Can’t download episodes for Clark Howard Podcast from Phone, works on Web app
-
Starting approximately 10/10, I can’t download any episodes of the Clark Howard podcast from my iPhone with the latest Pocket Casts application.
I can download them from my Macbook, which is on the same WiFi network and same DNS server.
I tried downloading with my iPhone only on cellular data, no change. I tested downloading episodes of a few other podcasts, and they all downloaded fine.
Pocket Casts Share Link to test episode – https://pca.st/4ekcokbm
Link to episode on Podcaster’s Website – https://clark.com/podcasts/10-13-25-the-cost-of-streaming-tv-can-you-trust-cpo-vehicles/ .
I’m not sure what to try next except to delete and reinstall the Pocket Casts app. Which I’ll try in a moment.
Is there a log or messages screen that will show me what is going on behind the scenes when Pocket Cast queues an episode for download?
-
Thanks. I came here to copy my initial report into a cust support request send from the app, so I’m def do that. I’ll look for the email you mentioned as well.
I did a few more tests without success in listening to the episode. I deleted and reinstalled the app. No change in the behavior.
I turned off “limit IP tracking” on my iphone , and the I tried playing from the Web browser “app” with both the iOS Firefox and Safari browsers. Neither could play the content.
-
ok. I sent the report from my Pocket Casts app and copied the request Id from your email into it.
I appreciate the quick response!
I also undid a recent change on my home network where I started using a pi-hole server running of VPN instead of my local ones. I reconfigured my router to use the local ones again. I have to leave home for work, but I’ll see if that changed anything when I return home.
-
It looks like a problem with the podcast and not Pocket Casts. There is a pretty long community thread about it on the podcaster’s website . I think it’s safe to close this request.
If you see anything interesting in the logs, I wouldn’t mind hearing about it.
-
Thanks for the update. From the submitted logs, we could not see any error entries that could relate to any download errors though.
-
I have the same issue, with the same podcast. Today’s episode (20 October 2025) shows that the file to be downloaded is 122 bytes and I’m sure it’s regularly 35mb-50mb. 17 October 2025 shows the same 122 byte file, I cannot see 15 October 2025 episode’s file size but 14 October 2025 shows 43.3mb
-
Hi there, @lookitsbenji! I checked on this and confirmed there is an issue on the podcast author’s side. Pocket Casts is not able to fix the feed. Please contact the podcast author (host) for more assistance. I also was able to play the podcast episodes from the mobile devices but not the web player.
-
As a follow up to this thread, it would be nice to see the http request/response output to help troubleshoot issues like this. I can run a curl -Lvs /episode/url command on my computer to catch DNS filtering ( pi-hole, adguard, etc ) and other issues , but I haven’t found a way to do it on my iPhone yet. At least not a way that follows redirects which is important since pca.st is effectively a link shortener. If we got a diagnostics menu option or similar that lets us see this activity, then there would be fewer support requests and more time for support to address real issues.
-
Thanks for coming back with this suggestion, @jagooch!
A couple of thoughts:
- The app actually has a built-in network self-check that covers part of what you’re describing (including whether DNS filtering or an ad-blocker is interfering). You’ll find it under Profile > Help & Feedback > tap the three-dot menu in the top right > Connection Status (iOS) or Status Page (Android), then Run Now. More detail here: https://support.pocketcasts.com/knowledge-base/how-to-check-my-network-connection/
- A full HTTP request/response viewer likely isn’t something we’d ship in the app. Captured traffic includes account credentials and tokens, which makes it tricky from a privacy standpoint. That said, the underlying gap you hit is real. A download that returns a bad file from the podcast’s server should leave a clear trace in the logs and show a clearer error than a silent failure. I’ve passed that along to the team as the actionable piece of your suggestion.
Thanks again for taking the time to circle back!