Expected behaviour: Add podcast to AntennaPod and be able to play the associated media content
Current behaviour: pop up displayed: IO Error. Too many follow-up requests: 21. It is my understanding that Android limits the number of recursive requests to a max of 20. For some reason, maybe related to how this podcast was created, the link redirects too many times and is rejected.
The error also occurs when the podcast is added through podcastindex.org
The same podcast is also available on bitchute, and using the recommended Bitchute RSS syntax (see format below) does indeed allow the addition of the podcast in AntennaPod, but the media content is not found and I get the “Item does not contain a media file” message. So although the podcast can be added, the content is not available.
First occurred: ~3 months ago. I suspect the publisher changed the format and since then, AntennaPod has not been able to subscribe to this podcast
Steps to reproduce:
Go to “Subscriptions”
choose the “+” button to add new podcast
Type “dr. cowan” in the search box
Select “Conversations with Dr. Cowan & Friends”
Notice the error message
or (through the bitchute RSS feed):
add a new subscription by RSS address: Dr.TomCowan
The podcast is added to the “Subscriptions” page
Select the item from the list and select any of the episodes.
Notice the “Item does not contain a media file” banner above the description
I can reproduce not being able to add by searching as in the first way to reproduce. Never attempted to add by RSS feed.
Could you please elaborate on your understanding of Androids limit on recursive requests to 20? I might be missing some understanding there.
If attempting to obtain the RSS feed from my computer, using: wget --verbose --server-response 'https://www.bitchute.com/feeds/rss/channel/drtomcowan/' the file gets presented with a HTTP 200 directly. I.e. there seem to be no redirects at all.
Apparently this gets thrown by ok http3. See the comment on StackOverflow. The header of the request needs to be modified to avoid this redirect error. I suspect that since wget doesn’t use that library (and is not based on java), the redirect error is circumvented.
Ah! Thanks for posting that link. The exact detail of why the server is triggering a redirect will likely differ, and I would argue the real problem here is a broken server configuration.
Maybe a work-around could be added if this was made visible as a GitHub issue. Would you feel keen to create one?
…and ticket was closed. It seems @ByteHamster looked more closely at this than I did, and concluded no work-around is possible. If indeed there are no media files published at all, it will for sure be impossible to download them.