@dave Something similar to Atom Link tag with 'next' attribute would be great. That allows the feed to provide a ling to another feed containing older episodes. That way you can go back to the 1st episode if you want to

@dave this is already defined in tools.ietf.org/html/rfc5005 using atom (as pointed out by @podcastaddict), if that covers the use cases, should we duplicate it in the podcast namespace or reuse? In principle I am more in favor of reuse.

@phoneboy @dellagustin @podcastaddict Good question.

It says that RFC5005 is a "proposed standard". Does anyone know if it ever got adopted? And, it it did, has anyone seen it in the wild?

I could start searching for it with the aggregator to see if nobody knows.

@dave @phoneboy @podcastaddict I first saw it as a recomendation in podlove.org/paged-feeds/ and once I used jekyll-octopod, a static site generator for podcasts (recently went out of maintenance), that supported paged feeds: github.com/jekyll-octopod/jeky

@dave @phoneboy @podcastaddict I did a quick manual search on a list of feeds I have, I could find at least one hosting solution that supports it (seems popular, the analytics of my app showed a lot of feeds from it), omnycontent.com/d/playlist/a85

@dellagustin @phoneboy @podcastaddict Thanks for this. That helps. I'll flag them on my side too, so we can see how widespread the adoption is.

@dave @dellagustin
It seems like all of the podcasts hosted by omnycontent.com/ support the paged links. Even the 25 MB one you posted has 4 pages of data. They just need to split their pages more often.

@steven @dave silly me, I did not notice that dave's example was already on omnycontent.com ...

@dellagustin @steven Thanks for the work on this guys. I'm going to build into the index some tracking so that we can identify who is using what namespaces/tags to make this process more robust.

@dellagustin @steven I wonder if @jamescridland has a contact at Omnycontent so that they could get involved in the namespace.

@dave @dellagustin @steven I've just raised this issue with their CEO. Their CTO is Long Zheng and he'd be excellent to have in here.

@dave @phoneboy @dellagustin Podcast Addict has been supporting this for quite some time. Some tools to generate RSS feeds are supporting this as well

@dave yes I like that. As well as what podcast addict said with the atom link tag

@dave it's a trap. Opening that totally jammed my mobile chrome 😅.

@dave WOW! I thought _maybe_ they had large <content:encoded> blocks, but no!

Checking the episode count it reminds me of the opening of Portal 2: "nine nine nine nine …"

@dave This is why we have a feature in powerpress called feed maximizer that minimizes the feed information beyond a set number of episodes.

@Todd_Blubrry What does it do with the old ones? Archive them somehow, or just move them out of the feed?

@dave This is one of my biggest beefs with feeds - no paging functionality. Don't love the IETF solution either of <link rel="prev-archive" href="[PREV_FEED_URL]"/>. Feel like there should be a simple way to request the feed with an offset or page number value.

I also think the <podcast:archive> proposal is lacking because it requires offering a way to request a single full archive feed file which lazy apps could just request every time.

@dave Maybe just having *.rss?offset=12 or *.rss?pg=2 still allows the feed's policy of how many episodes per feed file to be maintained.

@nathan Hmm. Bringing in url parameters seems out of scope for the namespace, but I do catch your meaning. Having just one big archive is tough. The good thing about RFC5005 is that it handles both dynamic and static feed generation pretty well. For hosts that produce and store static feeds, a dynamic offset in a url param would require a big refactor.

@dave Agreed, it's kind of outside the namespace but I think solving everything through namespace might not always be best. Thankful for your work on this!

@nathan Yeah, that's good to remember for sure. Gotta use the right tool for the job.

@nathan ..."right" being its usual subjective self. 😂

@dave This feed also has 9,999 episodes in it. I've reported it to Omny Studio, since that can't be as intended. My suggestion to them is to limit their feeds to 300 long, which is all Apple Podcasts will parse anyway.

It *does* have paging implemented, just as @podcastaddict requested, though.

@jamescridland @podcastaddict Do you know anyone at Omny that could join us here for tech discussion? That’d be really helpful.

@dave @jamescridland @podcastaddict Hi guys, Long from Omny here. I'd glad to see the issue of RSS size being discussed publicly as it has been a frequent internal debate as well.

Since inception Omny Studio has supported paginated RSS feeds using the RFC5005 <atom:link> spec for obvious performance/bandwidth benefits. Unfortunately, support for paginated feeds in apps has been spotty (but props to Podcast Addict).


@dave @jamescridland @podcastaddict Notably the Apple Podcasts app still does not, which means it will only display the number of items on the “first page”. (Furthermore Apple Podcasts directory will only show 300 but that’s not an issue in the app)

By default, we paginate by 100 episodes/items (subject to change), however we offer customers/publishers the ability to override their "pagination size".


@dave @jamescridland @podcastaddict Some of our customers, like the one in question, have a preference to show their entire catalogue in the RSS feed to their audience, which means to cater to the lowest common denominator and disable paging.

Whilst the <podcast:archive> proposal is interesting, we believe the already established RFC5005 spec addresses the same problem and allows for more responsive user experiences when navigating, especially when the archive actually becomes quite large.

@longzheng @jamescridland @podcastaddict Thanks for that explanation Long. We’re trying to figure out the extent that these standards are being used across the industry. This is very helpful info.

@longzheng @jamescridland @podcastaddict If we can get a feel for some of these things it’ll help decide if it’s worth “duplicating” that functionality into the podcast namespace. I’ve seen a couple of times where there is an existing standard but hardly anyone uses it. In that case, bringing it into the “podcast” namespace could actually help it get adoption more broadly. I’m building a stats tool right now to track which hosts are using which tags.

@longzheng @jamescridland @podcastaddict We definitely don’t want to waste time duplicating something that’s works well and has broad adoption. It’s the adoption part that’s hard to gauge.

Sign in to participate in the conversation
PodcastIndex Social

Intended for all stake holders of podcasting who are interested in improving the eco system