Feature request / idea for supporting service that consolidates RSS feeds.
I have 200+ podcast subscriptions and antennapod takes ages checking them all.
One solution could be to be able to manage how often these are checked in more detail.
Another idea I have is to create a script for myself that consolidates all my feeds into one. This could then be a service that supports antennapod. Like gpodder but it works. Anyone see any merit in this idea before I test it out?
Down the line I can see it being a way to sync subscriptions.
I guess the problem is that RSS feeds still have to be checked in the background by the service, but I envision that this could be made more efficient by caching popular RSS feeds.
Hi there, do you have automatic update schedule turned on? I understand it takes a while if you manually update since it needs to check each feed and download any updates.
Did you also increase the number of parallel downloads?
This is basically what most other podcast apps do (the real ones, not the platforms). They let their server fetch the feeds and the app then, instead of asking the podcast servers itself, asks the app’s server. This has some advantages and some disadvantages
Advantages
Faster refresh because we don’t rely on a slow podcast server. Also, we only need a single server connection
Can reduce data usage by just delivering the updated episodes (when the app sends its database state)
Privacy: Podcast creators no longer know about subscribers
Disadvantages
Privacy: The central caching/aggregation server knows about all subscriptions of all users (could be circumvented if the server was open-source and could be self-hosted)
Caching can lead to episodes appearing in the app later (I have seen users complain just because an episode took 1 hour to appear in some app)
The server infrastructure costs money (180k users with refresh every 4 hours and 50 subscriptions would be around 1 GB/s network traffic when sending them the full feeds)
Single point of failure (when the server is down, every podcast of every user is affected)
More work for a pretty small developer team
(Podcast creators no longer see AntennaPod in their web server logs, making it harder for them to count subscriptions and making AntennaPod less popular)
After talking to my flatmate, I wonder what’s the use-case of the feature. Users who are impatient to get new episodes wouldn’t use the service because it can have a few hours of delay between episode release and the episode appearing in the cache of the server. Users who don’t care about the delay when getting an episode can just enable feed updates in the background instead of refreshing manually and waiting for it to finish.
ByteHamster’s use-case question put differently: What’s the problem with the above? Does it slurp energy, render AntennaPod or your phone impossible to use, make you receive episodes slower, or something else?
Another advantage is that the app can be updated by the server when updates happen using a Push synchronization. So an app with few feeds would very rarely wake up the device to sync things in the background.
That said, the first versions of my RSS reader app Feeder did just this with a server and I later moved to check all feeds locally on the device due to the massive maintenance burden it actually was.
The code for the server is still available in Feeder’s repo if you dig in the history to this place:
Though it’s probably not very useful. The API was built for a minimum communication between app and server, so it doesn’t serve up a combined RSS feed.