GNOME Bugzilla – Bug 629162
Disc number 0 and 1 sorted differently
Last modified: 2011-10-24 00:15:49 UTC
Originally reported at: https://bugs.launchpad.net/bugs/483912 Binary package hint: banshee This happens with some of my albums, not all of them. On some albums, when I sort by track number ascending, track 1 appears at the bottom. This happens even if there are more than 10 tracks (i.e. track 1 is sorted below track 10). There is nothing special about the ID3 tags in the affected files that I can tell.
After looking into the database attached in Launchpad, it seems that problem is caused by the fact that some tracks in the same album have a different disc number: sqlite> select TrackID, AlbumID, Year, Disc, TrackNumber, Title from coretracks where trackid in (5927, 5928); TrackID|AlbumID|Year|Disc|TrackNumber|Title 5927| 484|2007| 1| 1|Sunrise 5928| 484|2007| 0| 2|Wait For The Summer As the disc number is used in the sort query, track number 1 ends up after track 2. I'll post this on LP too.
Confirmed on LP that disc number was the issue, so this is not a bug.
It kind of seems like our bug that we treat disc 0 and 1 differently.
What is disc 0 supposed to mean?
I'm not positive...I think it's intended to basically be the same as 1, except less explicitly so. One place it's set to 0 is in the transition from 0.13.2 databases. We should make sure it's not set to 0 anywhere else, change them to set it to 1, and then do a db migration that updates all the 0's to 1's.
Based on comments from the bug reporter, it seemed to have been a new import, rather than a migrated database. Perhaps when the disc number is 0 when importing, it should be reset to 1 as well?
(In reply to comment #5) > I'm not positive...I think it's intended to basically be the same as 1, except > less explicitly so. IMHO, I don't think so. Exactly in the same case as other fields, like track number, 0 just means that the data is simply empty. In fact, I have other old bug open requesting that Banshee should show empty spinbuttons when the metadata field is 0. This way the user knows if he edited this field on purpose or not (so it can be distinguished if a track has disc information or not). If you change all discs from 0 to 1 in a DB migration, you will assume that the metadata is there (essentially changing a "I don't know" to a "Yes" if asked the question "Is this the first Disc?").
It looks like there's an additional issue of looking at the year. It looks like an absent field causes the track to be considered to be in a different album.
(In reply to comment #8) > It looks like there's an additional issue of looking at the year. It looks like > an absent field causes the track to be considered to be in a different album. Chow, can you file that as a separate bug?
*** This bug has been marked as a duplicate of bug 575683 ***