I’m currently working on a rewrite of the automatic feed refresh feature (not automatic downloads, that’s an entirely different thing!). Currently, we have the option to set a specific time at which to refresh (eg. 8AM) and the option to set an interval (eg. every 4 hours).
Android is making it harder and harder to execute background services. Especially services that should start at a specific time have been quite hacky already, and it will likely be even harder in the future. In my work on that rewrite, I have therefore removed the option to refresh at a specific time.
As a (better) replacement, it would be great to have some way to be more smart about checking for new episodes. My rewrite doesn’t include this option, but it already prepares the foundations for such a feature. This is a first proposal for a smart refresh interval feature. Feedback welcome.
For each feed, determine the expected point in time when a new episode will be released. This can use historical data (when previous episodes got released), but maybe also take into account what the server tells us (HTTP headers, Podcasting 2.0 tags, etc). Then, depending on the release frequency, do the following:
Daily episodes: Check 1 hour and 3 hours after the expected release time. If there is still no episode, check back again daily 1 hour after the expected release. If there is no release for a week, continue checking only weekly.
≥Weekly episodes: Check 6 hours before, 1 hour after, 6 hours after, 12 hours after the expected release time. If there is still no episode, check back again daily 1 hour after the expected release. If there is no release for a week, continue checking only weekly.
This means that regular daily episodes are checked two times a day in the worst case. This is the same as our current default refresh interval of 12 hours. The difference is that it’s not 2 random points in the day, but it tries to capture the episode directly after the release. Regular weekly episodes are checked at most 4 times a week, which is a massive improvement over the current situation (14 times a week), saving a lot of traffic and battery. And again, it will still show the episode earlier than before, because the time at which we refresh is closer to the release.
Even if a podcast makes a long pause, we would continue checking it at least once a week. For “dead” podcasts that users haven’t given up yet, this means that we reduce the network traffic (and the time that a refresh takes) by a factor of 14.
This sounds like a great feature. Aside from the smart refresh itself, it will also be important to think about how to make this apparent to users in a simple way.
Does showing the next expected episode date make it more clear for users what smart refresh really does? I was thinking more of a detailed documentation entry.
First what I think could be problems with smart refresh :
There are some podcasts which don’t release often but when they do I want to listen as soon as possible. And the longer the delay since the last episode the more impatient / eager one can be ! Knowing there could be one week delay is a big regression imho.
Especially if released episodes are announced on social media. If AntennaPod don’t show the released episode when announced it would feel like there is something wrong.
For podcasts releasing daily I am not sure checking multiple time a day (as you could anticipate some podcast to release in the morning and other in the evening) is a good thing. I am thinking about users with limited mobile data.
What I would suggest is to have a specific settings for each podcast to explicitly set what is the expected release frequency. User could change it to declare how smart refresh should update. (In some way what exists for auto download)
Just to be sure, smart refresh would be an option and it will still be possible to opt to check each specific intervals for all podcasts? And a manual refresh would still update all podcasts?
When checking 1 hour after the expected release time and the episode is already there, we would not check again after 3 hours. The numbers in my proposal basically describe what we do if we don’t find an episode. Even if we don’t find one (or it is always released more than 3 hours later than we expected), it is still the same number of refreshes as our current default value (every 12 hours). So this only makes things better for people with limited mobile data.
I agree that this would be a nice feature, but for now I want to focus on the default case, where users don’t need to tweak different subscriptions manually. One step at a time
Nice work. No particular thoughts from my side, great to read the conversation Maybe only that I’m not sure it’s worth adding an extra setting at podcast level for this.
Also, I wanted to share the current proposal for an <podcast:update frequency> tag that is currently open for feedback and very relevant to this discussion:
