I never manually add anything to my playlist. Since I nearly always download episodes before listening I just review my Inbox when I’m on WiFi and click the download arrow next to episodes I expect to be listening to soon. They are automatically downloaded and added to the queue.
Hi, I’ve been having this issue with iHeartRadio streams (stuff you should know, my momma told me, stuff you missed in history class) exactly at minute 19 and then when it reaches the expected initial run time in each one of those. I have to clear cache, remove the episode and add it back to be able to finish them
Please add me to the list of those with this issue. I download all my episodes, so for me it’s not streaming related. It happens randomly as far as I can tell, and on multiple subscriptions. So far, Pause/Play returns the audio to the bluetooth speaker.
There’s quite a few folks with slightly different stories/circumstances around this issue. That makes it a bit hard to identify the probable root cause.
Some factors/trends that I see from the comments above:
- Most people have this issue while streaming, some confirming they don’t have this issue when downloading episodes. Only @TTB says to have this issue also with downloaded episodes.
- The initial report is from AntennaPod version 3.3.2. However, many more people chimed in recently, after the 3.4 roll-out. If you’re having this issue as well, please mention in which (suspected) version/how long ago you first noticed the issue.
- Some folks have reported this issue appearing with Bluetooth, others when playing on the phone itself. It’s probably unrelated to Bluetooth, with Bluetooth (earbuds/car) just being a ‘symptom’ of being on the go, i.e. when using a mobile internet connection.
Currently on 3.4 ans issue remains.
First version I tried was 3.3.2.
Always use on mobile network but had zero issues in Google Podcasts (or in YouTube website playing in Brave Browser). Have way less time at home, so cant really test over wifi.
Always use BT earbuds (wired headphones are not practical in my commute). But seeing as I have zero issues if the file was pteviously downloaded, Id say its not related with that.
I’ve gone back to all reviews until & including 1 May, with review texts describing this issue. Early May I didn’t see any relevant comments actually, so I get the impression it’s indeed something of 3.4 mainly.
I’m having this issue as well
- Using 3.4.0f (5f5d744e7), which is the only update I’ve ever used (just installed the app)
- I am also using a VPN alongside it
- When listening to “Behind The Bastards” (loaded from this RSS feed link Behind the Bastards) “Boston Slide Cop” episode continues normally to 22:32 where audio then cuts out and the audio line/number continues moving at the normal pace. At this point any interaction with the timeline features of the app (pausing, fast forward, rewind, etc.) will produce the error message. After the error message has been produced trying to go back and listen to anything before the 22:32 mark will not load and produce the error message. I do notice that going to before the 22:32 mark seems to take longer to produce the error message (tries to load for longer) and produces a “Response code:403” whereas going after the 22:32 mark it only tries to load for a few moments before producing the error message and produces “null” (see attached screenshots).
- Every other Behind The Bastards episode I’ve tried thus far simply fails to load and produces response code 403. “Boston Slide Cop” was the first episode I tried listening to after downloading the app so IDK if that has something to do with it.
Oh yes and also:
- Going under the “Boston Slide Cop” episode and “Reset Playback Position” allows the first 22:32 to be played again but once it hits that point the aforementioned problem still exists. Also doesn’t allow for any other episodes to be played.
- Removing the podcast from my list entirely and re-adding it also allows the first 22:32 of that same “Boston Slide Cop” to be played but doesn’t allow any other episode to be played or any other part of that “Boston Slide Cop” episode.
In addition to the new caching, another possible reason is that we upgraded the ExoPlayer dependency
for me, the issue was there in, 3.3.2 which was the first versio I tried.
Anyone usong for longer can post a version number that worked fine?
Is ExoPlayer included in Android System Webview?
Is AntennaPod running in Webview?
If i force stop Webview while AntennaPod is playing, AntennaPod is shutdown
Same problem. This is a huge issue. There has not been a single substantive response to these posts. Is nobody addressing?
1 Like
No, ExoPlayer and WebView are completely unrelated
The shownotes are displayed in a WebView
AntennaPod is developed by volunteers. Feel free to fix it yourself or hire someone to do it. If you don’t want to do either of that, you have to wait until a volunteer has time
2 Likes
@keunes. I am on 3.4.0, and my issue definitely began some time on or after May 12, which is when I updated the app. I am on Android 14.
1 Like
Hello, I’m next with problems. Quite often, when one episode ends, playing stops with some weird sound being endlessly played, and I need to manually skip 5s to make it playing next episode.
I’m of course on the newest Google Store version 3.4.0
Thanks for letting me know. I had no idea. Since I don’t have the skills to fix these problems and the community is obviously under-resourced, I’ll find a different podcast player. I appreciate the heads up.
1 Like
In 3.4 we introduced a caching mechanism for streaming episodes. The idea was that this would improve the streaming experience, by not being interrupted by drops in the network. However, it might not have worked as hoped.
I created a test version of AntennaPod where this change is reverted, so that you can test if that no longer has issues. Unfortunately the app is too big to upload here, but you can go to Revert #6927 by keunes · Pull Request #7216 · AntennaPod/AntennaPod · GitHub, click on ‘artifacts’, download the zip file, and install the app from the zip file.
It is safe to install it while you have the main app installed; it is a ‘debug’ version that can live next to the usual app.
Those with GitHub accounts (required to download the debug version), would you mind testing if this version still has the streaming problem?
2 Likes
I’ll test it but I’m dumb when it comes to github. Where is artifacts? I am on the page but can’t see it.
edit: Wait I figured out I had to login. I’ll let you know.
2 Likes
I have testing both.
Both fail with samen problem. But the expression is defference.
Debug en play store release.
You can then get debug to work more easily
release hangs up completely. If the debug occurs, it can be restored without the cache removed. so debug is better. release hangs up completely. If the debug occurs, it can be restored without the cache removed. so debug is better. I was then able to listen to the podcast after the problem. Press pause/play/move timeline one thing.
google translate from nl