Player audio randomly stops - but seekbar continues progressing

Are there people that aren’t having this issue? I see the reviews are still positive so I assume it’s usable on some devices?

I do not have this issue.

It may be relevant that I nearly always download episodes rather than streaming them.

This bug only affects streaming with some (maybe even most, but not all) podcasts.

1 Like

I’m seeing this bug with “Stuff You Should Know” every episode over 15 minutes and rarely with other podcasts.

I have had the same problem for the last month or so. The error message when I try to get it to play says “The media file could not be played” and goes on to suggest deleting and downloading a new copy. I have not been able to find a way to do that.

This brilliant program got me back into listening to podcasts but this is getting to be a show stopper.

What is the best way to help find a solution?

I am using AntennaPod 3.4.0, Android 14. All of my listening is streaming. I am connected by Wifi, solid connection.

TL;DR: Instructions on how to avoid the problem is in the last sentence, but please take a moment to read this post.

I can’t help to notice that there are people dropping questions in this thread, and realize the cultural difference between Google Podcast and AntennaPod is huge.

Quite a bit up in this thread, we had this post:

For a volunteer driven open source project like AntennaPod, the above used to be enough. It contains all the clues, at least in combination with the rest of the thread, for finding the answer. With the current situation with a huge influx of Google Podcast refugees, it is arguably not clear enough to meet everyone’s expectations.

While we are blessed with a great community manager. I fear burn-out with this sudden increase and cultural change of the user base. I would invite some responsible new user(s) to help out with forum participation, the answering kind of volunteer. I’m sure it would be much appreciated by both the team and the rest of the users.

Now, to spell out the details of the above Pull Request. It does revert the change introducing this bug, and it is scheduled for inclusion in the next release 3.4.1. Anyone can already locally compile this version and use it. I have done so and successfully streamed the troublesome boston slide cop episode discussed in this thread. This is the power of open source.

While running 3.4.0 or earlier, one can easily work-around the bug by downloading rather than streaming episodes.


I just uploaded a beta release containing the changes that most of you reported having fixed this


I listen podcast more 17 minuten this was ok. I will testing more

I know it’s probably boring details, but would you mind mentioning what was it that resulted in the fix that last test version that everyone still had a problem with but worked fine for me. It was kind of odd so I’m just curious what the difference is. Thanks for all the hard work on that one

I listing more is good version without the bug

I see release of 3.4.1 is this bug fixed? Beta version is good

There is a post referring PR #7250, linked to again in my latest post three replies up here.

If you fancy another entry point to viewing the difference, try a diff between the versions on GitHub:

Hopefully that answers your question of what. If the question is how it actually works, then it might be best to phrase down your current understanding of the change (preferably in a new thread) and take it from there.

1 Like

I have listing 2 podcast was good. Bug is fixed in release.