Proposal: Smart Refresh Interval

Feature request
1

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.

4 Likes
2

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.

A good example is Pocket Casts’s crystal ball:

ae5d1023-c0a1-4bb7-bd73-fee5c3621402_300x269

866b0968-06fb-4351-908d-f983b992c417_300x247

3

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.

4

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?

3 Likes
5

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 :slight_smile:

Yes

1 Like
6

Nice work. No particular thoughts from my side, great to read the conversation :slight_smile: 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:

7

I have an additional use case: I listen to “NPR News Now” which is a 5 minute podcast that is updated hourly. Please consider scenarios where episodes can be released multiple within a single day in your smart refresh redesign. Could be hourly, or 12 hours, or who knows what else might be out there.

I currently use a different podcast program where I can categorize/tag podcasts and then I can optionally create different update schedules for each category. So I have global update settings for all of my podcasts, and then I have an “hourly update” category I created and added the “NPR News Now” to that category, and set the schedule to start at 4am and update hourly.

I am considering switching to AntennaPod and would like to be able to set just this podcast to hourly updates without having to set my global update settings to hourly since the majority of my podcasts update daily or weekly.

Thank you for looking into this feature.

3 Likes
8

I’d say documentation on the smart refresh interval and a clear UI indicator about it are complementary, not mutually exclusive. Since we would be collecting information on episode frequency anyway, it would be a missed opportunity not to make that information available to users.

As an aside, refreshing ~50 subscriptions seems to take longer in the 3.1.0 betas, which makes an even greater case for this feature.

9

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.