New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Playback stops, won't restart after multiple forward jumps via Bluetooth #3264
Comments
|
Hi! I can not reproduce this issue on my device. Skipping forward and backward multiple times on my Bluetooth headset works fine. If you could reproduce the error and then grab a |
|
OK. I'll try to find some time to do that. First time I'll have worked with |
|
Thanks a lot. The article suggests to use |
|
Good tip. Thanks. I've worked with ADB a tiny bit to load CyanogenMod on an old tablet. But I'm no developer, so these things never get past the crawl stage of crawl / walk / run. :-) I'll pos when I have something. |
|
I'm delinquent on getting a logcat for this, but I was still have a problem just before the latest update. Now running 1.7.3b -- any chance there's a fix in there? EDIT: Never mind, problem still occurs with the new version. |
|
I believe experiencing the same issue when using the Android Auto app even without bluetooth. Reproduction is a bit hit and miss, in this instance I had to hit the skip button several times to reproduce, however quite often I've had it occur after only skipping twice. Once playback stops I have to clear AntennaPod from recent apps and re-open otherwise playback will not re-start (I pressed the play button twice to demonstrate this) LogcatDevice: Motorola X Force |
|
@dugite-code is describing very much what I've experienced. Thanks to dugite-code for posting their logcat, I'm not really set up to do that, which is why I'm super-delinquent doing so. Updating my original post: App version: AntennaPod 1.7.3b, Commit f9e7e9a, from Google Play store Android version: Android 8.1.0, security patch level 1 August 2019, no custom ROMs, not rooted |
|
As I recently purchased a new Phone I thought I would test this again, Please see my logcat output below. This time it was triggered after a couple of rewinds. LogcatDevice: Motorola One Vision |
|
Thanks for the logcat @dugite-code. Are you sure that it is the full logcat of the time when you pressed play? There is no logging from within AntennaPod, it just logged the fact that AntennaPod shows a notification. Either AntennaPod is not called at all or the logcat is from a wrong time. |
|
Sorry, looks like I accidentally trimmed too much in an effort to narrow things down. Here is a complete logcat dump. |
|
Thanks for the full log. There is still nothing interesting about AntennaPod in it, so I guess that the system actually does not call AntennaPod at all. I am currently not sure why it does not do it, though. |
|
So this behavior remains a mystery? |
|
From a first look, I do not know why this happens. This needs more investigations. I am not sure when/if I will be able to do that, though. Contributions welcome :) |
|
I've done a bit more testing, it appears to only occur if you have ExoPlayer selected in Media Playback. With or without skip silence and playback speed independent @dlemire60 what player are you using? I've not been able to re-produce the bug with the Built-in Android player or with Sonic Media Player. Note: looks like you have to close Antenna pod for the player change to take place |
|
I am indeed running ExoPlayer. I don't recall ever making a selection of that. I've got the three options you listed: Built-In, Sonic, ExoPlayer. Do you have a recommendation between the other two? Is the problem with ExoPlayer fix-able? |
Good find! 👍
We changed the default to ExoPlayer recently because it supports more formats and is under active development (as opposed to the other two). We should try to find out why this happens and fix it instead of reverting to the old players. |
|
Just noticed #3574 , any chance these might be related? |
|
I've had this recur again several times recently, particularly in the car (where it's extra annoying). I notice my player is back to ExoPlayer and I honestly don't recall whether or not I did that. So:
Thanks. |
|
I have experienced this issue multiple times recently. As previously noted, #4203 appears related / same. I'm on the verge of abandoning this podcatcher over this issue, as losing playback during my driving commute is infuriating. There are multiple user complaints over the course of a year+ with no apparent response at all. |
|
I am able to reproduce this with hitting the rewind button very quickly https://gist.github.com/tonytamsf/6b3fe74462da38c7a6d1431c6b654819 |
|
I tested this in a car, while playing just hit forward or rewind very quickly and it will crash with the ExoPlayer. With the default android player, it will not crash @ByteHamster I have a test build with doing actual locking when using the Exoplayer and I can make this crash go away. Is there any reason why we should not do locking with ExoPlayer? 28f424e#diff-75c6bb9019824923f353e71fb0838b9b923f41bfc7ed926f7b0b97cbf73cf11dR101 |
|
Sorry, I don't really understand what you mean. Should ExoPlayer be locked or not? From the code, I guess it should not be locked. So is the reason for this issue a deadlock? Comment here:
Code comment:
|
Right now the code does not lock for ExoPlayer here, PlayerLock If I actually do lock, then this issue goes away with hitting 'many' consecutive fast forward / rewinds. |
|
@keunes please assign to me |
If we actually execute everything on the main thread like it should be done, locking shouldn't make a difference. If it does, we are doing something wrong elsewhere. I fear that what we do wrong elsewhere could cause deadlocks or make the situation worse in other locations when adding locking. If you know where we do something wrong elsewhere, it would be a more "clean" fix. We can also lock and then do a long beta test if you don't know. |
|
I originally thought locking happens for the other 2 players, so there was not going to be a problem with locking on ExoPlayer as well. It seems like you suspect there are other threads running. Which I could learn how to find. Happy to dig some more to find the root cause, it will take me a while. Is it possible ExoPlayer is not thread safe? Not sure what this issue from ExoPlayer is telling us google/ExoPlayer#4463 |
|
I had this issue again this morning. Media player is set to Sonic. Locked up on a single forward jump on Bluetooth.
Have to exit Android Auto, close AntennaPod and relaunch it to resume playback. This remains super-frustrating, as AntennaPod otherwise suits my podcast playing needs pretty much perfectly. |
|
@dlemire60 does it happen with ExoPlayer? I am guessing yes. Does it happen if you slow down a bit when you skip, waiting for 3 seconds between each skip? |
|
@tonytamsf I'm fairly sure I've seen it happen with ExoPlayer. I won't claim to carefully track what player is selected. Generally slowing down multiple skips does seem to reduce the likelihood of this crash. But this morning it happened on the very first skip. And this only ever happens when the skips are triggered via Bluetooth. I've never had it happen from skipping forward using the phone UI. |
|
Got it, that is a good clue the media handling might be an issue. It happens to me when I use Android Auto screen in my car |
|
Glad to hear it's useful, since I'm not really in a position to capture / supply logs to help debug. The Bolt EV has channel forward / back buttons on the steering while that trigger the jump as well as on the infotainment screen. I've locked up AntennaPod with both. The common denominator in all of this for me is initiating the skip forward / back command via Bluetooth. I just reread my original post on this issue and all of that still holds. And I'm confident I've seen it happen with at least two of the three available media players. I'm a little fuzzy on whether the media player preference setting is sticky across program updates; I have a gut feel it isn't but I've switched phone app updates to fully automatic so I'm not really paying attention at that level. |
|
I'm also getting this bug. ExoPlayer selected and skips triggered via bluetooth. |
ExoPlayer is not thread safe, no. Currently, it only prints error messages to logcat when accessing it on the wrong thread. I tried upgrading the library and discovered that more recent versions will just crash the whole app in that case. I already made sure that most calls to ExoPlayer happen on the main thread but both the crashes when upgrading and the fact that locking fixes an issue show that I forgot some cases. If you would be up for digging into that, it would be pretty great :) |
|
This issue is more than 2 years old and we had several changes to the ExoPlayer code since then. I assume this went away at some point. If it didn't , feel free to comment and we can re-open the issue. |
App version: AntennaPod 1.7.2b, Commit b892713, from Google Play store
Android version: Android 8.1.0, security patch level 1 April 2019, no custom ROMs, not rooted
Device model: Moto G5S Plus phone
Expected behaviour: execute multiple 30 second forward jumps to skip over advertising and have playback continue without any other interaction with phone.
Current behaviour: While listening in the car or with Bluetooth headphones, multiple presses of forward jump button often cause AntennaPod to stop playback, and playback can only be resumed by unlocking the phone and restarting in the AntennaPod app. If Android Auto is active, I have to exit Android Auto; hitting the play button within Android Auto does nothing. This is reproducible, but not 100% consistent. Situation is better if I wait between presses of the forward jump button but playback sometimes still stops.
I encounter this most often listening to Security Now, as it typically has several long sponsor breaks per 2h podcast. http://feeds.twit.tv/sn.xml
First occurred: Uncertain, last few months?
Steps to reproduce: Start podcast playback via Bluetooth device. Press forward jump button on listening device several times (typically at least 3, often 5 or more)
The text was updated successfully, but these errors were encountered: