Feature: View http request and response log inside the mobile application
-
It would be a nice feature to see the http request/response logs inside the mobile application to help troubleshoot issues with episode downloads. I can run a curl -Lvs /episode/url command on my computer to catch DNS filtering ( pi-hole, adguard, etc ) and similar 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 the request and response logs , then there would be fewer support requests and more time for support to address real issues.
It would also make troubleshooting a lot easier. I had a download issue for a few days because I didn’t have time to get to my computer to investigate an episode download issue. Once I got to my computer, I was able to access my DNS server logs and see that the ad filter was blocking the domain “pscrb.fm”. That domain being blocked didn’t cause the browser based played any issues. ,but the mobile app could not download episodes that included an http get request to that domain. If I had logs inside the app, I would have saved me a few days of time troubleshooting the issue.
-
Hi again, @jagooch! Thank you for writing this one up as a proper feature request. The pscrb.fm example is a really useful illustration of the problem, since it shows how a single blocked domain in an episode’s redirect chain can break downloads in the app while the web player carries on fine.
And just for reference, I’ll add the same comments I shared in the thread where you originally requested this:
- 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.
I’ve made sure to file this feature request internally for you too. Thanks again!
Pocket Casts Forum 