View Issue Details

IDProjectCategoryView StatusLast Update
0005894MMW v4Conversion/Levelingpublic2013-01-10 08:19
Reporterrusty Assigned To 
PriorityhighSeverityminorReproducibilityalways
Status assignedResolutionopen 
Product Version3.1 
Target Version4.1 
Summary0005894: Auto-added Playlists for ripped tracks are out of sequence
DescriptionWhen 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 InformationReported by Dave L.
TagsNo tags attached.
Fixed in build

Relationships

related to 0005215 closedLudek MMW 5 Implement sort by DATEAdded (not DateTimeAdded) 

Activities

Ludek

2009-08-03 10:17

developer   ~0018608

Last edited: 2009-08-04 16:07

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.

jiri

2009-08-13 07:07

administrator   ~0018630

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?

rusty

2009-09-16 05:00

administrator   ~0018843

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.

jiri

2009-09-16 09:05

administrator   ~0018846

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.

rusty

2009-09-16 13:47

administrator   ~0018847

Reduced priority and set target to 4.0. This really should be fixed if possible.

Ludek

2009-10-08 12:23

developer   ~0019096

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

rusty

2009-11-24 18:02

administrator   ~0019763

Seems to make sense--it would also fix auto-playlists that look at date added but should disregard time as part of sort order.

jiri

2009-11-27 16:07

administrator   ~0019793

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.

Ludek

2009-12-01 16:43

developer   ~0019811

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.

jiri

2013-01-10 08:19

administrator   ~0034354

Seems to make sense. Note that we probably should add a DB index for this field then.