Since my old thread was locked due to inactivity I had to make a new one (Didn’t want to write in the other one since there was a new version on the horizon hehe)
Just gonna copy what I wrote here as well, seeing as it’s still an issue with the new version, and it does not happen (or rather, the media controls work perfectly fine) in other apps that can utilize them (e.g. Plex itself, YouTube, YouTube Music, Spotify):
I’ve been using Plexamp over the last few years on several phones and been loving it, it’s a really nice experience
However, as of late, it doesn’t seem the media controls from bluetooth devices are working correctly… I’ve tried it on 4 different bluetooth headphones:
Bose QuietComfort Ultra Earbuds Gen2 → Pause works reliably, but play doesn’t work for about 5 seconds after pausing. That is in Plexamp, in the Plex app itself it doesn’t start playback at all anymore when I use the earbuds’ physical / touch controls
Anker soundcore AeroClip → Pause works reliably, play doesn’t work at all in Plexamp (or Plex)
Nothing Ear (Open) → Pause works reliably, play works when I try it a 2nd time (as in, the first one doesn’t get registered) (Same behavior in Plex)
SONY WH-1000XM6 → Pause works reliably, play works after the 2nd time as well (Same behavior in Plex)
I’m running a Samsung Galaxy S24 Ultra with One UI 8.0 / Android 16.0. Plexamp version 4.12.4
I’ve also had a glance at the logs and I couldn’t spot anything out of the ordinary (as in, something like a “Received ‘play’ command, failed to execute” or similar). I’ve attached them though just in case there is some helpful insight in there.
Another thing I’ve noticed that in some of the respective apps for the earbuds / headphones they also have media controls and those behave in a similar way where pausing works fine, but trying to hit play has the issues as described above.
Right, apologies!
So what I’ve done here is first fully stopped the app through the Android settings.
After that I started, then connected the Sony WH-1000XM6 and tried using the bluetooth controls to start playing, which didn’t work.
I then manually started playing, then tried pausing via. BT controls which did work.
However, trying to start playing through BT controls didn’t work for 5 seconds, after which it worked again. Pausing always worked instantly. (Did this 3 times total)
Then I switched to the Bose QuietComfort ones. Play worked the first, pause worked instantly.
After pausing I always had to do the BT controls twice though for it to start playing again (as if the first one was somehow not registered or “eaten”?)
Then switched to the Anker soundcore ones, and those were pretty much the same as the Sonys.
I went through the logs a bit myself and I can’t really spot anything in between the pause and play events… Like, no errors, no extra information, nothing…
Unsure if that’s intentional or if there’s some extra debug information that could be added there to help figure out what’s causing this
You were right that there’s nothing in the logs between the pause and the failed play, and that turns out to be the problem rather than a clue. We weren’t logging incoming transport commands at all on Android. Media3 handles play and pause internally against the player, so a press the system never delivered to us and a press we took and then ignored look exactly the same in your log: blank.
Which is annoying, because those two want opposite fixes. Either Android isn’t routing the button to us for those few seconds, or it is and something on our side is dropping it.
So I’ve added what you asked for. Every play, pause and stop that reaches us now writes a line into the app log with the state it arrived in, and audio focus changes were already logged, so the two line up by timestamp. It’ll be in the next beta.
When you get it, same test as before would be perfect: pause, then hit play with the BT controls during the dead window. If the failed presses show a line, we know they’re reaching us and I go looking at our side. If they show nothing, Android isn’t sending them and it’s a session priority thing. Either way that narrows it to something I can actually chase.
Thanks for the detail on four different headsets, that’s what made it obvious this wasn’t one dodgy device.
As another data point, on my Pixel 9 running Android 17 it appears plexamp was getting killed by the system almost immediately after pausing, so resuming with headset controls wouldn’t work. Changing the battery optimization setting to unrestricted fixes it.
No need to wait for a new one, the build already in the beta has the extra logging in it. Grab a capture from that whenever it next misbehaves, ideally with the app open since you say it happens then too, and I will see what the car and the headset are actually sending us.
Oooh I thought I had to wait for 4.50.8 to be approved on the Play Store first haha, sorry
Just did the same spiel - Anker Soundcore first, then the Bose then the Sony.
The Anker Soundcore has that ~5 second delay when trying to play again which I can see at 11:24:25.866 to 11:24:30.919 and 11:24:38.642 to 11:24:42.381
My mistake, you did need to wait. The extra logging is not in 4.50.7, it is in the build sitting in review, so this capture cannot tell me what your headset actually sent.
It did show something else though. Three seconds after you pause we let the audio device go idle, and both of your slow resumes start right after that. Can you try pausing and then hitting play again within a second or two, before that kicks in, and see if the delay disappears? That would tell me whether it is your headset taking its time to reconnect or us being slow to make a sound.
For the Anker Soundcore and the Bose it once again was a ~5s delay before I could initiate the play again, for the Sony WH-1000xm6 I had to press the play/pause button on the headphones twice, no matter if I did it twice quickly or with a pause of several seconds in between (the first one doesn’t get registered)
Looked through the logs a bit myself and I don’t think I see the new logs?
For the Bose there’s a pause at 20:20:02.049 and a resume at 20:20:06.646, during those 4 seconds I’ve pressed the play button once a second. Same between 20:20:11.807 and 20:20:17.914… So either 4.50.8 also doesn’t have the debug logs (and I have to wait for another version) or the events just aren’t processed by Plexamp it seems?
Progress, and it may be the same root cause as another report today.
The old app declared a media button receiver and the rewrite dropped it, which means a press only lands if we are the session Android currently considers in charge. When a Bluetooth route drops that is briefly not us, and the press has nowhere to go, which fits your dropped presses and the Sony needing a throwaway first one.
Fixed in the next beta. Worth a fresh capture once you have it.
Okay, just got 4.50.9 and the debug logs show a bit more info now!
Specifically, there are multiple “MediaSession: PAUSE from a controller” that match up with that 5 second window where it doesn’t start playing the song again.
Afterwards it gets one with “MediaSession: PLAY from a controller”
It also seems like the calls are offset? As in, in the logs it is longer than 5 seconds from the first pause to the play (18:16:14.704 to 18:16:23.764) but it was definitely less than 10 seconds of me pressing the button on the Anker Soundcore.
Also I only tested with a single Bluetooth device this time. You are saying there’s another rewrite that supposedly fixes it so I assume you were talking about 4.50.10 or 4.50.11, right?
That log had it. Every press you made in that window reached us, but as a pause, not a play: after you pause we keep the audio stream open for three seconds so a quick resume is seamless, and Android tells the headset we are still playing for as long as audio is flowing, so its button sends pause and we drop it since we already are. iOS got a 600 ms version of that years ago for the same reason and Android never did. Fixed for the next mobile build after 4.50.10; the receiver change you asked about is in 4.50.10 and only covers starting from cold, so it would not have helped here.
Unfortunately Google makes it such a pain in the ass, needs a lengthly review for open beta. The fix should be in 4.50.12 if I’m remembering correctly.
