View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0009795 | MMA | Playback | public | 2012-10-10 18:59 | 2022-03-12 18:48 |
| Reporter | rusty | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Target Version | 1.0.1 | Fixed in Version | 1.1.0 | ||
| Summary | 0009795: Initiating playback of large numbers of tracks sometimes yields NP list of only a subset of tracks | ||||
| Description | 1 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. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 320 | ||||
| related to | 0009794 | closed | martin | Play (shuffled) isn't completely random |
| has duplicate | 0009901 | closed | rusty | Now playing Appears to contain only one track |
| related to | 0009767 | closed | martin | Song queue when song selected from "track" |
| related to | 0011038 | closed | martin | Persisted Now Playing List initially displays the currently playing track only |
|
|
I can't reproduce, assigning to Martin to review whether it could have been fixed since... |
|
|
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). |
|
|
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. |
|
|
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. |
|
|
Fixed in build 1.0.1.0320 |
|
|
No issues 960 closing. |
