View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0019708 | MMA | Playback | public | 2023-01-10 18:00 | 2023-07-27 16:55 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | unable to reproduce | ||
| Product Version | 2.0.0 | ||||
| Target Version | 2.0.0 | Fixed in Version | 2.0.0 | ||
| Summary | 0019708: MMA doesn't 'Always respond to remote buttons' (regression) | ||||
| Description | This was reported at https://www.mediamonkey.com/forum/viewtopic.php?t=103443 and I can replicate the bug as follows: 1 Disable battery optimization for MMA (just to rule it out as a variable) 2 Configure MMA to show in notifications bar for 0 minutes and enable 'Always respond to remote buttons' 3 Enable a bluetooth connection to a device with AVRC controls and play music 4 Press Pause and close MediaMonkey 5 Press the AVRC Play/Pause button --> Playback resumes 6 Press the AVRC Play/Pause button --> Playback stops 7 Close MediaMonkey & terminate the connection to the the AVRC device (stick it in a faraday bag) 8 Wait 15 minutes 9 Allow a connection to the AVRC device and Press Play --> In MMA 1.4, playback starts as expected (debug log: P54HNEMA1C) --> In MMA 2.0.1059, nothing happens (the user must initiate playback from the MMA app) R64ME7IMKB Both were tested on the same Pixel 2 / Android 12. | ||||
| Additional Information | A user reported a similar problem with Android Auto at: https://www.mediamonkey.com/forum/viewtopic.php?t=103646 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1072 | ||||
|
|
Fixed in build 2.0.0.1062 |
|
|
Verified 1062, with the test case above. This should also be tested further with: - 'resume play on connection' enabled - different vehicles - android auto |
|
|
Tested 1063 with 'resume play on connection' enabled. |
|
|
Retested on 1067 and when MMA isn't running in the background (because 'show in notifications bar' has expired), it fails to respond to BT buttons even if 'Always respond to BT buttons' is enabled). e.g. 1 Turn on Car and wait for BT to connect 2 Pressed 'play' button on the car stereo 4 times in stereo. No response. 3 Initiated playback on device --> playback works 4 Pressed play pause on car stereo --> buttons respond Log ID: 3VRTX6WPVL Description: MMA doesn't respond to BT buttons |
|
|
Please retest it with build 2.0.0.1068. I am not able to reproduce it. Btw. the log 3VRTX6WPVL is from build 1066 and not from 1067 |
|
|
Here's a debug log generated with build 1068. Log ID: HXJULSFBN9 Description: BT buttons don't work I'm not sure if this is a bug or not, though--when I test this particular device (Rav 4 Stereo), other apps don't respond to buttons either _unless_ metadata for the current track is loaded into the car's stereo, which only seems to occur concurrently with playback. i.e. it may be that for some devices such as this one, the only way to get a player to respond to BT controls is by initiating playback? I'm going to continue testing with other AVRC devices (that didn't experience this in the past) and see how they behave with 1068. |
|
|
I retested the original test case (that appears in the description) and it fails again in 1068 (though it passed in 1062). i.e. as originally described, MM doesn't respond to the AVRC BT Receiver/Controller even though 'Always respond to buttons' is enabled. Test track was 'The Record's flawed'. Debug log: 3UNRJQ1T2Z EDIT: the issue is related to the fact that this setting only seems to work when the 'Show in notifications bar' timer is active (despite the fact that the notifications player may not actually be displayed). e.g. if Show in notifications bar is set to 'Always' and Always respond to BT buttons is enabled, then this bug doesn't occur even after disconnecting the BT device for 15 minutes, and even though the Notifications Player disappears after 5-10 minutes (but if 'Show in notifications bar' is set to 30 seconds, then buttons to Play/Pause etc have no effect after even a few minutes). |
|
|
Fixed in build 2.0.0.1069 |
|
|
Tested 1609, and this setting no longer seems to have any effect, but MMA now seems to be responding to BT buttons consistently so that the functionality is less critical. i.e. If MMA is the last player used, it always responds to remote buttons, regardless of whether the notifications player timer has expired, and regardless of whether this option is enabled. BUT, if MMA is not the last player used (and the other player is configured to not aggressively respond to BT controls), then enabling this option doesn't cause MMA to preferentially respond to BT buttons. So, I'm re-opening this for 'urgent' evaluation (i.e. I think that it's no longer an 'immediate' issue, but that it should be reviewed on an 'urgent' basis. |
|
|
Tested build 1070 and although notifications player was set to always display and 'always respond to remote buttons', MMA failed to respond to BT play commands in the morning. i.e. 1 Configure the options described 2 Play music over a BT headset 3 Pause and then put away the headset 4 Wait 8 hours 5 Pull down notifications bar and then pull down quick settings in order to see hidden items --> MM appears in the system notification player 6 Re-connect the headset and press 'Play' --> MM fails to initiate playback Log ID: 7SJ5XBUBR5 |
|
|
This is mostly working on MMW 1071. Limitations are that: 0) If the user plays audio with another app, then MMA won't respond to bluetooth buttons. i.e. the 'fix' causes MMA to respond after it has been inactive for an extended period--but only if it was the last audio player to be used. e.g. 1 Enable 'always respond to remote buttons' 2 Play MediaMonkey to Bluetooth 3 Pause 4 Play Youtube to Bluetooth for a few minutes 5 Pause YouTube 6 Disconnect Bluetooth device 7 Reconnect Bluetooth device 8 Press Play on the Bluetooth device --> MMA doesn't respond! I don't think that this is a showstopper, though. But we may want to change: A) The default behavior so that this option is enabled by default since most users would expect that if MM was the last used player over BT then BT would work again when the BT device is reconnected. Since this is what the setting appears to do atm, would it make sense for it to be enabled by default? B) Since the setting doesn't cause MMA to _always_ respond to remote buttons, we might want to change tho wording. e.g. Responds to bluetooth or other controls even if another player was last used --> Respond to bluetooth or other controls whenever possible OR Respond to bluetooth or other controls even if app has been closed |
|
|
C) I just noticed another bug that I suspect may be related to the fix at ~71284 . Sometimes, unlocking the phone causes MMA to start playing for a fraction of a second. e.g. 1Navigate to the Playing queue 2 Press Play 3 Press Pause 4 Press the On/Off button to shut the screen 5 Unlock the device with the fingerprint sensor --> MMA Plays the current track for a fraction of a second! Debug log: M4Q8P5F6Y7 (89WJ4IHQH7 -- this instance occurred without Play & Pause) |
|
|
0) Fixed gain focus when Bluetooth connected if 'Always respond to remote buttons' is enabled(needs Bluetooth permission - user is asked on enabling if missing) A)If 'Always respond to remote buttons' is enabled then MMA will(should ) always respond. This is NOT a behavior that should be enabled by default. The last used player should respond and it's not related to BT. B) Fixed C) Fixed Fixed in build 2.0.0.1072 |
|
|
Verified 1073. i.e. 0) If this option is enabled, MM will open even if another app was played since MMA was last used. B) Verified string C) MMA no longer plays for a fraction of a second |
|
|
This issue seems to be occurring in build 1078. i.e. if 'Show in notifications bar' is set to 0, then MM will not respond to BT buttons after the device has gone to sleep, even if it was the last app used with the BT headset, and even if 'Always respond to remote buttons' is enabled. Tested with Pixel 5a / Android 13 / Volume leveling disabled / Auto-start disabled. Logs shared with MartinB. |
|
|
Unfortunately, after reverting to an earlier build (1076) and then upgrading to 1077 and 1078, I can no longer replicate this bug :-( Martin, please re-tag as resolved if the log doesn't provide any hints. |
|
|
Verified 1098 |
