View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015198 | MMA | Now Playing | public | 2018-11-06 16:41 | 2018-11-16 14:13 |
| Reporter | martin | Assigned To | |||
| Priority | immediate | Severity | major | Reproducibility | sometimes |
| Status | closed | Resolution | reopened | ||
| Platform | Android | OS | - | OS Version | all |
| Product Version | 1.3.3 | ||||
| Target Version | 1.3.3 | Fixed in Version | 1.3.3 | ||
| Summary | 0015198: Large "Now Playling" List Crashing (Samsung S8) | ||||
| Description | https://www.mediamonkey.com/forum/viewtopic.php?p=451634#p451634 Based on discussion with Martin, this issue was caused because of the overhead associated with filling the MediaSession queue (implemented at 0015137 in order to better support Now Playing lists in 3rd party clients such as Android Auto / Wear). Since the MediaSession queue is regularly updated (even in the absence of a 3rd party client), the problem always occurs when the user is playing extremely large e.g. >6000 tracklists. Possible solution would be a new option: Limit Now Playing for external apps Displays <x> tracks of the Now Playing queue in 3rd party apps such as Android Auto. [20, 200, [400], 800, 1000, 2000, 3000] Note: - for the value x chosen by the user, MMA should display: previous 20 tracks, playing track, x-20 upcoming tracks - if the user chooses 20, then the optimal approach of filling this queue with old cached tracks can be used - 400 is proposed as a default since 0015137 results in a default scenario in which browsing in Android Auto shows 0 tracks, except in Now Playing, so it's important that Now Playing show a well-populated list - I've proposed using a new setting since the existing setting 'limit list for 3rd party apps' has a limit that's device-dependent, and it's likely that users may want to have a much larger NP list if it's possible (e.g. for Android Auto) or a much smaller NP list (if they're using Android wear). | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 835 | ||||
|
|
Fixed instead through optimization. This should fix 1) crash (precisely ANR) 2) same speed as in previous versions However, with large playlists, some delays can be expected re. populating tracklist etc. (MMA is limited by SQL execution time) |
|
|
Per user feedback, although playback (and metadata display of the playing track) of a long tracklist starts after a couple of seconds (as previously), the player remains unresponsive for several minutes to skipping track/seeking. The play/pause does work during this period. |
|
|
I'm able to replicate the problem re. the delayed functionality of the Prev/Next/Seek functions. 1 navigate to Tracks (appx. 3800 tracks in list, all on the SD card of an Honor 5x) 2 tap the 3rd track to initiate playback --> song starts playing 3 tap prev/next or move the seek bar --> UI responds in 45 seconds Note: This doesn't happen on subsequent operations i.e. it only occurs immediately following step 1 (the addition of tracks to the NP list). Debug log: JHMPI7FZKJ Note: performing the exact same steps with MMA 1.3.2 --> UI responds in <1 second |
|
|
Fixed in build 1.3.3.835 |
|
|
The original issue (back/next/seek after loading large NP list) seems to be fixed. However, there seems to be a couple of other issues in build 835: 1) Empty Now Playing list appears briefly 2) Cases of tapping tracks in the Now Playing list not responding These are described below. 1 navigate to Tracks (appx. 3800 tracks in list, all on the SD card of an Honor 5x) 2 tap the 3rd track to initiate playback --> song starts playing 3 immediately tap 'NP list view' --> An empty 'Now Playing' list briefly appears, soon replaced with the correct list (issue 1)! 4 immediately scroll down the list and tap songX to initiate playback --> MediaMonkey doesn't respond, and sometimes shows 'MediaMonkey is not responding: Close | Wait' dialog (issue 2)! --> After about 10-15s SongX starts playing -->Debug log: 6CJ7UQJ1BZ Note: this issue occurs about 50% of the time. Also, although I originally thought that the bug only occurs when step 4 is performed immediately after loading the NP list (steps 2/3), I'm able to replicate the problem on occasion as follows: 1 navigate to Tracks (appx. 3800 tracks in list, all on the SD card of an Honor 5x) 2 tap the 3rd track to initiate playback --> song starts playing 3 Switch to Now Playing list and Pause playback 4 Let device go into sleep mode 5 Resume playback by clicking a track in the Now Playing list 6 Tap an earlier track in the Now Playing list --> MediaMonkey doesn't respond, and sometimes shows 'MediaMonkey is not responding: Close | Wait' dialog (issue 2)! --> After about 10-15s SongX starts playing -->Debug log: 8LNUA8QR8J I'm not able to replicate this particular version of the bug consistently, but I have replicated it several times. |
|
|
The issues seem to be mostly resolved in build 836, but I can still sometimes replicate the problem of tapping now playing tracks failing to respond: 1 navigate to Tracks (appx. 3800 tracks in list, all on the SD card of an Honor 5x) 2 tap the 3rd track to initiate playback --> song starts playing 3 immediately tap 'NP list view' 4 immediately scroll down the list and tap songX to initiate playback --> playback works Repeat step 4 several times sometimes scrolling up, and sometimes scrolling down --> About 5% of the time, MediaMonkey doesn't respond, and sometimes shows 'MediaMonkey is not responding: Close | Wait' dialog (issue 2)! --> After about 10-15s SongX starts playing -->Debug log: PPBWVK6BRC A second instance of the problem: 2Q9RGSHX72 (this one occurred only after 3 tries--perhaps it's related to the fact that I allowed the device to go to sleep and then tried to replicate the problem). |
|
|
Resolving, remaining issue moved to 0015202 |
|
|
Re-verified build 837. |
