View Issue Details

IDProjectCategoryView StatusLast Update
0009795MMAPlaybackpublic2022-03-12 18:48
Reporterrusty Assigned To 
PriorityhighSeverityminorReproducibilityalways
Status closedResolutionfixed 
Target Version1.0.1Fixed in Version1.1.0 
Summary0009795: Initiating playback of large numbers of tracks sometimes yields NP list of only a subset of tracks
Description1 Open playlist of 900 tracks
2 Play all (shuffled)
3 Immediately switch to NP List view
4 Scroll down
--> The NP list ends after ~ 30 tracks!!
5 Switch to a different view and then back to NP list
--> The NP list includes all the tracks that should be there

This same bug also occurs when clicking a track in the Tracks view.
TagsNo tags attached.
Fixed in build320

Relationships

related to 0009794 closedmartin Play (shuffled) isn't completely random 
has duplicate 0009901 closedrusty Now playing Appears to contain only one track 
related to 0009767 closedmartin Song queue when song selected from "track" 
related to 0011038 closedmartin Persisted Now Playing List initially displays the currently playing track only 

Activities

jiri

2012-10-10 20:03

administrator   ~0032395

I can't reproduce, assigning to Martin to review whether it could have been fixed since...

rusty

2012-10-14 02:00

administrator   ~0032535

Last edited: 2012-10-14 02:57

Further investigation shows that the bug isn't specific to playback--it also occurs when the user switches to a Playlist view with a large number of tracks (without initiating playback).

The problem goes away by waiting several seconds after switching to the view with the large number of tracks, so it would seem to be a performance issue (though I wonder if might be somehow related to 0009678 , since like that issue, this bug is specific to the NP>List and Playlist views).

jiri

2012-10-23 13:45

administrator   ~0032744

Decreasing priority, since this actually isn't a bug, but rather a performance problem.

Note that there probably won't be any much better solution available, since loading that number of tracks really takes some time. This kind of slowness is reproducible in other apps as well, even though in a different context due to different app logic and design. E.g., an attempt to re-order large playlist in Music app results in loading the playlist fully to memory - which takes quite a significant time on slower devices.

rusty

2012-10-23 14:48

administrator   ~0032748

Note: to clarify, the problem isn't specifically the performance--It's that the UI gives no feedback re. the fact that the list is still loading. i.e. when the user looks at the list and scrolls to the bottom it appears that the list is fully loaded because MM doesn't appear to be adding more tracks to the bottom of the list OR show an indicator that the list is loading.

A simple fix would be that the last entry in the list displays 'loading...' until the list is fully loaded.

martin

2014-09-04 13:56

developer   ~0040469

Fixed in build 1.0.1.0320

peke

2022-03-12 18:48

developer   ~0067260

No issues 960 closing.