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.