the pause button on my bluetooth device doesn't work reliably

[CloudyCrayons]

Shuttle version:

v2.0.7-beta4

Device, OS:

Google Pixel 2 With Android 9 PIE

Description of bug:

the Bluetooth device i'm using are the Jaybird x3's. holding for skipping tracks and the volume buttons always work. but the pause\play button works rarely.

Steps to reproduce:

1. have music playing or paused
2. lock the phone and put the phone to sleep.
3. Press the pause button to start or stop the music
4. listen if the music started or stopped

Expected outcome:

pressing the button while music is stopped should start playback pressing the button while music is playing should halt playback

Observations/Actual Result:

generally only happens after a long time of listening to music with shuttle in the backround. this might be a side effect of androids aggressive backround power management when the phone is sleeping.

Restarting shuttle or disconnecting the Bluetooth device should temporarily fix it.

[CloudyCrayons]

reopening because I accidentally posted an issue with no description and closed it out of panic.

[raven-ie]

I have same bug on OnePlus 6T and Shuttle from google play store.

Observations:

• After some time pause no longer works.
• Pause can be reactivated by either opening app and pausing/resuming from app
• Pause can be reactivated by pressing next/prev song button two times (first time isn't always registered) then pause works fine as well.
• I have removed battery optimization for Shuttle and still didn't get expected results

[raven-ie]

Got the issue again and I was able to get control over pause. I can confirm that prev/next button suffers from the same unresponsive state. Unlike pause though the do work the second time you press.

Observations:

• Leave music playing for some time
• Press pause and observe that it's no longer working
• Press prev/next song and observe that they aren't working as well
• After initial prev/next button press they start to work along with pause

Edit:

• Noticed today that above 'fix' isn't always working.

[BreadBreadington]

Same issue with me more or less using the Anker Soundsync Drive.

Oneplus 6 Android 9 (OxygenOS 9.0.2) Shuttle+ 2.0.6

• Play/resume works without issues, but pause doesn't
• If another music app has played music recently (Stock music app/Spotify/etc) the play button on my bluetooth dongle will resume music with that app and not Shuttle+
• Prev/next song buttons work fine

[AlexanderOMara]

Experiencing the same behavior as @BreadBreadington with my Pixel 3 and Anker Bluetooth audio device. I do not have the issue with VLC, so I think it is Shuttle related.

[raven-ie]

I've noticed that gestures on 6T to pause/play music also doesn't work properly with Shuttle.

[Ahesselager]

I have a similar issue with my Bose headset and a Oneplus 6T - the pause/play button only works occasionally. I can find no real pattern to it. On my Oneplus 1 I had a 100% workaround with keeping the Shuttle app in focus when I locked the phone. My 1+1 ran LineageOs

[anotate]

Same issue here. Issue :

• All bluetooth controls work normally, excepted pause.
• Pause works fine on other apps but very rarely on shuttle+.
• The issue occurs on both my Bluetooth devices.

Phone : Lg g6 (h870) running stock lg oreo Bluetooth devices :

• Sony mdr-zx770bn,
• Anker soundsync

This issue didn't occur on my previous phone (lg g4 running stock lg nougat) despite using the same bt devices and shuttle+ version.

Edit : formatting

[raven-ie]

I've tested other music players and so far only Shuttle have this issue.

[timusus]

Can those reporting this same issue please mention the app version? @raven-ie @anotate @Ahesselager @AlexanderOMara @BreadBreadington

I'd also be interested in whether anyone can reproduce this in the production version (not-beta)?

[raven-ie]

It was happening in v2.0.7-beta4 and it still happens in 2.0.8. I'm on Shuttle+ production.

[Ahesselager]

My current configuration is a oneplus 6T with Oxygen OS 9.0.12 and shuttle version 2.0.8 upgraded

[mhammond]

I can reproduce the issue with both my bluetooth headset and the button on my el-cheapo wired headset. I can reproduce it in Android Studio with the current master branch. I'm on a Nokia 8 running Android 9. It reproduces reliably if I start the app, then switch to the "task manager" tiled view and swipe the app away - the button then fails to work until I manually "restart" it (although the process does remain running throughout.)

Sadly I only know enough Android to be dangerous, but I notice from the debugger that the process itself never terminates. When I swipe the app away, I see the main intent get destroyed as I'd expect, but I also see ResumingServiceManager.destroy() called - which I don't really expect (but as above, I don't know enough about this to be sure). When I click on the icon to "restart" it, I see the main activity restart and rebinding to the service, etc.

When it is in the non-working state, logcat does report the button press (eg:)

06-22 16:31:57.592  1372  3194 D MediaSessionService: Sending KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=0, downTime=0, deviceId=-1, source=0x0 } to com.simplecity.amp_pro.debug/Shuttle (userId=0)
06-22 16:31:57.603 12878 12878 V Avrcp_ext: recordKeyDispatched: KeyEvent { action=ACTION_DOWN, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=0, downTime=0, deviceId=-1, source=0x0 } dispatched to com.simplecity.amp_pro.debug
06-22 16:31:57.604 12878 12878 V Avrcp_ext: Player 8 package: com.simplecity.amp_pro.debug
06-22 16:31:57.607  1372  3194 D MediaSessionService: Sending KeyEvent { action=ACTION_UP, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=0, downTime=0, deviceId=-1, source=0x0 } to com.simplecity.amp_pro.debug/Shuttle (userId=0)
06-22 16:31:57.608 12878 12878 V Avrcp_ext: recordKeyDispatched: KeyEvent { action=ACTION_UP, keyCode=KEYCODE_MEDIA_PAUSE, scanCode=0, metaState=0, flags=0x0, repeatCount=0, eventTime=0, downTime=0, deviceId=-1, source=0x0 } dispatched to com.simplecity.amp_pro.debug
06-22 16:31:57.608 12878 12878 V Avrcp_ext: Player 8 package: com.simplecity.amp_pro.debug

But no matter where I set a breakpoint, nothing ever gets hit.

Please let me know if there's anything else I can do to debug, or even just offering me some clues as to what the lifetimes of the various services are expected to be might point me in the right direction.

[eisnerd]

I've got this working for me on Oreo and Pie, which have an extra "battery optimization" for background services. It may be leaking resources now, though, or reintroducing a pause button bug that gets a mention in the code comments. Further investigation is needed, but if any other devs watching this want to try it out and report back, that would be very helpful.

[mhammond]

That commit does appear to improve the pause behavior, but things still aren't quite right (eg, I can still reproduce "play" being ignored and other oddness). I'll get more specific details over the next few days, but thought I'd mention I'm having a play and still a little confused :)

