Player audio randomly stops - but seekbar continues progressing

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:

  1. start debugging app.
  2. play podcast more than 20 min.
  3. wait until stop.
  4. after that the app is in crash mode.
  5. 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. :crossed_fingers:

1 Like

First a warning in debug mode. I will testing
Uk message in Dutch version

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.

2 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