Latest Unplayed Badge Indicator Not Working
-
The unplayed badge indicator is not working this morning on the Web App. It currently shows that all podcast subscriptions have unplayed/unarchived episodes — which is not accurate.
Thank you. -
-
Thanks for the bug report!
It makes sense that the issue would happen in both places – they use a lot of the same code behind the scenes.
I believe this issue has been resolved, as I’m not currently seeing it on https://play.pocketcasts.com/podcasts.
If that’s incorrect, would it be possible to post a screenshot in this thread showing the issue? If you’d rather not post it in public, you can always email us at (email visible only to moderators and staff).
-
Yes. This issue has been resolved.
But since I’m now here — I actually only registered because of this bug here in the forum — why is the frontend actually more limited here than on Android? I use Pocket Casts syncron on Android and Windows. On Windows you only see the red Badge when there are new episodes. With Android you can also set that the number of new episodes should appear in the red badge. At least for the German versions. But I guess it’s for all languages so, isn’t it. I miss that on Windows. Could you patch that? Shouldn’t be a big deal. Instead of a yes-no flag, just add the counter like on Android.
-
This is actually a request we get a few times a year, so it’s on our radar!
There are some rather tricky technical issues we’d need to sort out to support this – in the apps we have all of the data about which podcasts you’ve listened to in a local database, so it’s pretty quick and easy to calculate how many you have remaining and display it in the UI.
On the web, it’s a bit trickier because there is no persistent storage like on a mobile device – everything needs to be fetched from the server, and our server doesn’t currently keep an “unlistened episode” count for each podcast. This is possible to do, but has tricky side-effects – if the server maintains this count, it can very easily end up out-of-sync with mobile devices.
Unfortunately I don’t have a timeline on when we might be able to get this work done, but I’ve added this thread to our internal issue tracker as +1 for “please implement this feature”.
-
I’m not talking about the web interface. I’m talking about the Windows app.
In fact I see that you don’t handle the windows software like a real program and this app is not much more than a “dumb” interface. Which I really regret because the syncing between Android and Windows is the reason I pay for Pocket Casts. But even then it should be really easy.
Store it in the backend as a cookie on the web (of course with the option for anyone to refuse it) and make an additional rule for web apps that if there is no cookie (and on an Apps there should be no cookies!) you should look for a file in the data folder on Windows that contains the info. Wrote cookie or file everytime you sync. And if there is no cookie and no file, the counter won’t show and it’s like now. Simple rule. Works for web and web-interface-apps. The only differnce between this to interfaces is, that you need a class for cookies and a different for files.
Otherwise ignore the cookie and just use a file. Same rule for web and interface-app. If there is a file, show it, otherwise not.
-
As you noted – the desktop apps are indeed a derivative of the web-based app (with custom integration for the system playback APIs).
Unfortunately, cookies are very space-constrained (they can only hold about 4000 bytes per domain), so they can’t store enough data to reliably solve this problem for us. Other technology like Web Storage is interesting for this, but we still come back to the problem of recalculating the unplayed counts each time the browser (or app) is reloaded and during each sync – on mobile, we can run an SQL query to get those numbers because we have all the users’ data locally. Without that data, we need to refetch all of the user’s podcast data – burning a lot of the user’s CPU, memory, and bandwidth to regenerate those counts for every sync (because we couldn’t store every users’ podcast list in memory at all times without some significant performance issues).
While it’d be great to use something like sqlite on Windows and macOS to keep all of the user data local, these aren’t Electron apps – they have all the same sandboxing restrictions as a browser window (and don’t use up 200MB of storage on your device for an embedded copy of Chrome…). This is great for privacy and security, but it also means that our only good storage option is the server.
We’re constantly working to improve the web and desktop versions of Pocket Casts, and work hard to strike the right balance of performance, respect for the user’s resources, and platform feature parity. The balance we have makes some problems like this a bit trickier to solve, but allow our tiny team to ensure a solid experience on every platform.
-
It sounds like you’re pointing out the limitations of the Windows app for Pocket Casts, and how it’s not leveraging its full potential as a standalone program. You raise a great point about how syncing between devices, especially Android and Windows, should be seamless, considering it’s a paid feature.
Your suggestion about handling data storage in the backend—whether through cookies or a simple file in the data folder—makes a lot of sense. By using this approach, the app could sync more reliably without relying solely on a web-based structure. Implementing a system that checks for cookies or a file every time syncing occurs would create a more consistent user experience. Plus, as you noted, it’s a relatively simple solution that could improve both the web interface and the app.
It’s a valid concern that software should operate smoothly across platforms, and your proposal for file-based or cookie-based syncing could certainly enhance the app’s functionality.
Pocket Casts Forum 