[eisnerd]

Thanks for trying it out. Yes, I've also found it not completely reliable while I've been using it these last couple of days.

The main thing that's stopped it is using another media app or a call or something that takes audio focus. I'm not sure whether it's the focus, other media sessions or specifically when something starts handling media buttons. I think there's probably other things that stop it working, but this seems like a big piece of the puzzle.

[mhammond]

I'm becoming convinced #445 is directly related, but still trying to work out how...

[timusus]

@mhammond what makes you say that? I can't really think how/why this would relate to the dummy notification. That is really just an additional piece of functionality which doesn't change the behaviour of any other aspect of the app, as far as I can tell/recall.

[mhammond]

Yeah, it's not clear yet, but I suspect the bluetooth button behaviour and the notification lifetimes are somehow intertwined, but that that's probably just because I'm yet to get clear STR here. 1a59f45fc60b6a5a0b56abfc29fc95b91bc7fec5 definitely improves the "when paused" behaviour, although I haven't found the .release() necessary. It's a fun puzzle :)

[timusus]

I think they just seem linked because both are related to whether the service is running or not.

When the service isn't running, it's possibly not receiving bluetooth commands (though these should be handled by the system and forwarded to the service via intents, or otherwise via the media session). Absence of a notification is just a symptom of the service not running (or at least not running in the foreground).

[eisnerd]

It might not help to work out if they're related, but there's a good chance that they both have to do with the ever changing battery management systems, so I think it's a far out suggestion. Something like making a new media session whenever another app requests/releases focus or the service gets closed may be part of the solution.

[anotate]

@timusus Sorry for not telling you my version number earlier, I didn't see your question. I'm on 2.0.11 and can still reproduce the bug. I did some testing and it seems the bug goes away if you hit pause with the app in the foreground (by using bluetooth or the screen). The problem seems to occur when music is started from outside the app, while it's not running (by using bluetooth or a widget / live wpp). It won't occur if you start music while the shuttle notification is still there. While typing this I realised @eisnerd was probably right, and excluding the app from battery optimisation seems to make the bug go away, so thank you ! Mind you I only did like 5 minutes of testing right now but I wasn't able to reproduce the bug when I reliably could do it before.

[timusus]

@eisnerd you only register a media session when you have an active service handling media playback. It's not something you need to create when the app isn't running. I believe there is a simpler solution to this. The reason disabling battery optimisation helps is it just allows the service to live longer, which means it's still around to receive playback commands. This is only a short-term workaround - once the service is eventually destroyed, the same problem still exists.

I think the answer lies in figuring out why the Media Session isn't forwarding commands to Shuttle after it has been shut down, even when it is the most recently registered MediaSession. I'll need to dig into the MediaSession docs, but it may just be that Shuttle uses older API's. I think there might even be something you're supposed to register in the manifest now to tell the MediaSession you can be launched to handle commands - I can't quite remember.

[eisnerd]

According to the docs, all you need to do now is use MediaSessionCompat and not call .setMediaButtonReceiver(null) on it. I did read the docs when doing my initial investigation. I guess there's a chance that something (another BroadcastReceiver? MediaButtonIntentReceiver?) is conflicting with MediaSessionCompat and should be removed now that the support library handles this itself.

[mehulTank]

i am getting same issue i am developing app which is connected with blue tooth speaker after some time media button not get any action or intent in Media Receiver intent i am getting issue in samsung galaxy s 10 & s9

[mhammond]

After playing a little more with this, I think @timusus is correct and I was conflating a number of unrelated things. The largest issue I see with the bluetooth button is just that "pause" usually doesn't work. The MediaButtonIntentReceiver.java block referenced in 1a59f45 explicitly comments that pause will be ignored in some cases - and shuttle always seems broken (ie, we don't pause) when it is ignored. I've been running a custom build of shuttle with 1a59f45 applied (although without the .release() as that doesn't seem necessary) and it's been working well.

I don't quite understand the comment there - what problem is being solved by ignoring pause in that block, and how is the pause expected to be acted upon with that block in place? Or to put it another way, what regressions would you expect if that block was removed so that the pause command was never ignored?

[mhammond]

that "pause" usually doesn't work.

Sorry, I should be clearer here - it "usually doesn't work when the app itself isn't foregrounded" - I can offer reliable STR for it not working, but an unqualified "usually" isn't correct...

[mhammond]

My bi-annual checkin :) Should I abandon hope here?

[CloudyCrayons]

It is still happening to me. But maybe 1 out of 5 times.

[AlexanderOMara]

Same story for me too, same devices, latest Android update. Shuttle+ 2.0.12