I tried this version without much luck. It also presented the same problem after ~17 minutes of reproduction. :(.
But as indicated by other user in this version it is easier to recover by simply stoping and resuming de reproduction.
1 Like
I was playing some pods this weekend on the debug version. My pods donāt usually have many updates on the weekends so I didnāt have a great sample size to play with but I was connected to wifi all weekend and the three or four episodes I listened to all played without issue. Well I just listened to another and because I usually only noticed this issue while I was away from home and disconnected from wifi I decided to try something different. The podcast started playing and I āsimulatedā what I thought Iād notice when this happened, which was when Iād start listening to a podcast on wifi and then leave the house and automatically switch to mobile data. And wouldnāt you know it, the issue reoccurred. And I donāt completely understand but it was at 17:34 into the podcast, which falls in line with everyone saying the 17 minute mark. I donāt understand what is significant about that. Not all podcasts are the same file size so it canāt be something triggering based on playback progress with regard to the data size, but Iām no developer. Is the app caching 17 minutes at a time?
I didnāt get an error message, though so not much else I can provide.
edit: Dang. So I removed the debug app and went back to production. The pod that I had the issue withā¦I started it over and streamed it and stayed connected to wifi and again at 17:34 playback cut out. No idea.
Just chiming in with the same issue on 3.4. Started about a week ago. Frequency has increased. Always on Wi-Fi (so not a connection issue), happens both from phone speaker and multiple Bluetooth headphones. I exclusively stream, have not tried downloading and listening yet. Happens on various podcasts, sometimes about 15 minutes in, but in the last 2 days itās happened with only 5 or so minutes left in the 1+ hour ep.
Audio cuts out but playback is still advancing. Attempting to pause/rewind/fast forward earlier this week gave me the error message that the ep canāt be played. In the last few days it appears playback resumes but still without audio. Going back to a timestamp before the audio cut does the same: it appears that playback resumes but no part of the episode plays audio once it cuts out initially. Closing and clearing the cache does not help.
I checked the first episode it happened on at least once a day and about 3 days later was able to get from around 15 minutes to the last 5 minutes before it cut out again. It seems after I listen to other pods (audio does not cut out for all, maybe 1/4) I can go back to the one with the error some time later and it will magically work again. No GitHub account but will try downloading and see if that helps for now. Thanks for the work you do!
1 Like
Not 17 minutes, but 50 MB. Depending on the audio quality, that may be at 17 minutes or another time point.
Thank you @teunlielu and @abdelix for downloading and testing the debug build. Given that you say it didnāt fix the issue and only made it easier to recover from it, I think itās safe to conclude that itās not the caching.
Weāre looking into other possible causes.
1 Like
for the person who wants to fix
following steps to test/debug problem:
- start debugging app.
- play podcast more than 20 min.
- wait until stop.
- after that the app is in crash mode.
- you can debugging whats is happening.
Unfortunately, I have no Java knowledge myself
Adding my voice here since I had the same issue. The screenshots of the error above are the same I get. Audio stops after ~17minutes, requiring a force close and clear cache. Once resuming, the player will play a few minutes and then mark as completed, despite time remaining.
The same isue to me:
āAdding my voice here since I had the same issue. The screenshots of the error above are the same I get. Audio stops after ~17minutes, requiring a force close and clear cache. Once resuming, the player will play a few minutes and then mark as completed, despite time remaining.ā
Same problem lately for me with the Play Store version of AntennaPod 3.4.0 on GrapheneOS/Android 14. Like others, generally this failure/stoppage occurs around 17 minutes, though I donāt doubt the timing might be different if the given podcastās sample rate varies. Clearing the AntennaPod cache seem to resolve the issue for the failed podcast. I never had this issue until recently, perhaps the current release.
1 Like
Hey all,
Android 13 with AntennaPod 3.4. Same issue and same workaround (clearing cache). Another workaround is sharing the link to file ; that opens mobile browser and i can play it from there.
It seems to be happening to iHeart streams exclusively for me. I donāt think iāve encountered this problem with podcasts unaffiliated with them (namely Lions Led by Donkeys and Tech Wonāt Save Us).
A bit more details : it happens on mobile and wifi, speakerphone or plug-in earphones (audio jack) and i feel like once the play is stopped for a stream, all the other affected streams are broken too (error message immediately for any episode of the other iHeart podcasts)
Keep up the good work! iām subscribing to this topic.
Just adding my voice that Iām having the same issue. Started sometime in mid or late May 2024. Itās not all podcasts, but some have stopped streaming 17 minutes and some seconds into program. I get the same error message as others have posted.
Iām streaming on home WiFi, Android 13 (Moto G Power 5G 2023), AntennaPod 3.4.0.
A couple of podcasts Iāve run into trouble with are Mission Implausible and Fast Politics with Molly Jong-Fast.
I switched over to AntennaPod when Google Podcasts went away and have been very satisfied with it until this recent, intermittent problem.
Not for the first time, Iām sorry Iām not more tech savvy so I can try to help identify and fix the problem instead of just being a āme too, Iām having that problem also,ā voice. I greatly appreciate the time and dedication of the volunteers who have made AntennaPod possible.
Hi @teunlielu, @abdelix, @richardeid and anyone else who has a GitHub account and is willing to test:
@ByteHamster prepared another test build, reverting another recent change. If youād be able to help test that one also, thatād be great. (In case that version doesnāt have this problem, we donāt have a final fix yet but at least weāll have a direction in which to look.)
Again, like last time:
Many thanks for your help debugging this issue!
1 Like
Installed. I have a bunch in my queue for the weekend so I will hopefully have an answer shortly. Or not because itāll be fixed. 
1 Like
tried with 3 streams that had the problem (all iHeart). it seems to be working! i think this is it!
1 Like
@teunlielu are you speaking about message warning that playback states and history will be deleted after a while for unsubscribed podcasts ?
If yes itās not an error, future version will allow to add to queue episodes from unsubscribed podcasts. Itās only to allow to listen to ad-hoc episodes that someone for instance recommended you. If you want statistics, history, auto download or whatever then subscribing is required.
3 Likes
Yes this message must translate.
I listen two sort podcast works now. But i must longing podcast
1 Like
Iām four episodes in and it seems good so far. When I first got my database transferred into the debug version I was in the middle of a podcast with about 20 minutes left. As the podcast neared the end and some ads were running I hit the skip ahead button a couple times to get to the end of the episode and the error message about āpodcast could not be playedā came up so I was worried initially but every pod since then has been ok. I still have a decent queue left so weāll see.
edit: I forgot to mention this on the last test build but I love the icon on the test build! I can report no bugs with it so itās ready for production lol.
edit 2: spoke too soon! I was just listening to a podcast and the issue popped up again, but not without a qualifier. I like to mess around and break things. Since a handful of pods worked I decided to try something. I was just around 7 minutes into this podcast and I thought since it seemed to be a caching issue letās see if I can ābreak the cacheā in some way. Easiest thing I could think of was to force close the app while it was playing. Did that. Opened the app back up and continued playing and wouldnāt you know itā¦at the 24 minute mark it went silent. When I opened the phone again to see what was going on, I noticed the timer continuing to run.
Iām not sure this is a normal use case of course but regardless I still ran into the same issue. If you need any more info let me know! Iāll keep trying to break it in other ways if I can think of any.
1 Like
A post was split to a new topic: Duplicate episode
I have listing long podcast works now fine.
1 Like
Thanks for testing, @teunlielu @richardeid @koumilak! The fact that the test build works is only a small step forward, unfortunately. That build removes a bunch of things that we should really keep. Otherwise, it would break other use-cases.
Because of this, I created another test build that re-adds some of the features. Would be great if you could test that one as well to see if it is still all good. Then we can keep gradually adding/removing things to see what is actually causing this. Test build here: Test using defaultmediasource by ByteHamster Ā· Pull Request #7250 Ā· AntennaPod/AntennaPod Ā· GitHub
Thanks!
1 Like