Antennapod download errors (403s etc)

Installed Antennapod, and have been successfully downloading and listening to podcasts, recently though it has stopped downloading any episode from newly Subscribed Podcasts, throwing any number of download errors, inparticular 403s, (forbidden, blocked access).

Using gnirehtet and reverse tethering, I can connect to newly subscribed podcasts without any problem:

Not sure why, but can only think weak wireless signal is to blame, despite being able to see the podcast series, and still browse, Antennapod throws errors when trying to download.

Regain your privacy! Adopt /e/ the unGoogled mobile OS and online servicesphone

weak wireless signal doesn’t play into this. A http 403 comes up due to the remote limiting your IP or user-agent. Browsing podcasts might speak to different remote (the one with the rss feed) than the download links for audio files - and those got issues. Does it happen on all podcasts or only specific ones? able to disclose them?

I assume it is temporarily due to ratelimiting. More exotic reasons could be the dns in reverse-tethering giving you another host than you get on the handheld and this one isn’t misconfigured to serve the paths you request in Antennapod. After all, if you don’t use the mobile data connection, both handheld and PC/Laptop do have the same network exit. Then my rate limit theory makes less sense.

1 Like

It only happens on certain podcasts, and I don’t use mobile data at all.

I did try to download one of the podcasts via the weblink in Antennapod, and in a browser on a laptop (although the address of the feed could have been different), but they both failed, but did download when reverse tethered.

Happy to disclose the podcast if that helps.

do you have advanced privacys tor exit enabled when you see the 403? CDNs that carry podcasts can limit tor exits.

so… let’s check one of the podcast where you see errors?

tit-for-tat, mobile computing podcasts I follow myself: https://cast.postmarketos.org/ + https://blog.esper.io/android-bytes-podcast/

I’ve been having the same issue with AntennaPod lately. The 403 error on some podcasts whether I have a great signal or a bad one.

could also just be some rss / mp3 url that is now outdated. Host sees request on path that is not allowed anymore, returns 403. So I think any report needs to name the Podcast to poke the rss feed.

Antennapod has without doing anything started redownloading, weird.

Podcast that was not downloading: ‘Diary of a Project Manager - Richard Stone’.

By turning off Advanced Privacy/Hidden IP, Antenna POD downloads work fine.

I understand this feature routes traffic through TOR, and presume it is this causing the issue.

@tcecyk writes: ‘CDNs that carry podcasts can limit tor exits.’

Presume that is the issue ?

all too likely. But as podcast urls nowadays go through many redirects (for … analytics) any one host in that redirect chain hosted at cloudflare or similar can hiccup on Tor.

In Antennapod, if you long-press an episode entry and go to “share” for “media-address”, a url is shown. That’s the one to debug. If you contact the sites that just enable cloudflare for other reasons but never gave the Tor usecase a thought, they might disable the Tor check. If they just serve static files there’s little reason to make life hard for Tor users.

That’s the one to debug

they might disable the Tor check.

OK, do I understand it correctly that some companies serving the podcasts restrict connections through the TOR network ?

In this case it is podtrac.com

From what you say there is no gain for them to ban such TOR routing.

I will ask them directly if they ban routing through TOR.

I presume server queries know its a TOR Router ?

there is a real upside for the provider shunning Tor for anything that takes computational effort and presents an attack surface (their tracking). Tor will skew their country numbers and invite probing.

The plain static file hosting is less susceptible to abuse, only to bandwidth. As there are ~2000 Tor Exits, a sane rate and bandwidth limit per IP can protect a static file serving host. This part can be solved.

As analytics are bread and butter for podcasts - to back its media data for advertisers - podcast hosters don’t include the deeplink to static files mostly.

If the tracking layer is very efficient and the operator doesn’t mind probing, than categorizing Tor Exits into an extra group in analytics is a way to allow for them. There is an argument for Tor here, as countries under censorship are in need of multiple info sources.