Bugzilla – Bug 4380
Scanner creates duplicates of the same album.
Last modified: 2008-12-18 11:12:53 UTC
There are 2 instances I've seen of the scanner behaviour in 6.5.x being different from 6.3 and creating a duplicate album entry where 6.3 would not have. 1) Where there are tracks from the same artist/album in different folders in the file system. Position on disk should not matter. Say I have music/u2/the joshua tree - and this folder contains tracks 1 - 5 and I have another folder music/u2/joshua tree - and this folder has tracks 6 - 10 Even though the taggin is correct, I'll end up with 2 Joshua Tree entries in the database. 2) I rip track 1-5 of a CD and perform a re-scan. I then decide that I like tracks 6-10. So, I rip these and they appear in the same folder as tracks 1-5 with the exact same album name/tagging etc. When I perform a re-scan (Look of new changed music) I end up with 2 entries for the same album with the tracks spread as they were ripped. So there seems to be some gaps where the scanner does not check to see if an album already exists for new tracks being added.
1. slimserver has to have albums in the same folder. 2. not sure how that should behave in design, so that might be something that shoudl be fixed.
Just some more info. One particularly stubborn set of MP3's were creating 2 album entries that are by the same artist with the same album name. I discovered that track 1 of the album had both ID3V1 & V2 tags which were slightly different. Tracks 2-10 had only ID3V2.3 tags. In both cases the server used the ID3V2.3 tags for it's artist and album name, but had determined that track 1 was from a different album based on it's ID3V1 album tag being different to the rest of the tracks.
Would it be possible for you to upload one of the affected files and attach it to the bug, Mick? In any case, the workaround (putting it here for other users if they search for this bug) seems likely to be straightforward: remove the conflicting id3v1 tag.
Created attachment 1664 [details] Track 1 of 2 These 2 files appear to come from different albums even though they're from the same one.
Created attachment 1665 [details] Track 2 of 2
Try taking out the 'Disc 1' tag from the David Gray track :)
I made both the IDv1 & IDv2 tags identical except for Song title, but the scanner still saw them as 2 different albums. BTW every other song on the album got grouped with David Gray. It was track 1 that it thought was different. So I had Album Name - Track1 Album Name - Track 2 ->10 Aslo the album name listed for both entries was identical. I think it was something in the APE tag. I end ended up bringing track 1 into MP3 tag and stripping all ags, then re-tagging it.
It's a difficult philosophical problem. We've taken a stand against EDITING users' tags. We try to guess how they intend us to use the tag data that's there. If there are conflicting tags, how do we deal with it? The bug database is full of bugs that when we try to guess one way, some users will pop up and make good points about us needing to guess the opposite way. If we add user options, our GUI gets complex and difficult to support. I'm interested, Mick. Do you USE the two tags for anything on purpose? Or are they just there as an accident of software you have loaded them into in the past? What behavior would you like to see? Just that Slimserver uses the highest version tag data?
Chris, The reason why I flagged this as a bug is because the behaviour of Slimserver has changed since 6.31. At the time, the 2 tracks appeared as part of the same album. I'm not really that interested in the IDv1 tags. But my issue is that even when I made IDv1 & V2.3 tags identical, I still got 2 albums created. I not sure what added the other data. I use MP3Gain and occasionally iTunes. The main issue is that the tracks I uploaded appear in the UI/Database as 2 identical albums by the same (in this case various) artists. Now maybe it's by design that you allow duplicate album names when albums are by Various Artists. There may also be instances of classical music tagged this way. But I think any other case is probably bogus or should be an option. If I have an album called The Josua Tree by U2 in my database twice consisting of track1 and tracks2->10 then something has gone wrong. As for each person having their own idea of how thing should work, the only way to fix that is to leave it to the user to decide on tag priority as a perference. Something like.... How should Slimserver treat files with multiple tags? Use the 1st of multiple tag is the following order - <Dropdown> ID3V2.x/IDV1/APE2/APE2 APE2/APE/IDV1/IDV2.x etc....
Okay, so maybe what I should test for primarily is generate a set of tracks with different kinds of tags, and different tags in use, but with the same artist and album, and check to see if they really get put into the same album.
I don't think you need to do what you're suggesting below. If you make the IDv1 & IDV2.3 tags in the tracks I uploaded identical, you'll still get 2 albums generated by the scanner. Also as an experiment, try ripping tracks 1-5 from an album. Do a "new & changed" re-scan. Now rip tracks 6-10 of the same album. Do an 2nd "new & chnaged" rescan. Do you end up with 2 albums? See the attached images of my 2 "James" greatest hits.
Created attachment 1690 [details] Images showing 2 entries for the same album in the Db
I don't get two albums when I do that, but it occurs to me what may be happening is the software you use for ripping may be throwing in a time stamp or job number into some tag field that we ought to ignore, but aren't. Dan, for the spec, does it seem reasonable that tags of different formats with exactly the same info and in the same directory should be made part of the same album?
*** Bug 4555 has been marked as a duplicate of this bug. ***
My problem sounds just like the first example in the original bug description: Some of my music albums are divided into two or more subdirectories for organizational purposes, although all the tracks share the same ALBUM tag value. In 6.3 and earlier, all of the tracks which had the same ALBUM tag were grouped together as a single album when browsing. When I upgraded to 6.5.1, I noticed that now each subdirectory is treated as a separate album, all with the same name. For instance, I have an album called "Short Trip Home" by Edgar Meyer. Tracks 1-9 are in "short trip home/1-9" and tracks 10-13 (a concerto) are in "short trip home/concert duo". When browsing through the web interface by artist, the Edgar Meyer screen includes: All songs Short Trip Home (1999) Short Trip Home (1999) The first link is tracks 1-9, and the second link is tracks 10-13. KDF noted that "slimserver has to have albums in the same folder". However, up through version 6.3 that was not the case. This behavior is new, and it screws up my filing system.
Chris, Not sure if any progress was made with this bug, but I'm not the only person experiencing it. http://forums.slimdevices.com/showthread.php?t=30555
Jim Zolx notes in bug 4531 that Guess Tags seems to operating even when there are already clear tags. I'm having someone look at it.
Please test again with SC7. Can you still reproduc?
No feedback in >1 year. Please feel free to re-open if you can reproduce the issue with the latest SC7 build.
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.