Bugzilla – Bug 5985
Compilation column NULL for non-compilation MP3
Last modified: 2008-12-18 11:12:53 UTC
I've noticed that I get duplicated album rows in my database. On further investigation the reason for the duplicates was that the album was comprised of both MP3 and AAC tracks. The AAC tracks have a value of '0' for the compilation column, the MP3 tracks have 'NULL' in the compilation column. From within iTunes, where I have tagged the tracks, none of the tracks are considered part of a compilation. I don't think NULL should be allowed in the compilation column. (Note this does seem quite similar to bug 5209 but in reverse, wasn't sure whether this would count as the same thing) Can provide further details if required...
Steven to characterize this behavior and try to work out the 'right' thing to do.
One issue is that iTunes doesn't have a way of marking a file "not a compilation". It either includes the iTunes Compilation fram (TCMP) in id3v2 tags for compilations, or it deletes the frame on non-compilations. Coupled with the way SlimServer operates, by allowing three states (True/False/NULL) in the COMPILATION column and this what you end up with. The 'right' thing to do would be to always set COMPILATION to 0 when adding a new album to the database (unless you already know that it's a compilation) and then when the scanning pass is run that figures out whether albums are compilations, mark those that are with a 1. Then you have no NULLs. To be certain, add NOT NULL to the column definition for compilation in the albums table. See also comments 8 and 9 in bug 5108. NULL <> False, and I suspect SlimServer has to go to great lengths to treat them the same, with problems like this one being just one consequence.
so, am I to believe that we have a number of bugs that are this same basic issue: bug 5209 bug 5108 possibly bug 5725 if so, they should perhaps be merged so the discussion can be focussed. If not, then we should try to get more specific in the summaries so that the discussions won't end up crosslinked and redundant. I can't recall if there was an action item for someone to query Dan Sully about any possible reason for NULL (if we use defined 'compilation' as some sort of important test, that would be one reason. We'd need to find those cases anyway if there is any chance of switching to binary values.
If I remember correctly, compilation=null will allow SC to do its own compilation detection while compilation=0 or compilation=1 will override it. Let me see if I can find the bug.
Ah, here it is, change 4258 for bug 3322.
Steven, I think the problem is that there is an issue with leaving the DB as NULL for compilation. It makes sense that if we see NULL from metadata, that SC does it's own processing, but once processed is there any remaining need to keep the NULL? I think that's the question being asked here and in the other bugs. Me, I'm not sure why this is such a problem. NULL does mean empty, and it's used a lot in other cases where SC needs to know if something has been processed or not.
Thank you once again for your insightful comments KDF. So this particular issue is about consistency in SC. So SC uses NULL in the DB for MP3s without a compilation tag while it uses 0 in the DB for M4As without a compilation tag unless SC determines the files in question are a compilation based on other means. I looked at the tag data of the MP3s and M4As from iTunes and neither contain a compilation tag when set to compilation=no in iTunes. I don't have a strong opinion if the value should be null or 0, but it should at least be consistent. Andy, is this something you could look into?
Looks like iTunes does set CPIL to 0 for AAC files when the compilation flag is not set. I have changed MP4::Info to remove CPIL when it is set to 0, so it should work like MP3::Info now. Fixed in change 14979.
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.