Bugzilla – Bug 2405
Scan track order should have no influence on scanning result
Last modified: 2008-09-15 14:37:04 UTC
In DBIStore.pm, sub _postCheckAttributes tries to determine if the last album used is the same than the current track album. If not it searches the database to find it. Problem is the conditions used to check the cached album are not the same as the conditions used to search the DB. That means that adjacent tracks in scan order (whatever that is) may end up in the same album, but a change in the scan order (like a rescan) can relocate the track to another album! In particular, this applies to disc/discc and year.
Fred - are you running the latest subversion? I checked in a fix for cases like this last night. Do you have a reproducable case? Thanks.
SVN 4904 is an attempt at fixing some of the issues, in particular for DISC and YEAR. DISC is checked or not depending on the preference. YEAR should not be an album identifier, compilations in particular have different dates for different songs. Comments welcomed. I think this kind of behaviour may explain some of the parsing bugs still laying around. I did not check all cases, only the one mentioned above. If reasonable, then the logic could be applied to ALL caching done while scanning.
Latest trunk, updated a couple of hours before my path. It is easy to reproduce. Use 3 tracks, and play around changing album year and/or disc value using some ID3 editor (you do need to change the order of tracks, just the order of appearance of the values, which is the same thing really). For example: track 1 from 1997 disc 1, track 2 from 1998 disc 1, track 3 from 1999 disc 2 -> creates 2 albums with groupdisc off (as it should), but 2 abums as well with group disc on since on track 3 disc is checked without a care for groupdisc setting. Now change this to: track 1 from 1999 disc 2, track 2 from 1998 disc 1, track 3 from 1997 disc 1 -> creates 3 albums with groupdisc off (first album for the first track, then another one since YEAR is used when searching the DB for track 2 album, then a third one for the same reason: no 97/disc1). With groupdisc on, you get only 2 albums, because year is not checked in the cache between the last 2 tracks. If year is the same, then ultimately the group disc setting works, it's only that if it alternates 1,2,1,2, you search the DB each time instead of using the cache... If a single track has an iTunes disc==discc==1 in the middle (like I had), then it creates or not another album (groupdisc or not) depending on where it is (i.e. if cache or DB search reconciliation is used). I know for a fact rescanning does this because I've been catching this with my CLI test program for a while. Never found time to investigate until now.
Ooops: "you do need to change the order of tracks, just the order of appearance of the values," should read "you do NOT need to change the order of tracks, just the order of appearance of the values,"
Thanks - looks good.