View Issue Details

IDProjectCategoryView StatusLast Update
0015198MMANow Playingpublic2018-11-16 14:13
Reportermartin Assigned To 
PriorityimmediateSeveritymajorReproducibilitysometimes
Status closedResolutionreopened 
PlatformAndroidOS-OS Versionall
Product Version1.3.3 
Target Version1.3.3Fixed in Version1.3.3 
Summary0015198: Large "Now Playling" List Crashing (Samsung S8)
Descriptionhttps://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).
TagsNo tags attached.
Fixed in build835

Relationships

related to 0015137 closedmartin Android Auto: Browsing more than 500 Tracks, Artist, Albums Fail 
related to 0015202 closedmartin Low SafStorage performance on some devices causes ANR in Now Playing list 
related to 0015203 resolvedmartin Occasional failed update notifications 

Activities

rusty

2018-11-07 03:08

administrator   ~0051526

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)

rusty

2018-11-07 15:30

administrator   ~0051527

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.

rusty

2018-11-08 07:37

administrator   ~0051528

Last edited: 2018-11-08 15:21

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

martin

2018-11-09 12:46

developer   ~0051530

Fixed in build 1.3.3.835

rusty

2018-11-09 14:26

administrator   ~0051531

Last edited: 2018-11-09 14:34

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.

rusty

2018-11-10 23:03

administrator   ~0051533

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).

martin

2018-11-12 19:35

developer   ~0051537

Resolving, remaining issue moved to 0015202

rusty

2018-11-12 21:50

administrator   ~0051540

Re-verified build 837.