View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0014201 | MMA | Playback | public | 2017-04-25 14:20 | 2018-07-27 14:45 |
Reporter | martin | Assigned To | |||
Priority | immediate | Severity | major | Reproducibility | sometimes |
Status | resolved | Resolution | fixed | ||
Product Version | 1.3.0 | ||||
Target Version | 1.3.1 | Fixed in Version | 1.3.1 | ||
Summary | 0014201: MMA stays active due to MediaBrowserServiceCompat | ||||
Description | http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=87578 http://www.mediamonkey.com/forum/viewtopic.php?f=26&t=87592 In some cases if PlaybackService is browsable, then BT device can browse content i.e. http://www.ventismedia.com/mantis/view.php?id=13643 There is strange behavior that service stay binded also when BT device is disconnected (e.g. car radio) until BT service will be off. In this case our PlaybackService must be stopped in usual way(onDestroy is not called in this case) | ||||
Tags | No tags attached. | ||||
Fixed in build | 701 | ||||
related to | 0013643 | resolved | martin | Provide more nodes via MediaBrowserServiceCompat (re. Android Auto) |
related to | 0013575 | closed | martin | Support for Android Auto |
related to | 0013319 | resolved | martin | Android wear - NP list browser |
related to | 0013961 | resolved | martin | BT: Track not updating on Car head Unit |
related to | 0014988 | resolved | martin | MMA should display directory contents / playlist contents over bluetooth |
|
Fixed in build 1.3.0.695 |
|
No regressions 695 |
|
Martin, can you please look into this further? A user has indicated that the issue still occasionally occurs: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=87578 |
|
User uploaded a debug log to the forum thread at http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=87578#p435947 |
|
From the log I can see client com.google.android.wearable.app is binded to MMA (it means browsing tracks from AndroidWear). Until the client is binded,playback service can't be destroyed and stays awake. It means issue is not on MMA side. Fixed browsing for AndroidWear devices in 1.3.0.700 |
|
All logs have same cause, some external client is binded to our PlaybackService to browse content (client can be e.g. AndroidWear, AndroidAuto or some BT device). When I was testing, sometimes client was bluetooth service. I mean bluetooth device was disconneted already, but bluetooth service was still binded as client until I turned off Bluetooth completely. When MMA had "Playback notification" displayed until last client unbinded, then user thinks that auto-closing doesn't work. Otherwise user reports that mma drains battery. What about add new notification when playback is inactive longer then limit and clients are connnected e.g. "Remote clients connected to MediaMonkey" "MediaMonkey is not able to be closed until remote clients are connected to browse its content" "Possible clients are Android Wear, AndroidAuto, Bluetooth devices etc." What do you think? |
|
I have added Notification to next build 1.3.0.700. The notification appears when PlaybackService should be stopped, but it's not possible due to browsing content by remote client. Notification disappear when playback service stops or starts again due to some playback action. Finally I have modified Notification text. Browsing MediaMonkey content Last connected client %s Let me know what do you think? You can test it e.g. with AndroidAuto or AndroidWear. |
|
Maybe there should be possibility to disable this notification in Options, what do you think? |
|
a)The problem is external to MMA It depends on behavior of system android.media.browse.MediaBrowserService which seems to vary based on device and the application controlling MMA (this system service binds to MMA service to browse MMA content by other application/devices). b)Notification does not resolve problem, but let user to know that some other app browses MMA content. Until other application/device browses MMA content, MMA is not able to be stopped. Notification 'Last connected client %s' helps to user to identify what was browsing MMA content. To explain the problem further, when Android Auto or Android Wear are controlling MediaMonkey, expected behavior is observed i.e. if the user stops playback in the controlling app then MediaMonkey auto-exits. e.g. I)Android Auto 1)Run android auto 2)Choose MMA as Player 3)MediaBrowserService is binded to MMA client "com.google.android.projection.gearhead" 4)so Android Auto app is able to browse MMA content, until Android Auto is runnning or until another player is chosen, MMA(One service only) is active. II) AndroidWear 1)initiate playback from MMA 2)PlaybackNotification with track Metadata on AndroidWear appears 3)User can browse MMA content from watch by click on "Browse" action 4)MediaBrowserService is binded, client is "com.google.android.wearable.app" 5)Until user returns to metadata screen on watch MediaBrowserService is binded. However, in the case of Bluetooth, there are unfortunately cases when MediaBrowserService stays bound without an obvious reason--though the problem is device-specific. e.g. III) Bluetooth 1)Turn on Bluetooth 2)pair with SBH 50 3)initiate playback 4)MediaBrowserService binded 5)pause playback On Samsung S5 mini Android 6 (problematic behavior) 5)client packageName "com.android.bluetooth" 7)MediaBrowserService stays binded until bluetooth is disabled - THIS IS ISSUE -> MMA stays active 8)After playback inactivity playbackService fails to stop beacuse MediaBrowserService is still binded -> SHOW NOTIFICATION to inform users (In this case user have to turn off/on bluetooth) On MOTO G5 plus Android 7 (expected behavior) 6)client packageName "com.google.android.wearable.app" 7)MediaBrowserService unbinded after a while 8)No problem here From the logs I also saw that MediaBrowserService stays binded when client was "com.google.android.wearable.app". Because the problem is not on the mma side, I think displaying notification is the only thing what we can do. |
|
Unfortunately, I still don't understand how notifying the user 'Last connected client %s' solves the problem. As far as I can tell, it would just be annoying to have a notification appear that is essentially an error message. I've never seen the notifications drawer used in this manner. From my perspective, the only real solutions are: a) to prevent this from happening if the user exits MMA and/or stops playback (in which case auto-termination rules should kick in) b) to give the user the ability to terminate MMA via an Exit function I also wonder why we're receiving these reports now and not with previous versions of MMA. It implies to me that something (e.g. related to changes in Bluetooth functionality) in MMA has changed triggering these issues. Note though: if we decide that we still want to keep a notification, I would expect that it should at least be functional. e.g. keep the player controls/metadata, but add an indicator showing what is causing it to display (e.g. Bluetooth symbol, Android wear symbol). |
|
GOOD NEWS, I have reviewed all debug logs from users, all of them have Samsung devices and for all it's caused by "com.android.bluetooth" (one of it had also client "com.google.android.wearable.app", that's why I thought it can be caused by different client, but not) finally I have found something about it https://stackoverflow.com/questions/39454127/why-is-package-com-android-bluetooth-querying-our-mediabrowserservice-on-samsu WOW GREAT: if MMA returns null for client "com.android.bluetooth", then MediaBrowserService unbound immediately. THIS SOLVES the issue. So I removed notification to next build. Fixed in build 1.3.0.701 |