Do not update all feeds each time

Feature request
1

Currently, all active feeds are updated each time the update is started.

However if I know a feed is updated only once per week, I could tell AntennaPod: “Do not update this feed for 7 days after the Published date of the latest episode.”. This number (an integer number of days) should be customizable per feed and a zero would mean that the feed should be updated every time.

This would significantly lower the number of feed accesses and maybe inspire authors of other podcast apps.

Another feature could be another (higher) number that would show a symbol in the feeds list, if a feed did not publish a new episode since that number of days.

2

One of the 2.0.0 beta versions did something similar. It respected when web servers told AntennaPod that it does not need to re-check in the next x hours. Unfortunately, creators use broken server configurations, so we had to remove the feature again.

1 Like
3

I didn’t know about the server feature. I meant it as a manual setting for the user.

4

A setting that users could manually change could work, but probably not the way we’ll go:

  • it’s yet another setting while the app already has quite a few (and we aim to keep the app simple to use)
  • we’ve had complaints from users about app behaviour that was caused by a setting they had changed in the past but forgot about - the same might happen with a setting you’re requesting: “How come I receive new episodes for this podcast only a day later?” > “Did you perhaps change the update frequency for this podcast?”

However, this could be something that podcasters could more reliably indicate. There is a new technical initiative called the Podcast Namespace, allowing podcasters to add metadata to their feed. I submitted a proposal that would allow podcasters to indicate how often they (expect to) release new episodes. This information could then be used by AntennaPod to determine how often feeds should be updated, without the need for users to specify this.

1 Like
5

(sorry for the necrobump!)

I like the spirit of your proposal in the Podcast Namespace! I think that something like that would be very flexible.

However, in the meanwhile, I see that the syndication namespace has a simple solution to what this feature request is about: the ability for a publisher to set a custom frequency, which is appropriate to the feed the user is asking.

While I can’t wait for something even better to be available, I think this would really be an important step: as a podcast host, I hear the “how fast will my episode arrive in AntennaPod” argument from users, and I’m afraid it could be a winning point for big, closed platforms like Apple Podcasts. Being in a radio, where I can expect new episodes every hour, the default 12-hour interval is really big, and I’d love to be able to ask podcast clients to poll hourly.

6

Actually, we had something similar to this in the past. When the server indicated that the RSS feed will stay fresh for a given time (using HTTP headers), we skipped refreshing that feed until the time ran out. Unfortunately, we got a large number of complaints by users who saw episodes on the website (and in the feed using the web browser) but not in AntennaPod.

7

When the server indicated that the RSS feed will stay fresh for a given time (using HTTP headers), we skipped refreshing that feed until the time ran out.

Thanks for the quick answer @ByteHamster ! I see what you mean, but I would also like to understand better.

@keunes says that they have a proposal to do something similar (just more expressive) to what I’m saying.
I think the assumption is that HTTP headers should have all the semantic we need, but people misuse them very often, so we cannot use them; while for RSS tags we expect their usage will better reflect the publisher’s will, because they are higher on the stack. This is, at least, my understanding, and my motivation for the request I am making.

If that is the rationale, I don’t really see why <podcast:frequency> can be adopted (when standardized), while <sy:updatePeriod> cannot.

Unfortunately, we got a large number of complaints by users who saw episodes on the website (and in the feed using the web browser) but not in AntennaPod.

Well, the motivation behind my request is very very similar: I host podcasts, and I’d like my listeners to use Antenna Pod instead of commercial podcasting platforms. What can I do to give updates to listeners quickly?

1 Like
8

Do you know if <sy:updatePeriod> is widely adopted by publishers? If not, then we’re talking a chick-and-egg story for both namespaces/tags.

I feel that we should focus on the namespace that is under active development and discussion; tailored to our specific needs; and which we already support partly (if I’m not mistaken, we don’t support anything from the syndication namespace).

That’s great to hear <3 Have you engaged in the discussion on this podcast namespace tag yet? I think that getting voices like yours (as host) would be valuable to move things forward.

9

Do you know if <sy:updatePeriod> is widely adopted by publishers?

I didn’t know, so I have done some crawling over podcastindex.org. I hope this can be usful. Let me know if you want to have the scripts, data, or anything else.

Results

I downloaded a list of the latest 1000 feeds from podcastindex, downloaded them all, and had a quick look at them.

Adoption among feeds

The adoption is 6.4% in this sample, comparable to the 6.8% of podcast:funding, 2.44% of podcast:location, 0.7% (sic! I couldn’t believe that) of podcast:alternateEnclosure

Adoption among websites

If we count the number of websites supporting this tag instead of the number of feeds supporting it (thus ignoring that some websites host more podcasts than others), this number bumps to 13.7%, while podcast:funding goes to 5% and podcast:locked to 19%.

Other findings

Every single time that sy:updatePeriod was used, its value was hourly. This suggests that it’s only used by people who want their feed polled more frequently.

Limitations

My analysis is of course limited because it’s just on a rather small sample, but I think it’s still useful.

A better analysis would need to ask: how many podcasts needs to set a higher update frequency at all? A podcast series releasing one episode per week will be ok with daily checks, so this kind of users don’t have any incentive to use updatePeriod. This was too complicated to check, so I didn’t, but my feeling is that if we take this into account, then the adoption by people who needs it is quite high.

Conclusions

So, to answer your question I think that adoption is not so low. it’s higher than the adoption of other easy to support tags which the authors clearly have great incentive to support (podcast:funding bring money in their pocket).

Have you engaged in the discussion on this podcast namespace tag yet? I think that getting voices like yours (as host) would be valuable to move things forward.

I haven’t, but I will. thanks for encouraging me :slight_smile:

1 Like
10

I interacted on the discussion in podcast-namespace, and gave my contributions.

Honestly, I believe that the discussion is stuck:

  • there is some vague consensus that a tag specifying the polling frequency/time is useful
  • the proposals that are more concrete look very similar to what we already have in the syndication namespace
  • some proposals look more ambitious, expressive, but also half-baked. i.e.: the idea of using ISO 8601 might be interesting, but it’s just an idea. Should every client poll at exactly the same moment? This seems like a recipe for self-DDoS-ing. Should each client apply some random variation to those intervals? how much of that? None of that has been specified, so I don’t see it as a real proposal
  • no practical case has been proposed of scenarios in which podcast hosts would benefit from more expressiveness to what we already have

I definitely understand that projects such as podcast-namespace are often run on “free time”; but I wonder if we can expect that specific topic to ever move forward in a reasonable amount of time. While I hope we can have something great in the future, I’m sorry that many clients, including AntennaPod, are letting perfect be the enemy of good.

If there is any input I can give to those discussions to help you, please let me know.

Oh, and again: thanks so much for maintaining such a great podcast app! :heart: