View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012887 | MMA | Playback | public | 2015-10-08 15:03 | 2015-12-18 03:05 |
| Reporter | rusty | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.1.3 | ||||
| Target Version | 1.1.3 | Fixed in Version | 1.1.3 | ||
| Summary | 0012887: Bluetooth stutters on playback | ||||
| Description | User is reporting BT playback stutters consistently on an S5. Debug logs at: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=82467#p414887 Please triage. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 508 | ||||
|
|
In the Log YAGY8ZBO7X I can see as last record: 10-07 18:24:35.396: W/com.ventismedia.android.mediamonkey.player.PlaybackService(0): Trim memory: TRIM_MEMORY_RUNNING_MODERATE[onTrimMemory():1069] Maybe some phone low power mode causes it, but I don't know why, because we are using PowerManager.PARTIAL_WAKE_LOCK. Any idea? |
|
|
We agreed that we will try to release resource in playback service. I.e. we will clear bitmap caches that will release big amount of memory. Next time we can try to move playback service to separate process to allow releasing application resources. But there might be some drawbacks. More info here: http://mindtherobot.com/blog/37/android-architecture-tutorial-developing-an-app-with-a-background-service-using-ipc/ Fixed in build 484 |
|
|
Users are still reporting that this occurs in build 496: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=82887 This report includes debug log. JTS-677-64379 RDD-598-99102 HRD-725-70402 I've also been able to replicate the problem on occasion: Short break in playback occurred while playing 'Smalltown Boy', about 10 seconds from the end of the track (shuffle was enabled). Debug log: MV442HEJ0K |
|
|
Added developer options to test it(build 1.1.3.500). To get "Developer options" user must click the 'MediaMonkey icon' in the 'About MediaMonkey dialog'. |
|
|
Seems that issues were caused by 1)Progressbar in notification which must be refreshed each second - resolved by added new option in Options(also removed from Developer Options): Hide progressbar in notification/miniplayer -You can hide progressbar to avoid stuttering or reboot issues. Is text ok or should be formulated differently? 2)other app which user had installed (NewsOn) Fixed in build 1.1.3.506 |
|
|
Adding a config option for this isn't a solution. Other apps that implement a seekbar presumably don't crash/stutter. Isn't there a way to actually fix this? |
|
|
Other apps has no progressbar in notification. The issue is that progressbar must be updated every second and it causes stuttering. On other hand it seems happend only on some devices(none of mine). So I see the option as good solution. Maybe I can also increase update time to 2 seconds to be less demanding. |
|
|
Another solution can be set progressbar Hidden as default, because it causes other issues like 0012963 or 0012946. |
|
|
OK, so how about: [ ] Show seek bar in notifications Displays playback status in the notifications drawer (beta) Note: - it should be disabled by default - '(beta)' should be a separate string so that if it's fixed in Android, no string modifications are required Also, I assume that you found that the 'Album art' and 'reboot fix' options on the developer options are not related to this? |
|
|
OK, please clarify: What do you mean if it's fixed in Android? I think it doesn't depend on android version. I think it's device specific issue. Note: Should be "seek bar" in the title, not "progress bar"? Because user can't seek in notification, he is only informed about progress. |
|
|
Summary: - removed 'Album art' and 'reboot fix' options - added "Show progress bar in miniplayer" in DeveloperOptions, which is enabled as default (I think that issue cause progressbar in Notification only) - added "Show seek bar in notifications" in Options, which is disabled as default Disabling progressbar in notification definitely solves issues 0012963 and 0012946. About stuttering it seems that the issue is fixed besides one user(JTS-677-64379). 1) http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=82467#p416307 fixed by disabling progressbar 2) http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=82887#p416379 fixed by uninstalling other app (NewsOn) 3) ticket RDD-598-99102 stuttering - fixed by disabling progressbar, but some skip issue remains. I will check new logs. 4) ticket JTS-677-64379 still getting stuttering, this is when playing through his car stereo |
|
|
Re. '(beta)' being a separate string, I meant that if the issue is somehow resolved, then there's no need to rely on translators to update all of the various strings--we can just get rid of it ourselves. Re. 'seek bar' vs progress bar: in other parts of MMW and in documentation, it's always referred to as a seek bar. Re. 'Show Progress bar in miniplayer': are you saying that you believe that 0012963 and 0012946 are probably solved by turning off the seekbar in the notification bar by default, but that you're leaving this as a developer option just in case it isn't always resolved and we want users to try disabling the progress bar in the miniplayer as well ? |
|
|
Re '(beta)'- ok Re 'seek bar' - ok Re. 'Show Progress bar in miniplayer': The original option was disabling both notification and miniplayer and it solves these issues. However I think that just disabled notification seekbar is sufficient, but I am not sure, so users can also disable miniplayer seekbar in Developer options separately(enabled by default). |
|
|
Strings updated 1.1.3.508 |
|
|
re 4) ticket JTS-677-64379 - Issue on Android side for device Nexus 6P http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=68820&start=135#p410784 confirmed by user (also stuttering on PowerAmp, GoogleMusic is exception) |
|
|
Fixed in build 1.1.3.508. |
|
|
Verified 525 BT headunit |
