View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005894 | MMW v4 | Conversion/Leveling | public | 2009-07-29 15:04 | 2013-01-10 08:19 |
| Reporter | rusty | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | open | ||
| Product Version | 3.1 | ||||
| Target Version | 4.1 | ||||
| Summary | 0005894: Auto-added Playlists for ripped tracks are out of sequence | ||||
| Description | When the user rips a CD, tracks are ripped in sequential order, however, the auto-added playlist that is created (assuming 'Create Playlists of newly added Tracks' is enabled) is not in the correct sequence. e.g. for a CD with 13 tracks, the playlist will be in the following order: Track# 2, 3, 1, 4, 6, 5, 7, 9, 8, 10, 12, 11, 13 | ||||
| Additional Information | Reported by Dave L. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
I guess this is side effect of newly added feature to utilize multiple CPU cores for ripping. i.e. on quad-core the tracks are ripped per groups consisting of 4 tracks that can be out of order depending on how fast they are ripped. Solution could be just sort each this auto-added playlist according to following order: Artsist, Album, Track#. So far the tracks are sorted according to the time when they had been added to library. |
|
|
Yes, due to multiple CPU cores encoding the tracks are really technically ripped in this order. We could somehow resolve this by adding tracks to the playlist only after the whole conversion is done, but I'm not sure whether it's the best solution, I'd probably slightly prefer to leave the unsorted. Rusty? |
|
|
Leaving them unsorted looks sloppy and is clearly a bug. We should fix it, but I'll leave it to you to set the priority. |
|
|
The more I think about it, the less options for a change I see. The point is that the tracks really _are_ added to Library in this order, i.e. the playlist is properly sorted according to Date Added column. Any attempt to 'fix' this would result in some other side-effects, e.g. we would defer adding tracks to this playlist and so tracks already in Library wouldn't appear for some time in this playlist. So, I'd either close the issue or somehow defer it, just in case we find out some way how to change it. |
|
|
Reduced priority and set target to 4.0. This really should be fixed if possible. |
|
|
Solution could be to use suggestion from 0005215 to add "Date Added" and rename "Added" to "Time Added". And then use "Date added" to sort this according to following sort rules: [Date added, Artist, Album, Track#] (sorted according to the priority). |
|
|
Seems to make sense--it would also fix auto-playlists that look at date added but should disregard time as part of sort order. |
|
|
Note that this playlist isn't an auto-playlist, so we can't simply define its sort order. We can, however, insert tracks into the playlist according to such an order - i.e. manually set playlist position of a newly inserted track. Note that we have to think about time complexity of the solution, as there might be thousands of tracks added during this step. |
|
|
And wouldn't it make more sense to implement it as Auto-Playlist? i.e. Recently Added Tracks -> Auto-Added 2009-12-01 would be auto-playlist, but Recently Added Tracks -> Added 2009-12-01 17:36 would be simple playlist as is currently. |
|
|
Seems to make sense. Note that we probably should add a DB index for this field then. |
