Bugzilla – Bug 6208
compilations albums should not show up duplicate due to directory structure
Last modified: 2011-03-09 07:41:19 UTC
when slimserver finds tracks from the same album in different directories it treats them as if they were on different albums. please see: http://forums.slimdevices.com/showthread.php?t=39863. i find this behavior unexpected and also strange - i personally think the tracks' tags should be the ONLY instance used to decide if a track is part of the same album or not. since previous bug reports (https://bugs-archive.lyrion.org/show_bug.cgi?id=4150) were closed due to "works as designed", i would now like to file a change request: please add only one additional control, which will tell slimserver to "guess" track properties based on: -> directory structure + filenames only -> tags only (! this is the important/new one !) -> both (apparently the current behavior?) -> (any other criteria you may feel necessary) this should make squeezecenter more independent and flexible when it comes to individual's directory structures.
This would be a reversion in behaviour and a return of the "greatest hits" bug. no thanks.
Changing the current behaviour would be a huge step back to where we were pre v6.5. Adding even more settings that influence album grouping and artist listing easily leads to a support nightmare. The current behaviour is very straight forward and the one album per directory directive seems logical for most people.
Given the different approaches to library organization, I think this is a reasonable request if it's doable. One of the settings for the pref would be to use the old behavior. With the choice up to the user, that in and of itself isn't a reversion. Yes, it trades one 'bug' for another, although neither behavior is a bug, just the limitations of each in uniquely identifying albums when there's insufficient data. The abrupt change in behaviour was (and still is) its own support nightmare.
Seems like a reasonable power user feature, though the default behavior should _not_ change. Will look at again post-7.0.
I'm still using 6.3.1 because of this new "feature". I have about 4000 classical albums, a majority of which are multi-CD sets (opera, box-sets). I store each CD in its own folder; that's just part of my workflow with EAC. Slimserver I believe is the only piece of software that uses the directory to determine which album a track is part of. (I've use ITunes, MediaMonkey, Windows Media Player, Gigabeat player).
>I'm still using 6.3.1 because of this new "feature". I have about 4000 >classical albums, a majority of which are multi-CD sets (opera, box-sets). >I store each CD in its own folder The "bug" being reported here is only an issue if albums are stored with songs NOT in the same folder (eg. for compilation albums, where each song may have been stored under a different artist folder). If you have all songs in the same folder, you shouldn't see any change in functionality. For people who do have album songs distributed in different folders, they can add COMPILATION=0 to attempt to force songs together into one album, but as various people have said here, it all leads back to the "Greatest Hits" problem. I see no reason to provide an option to go back to the old functionality, as this didn't function well anyway. If you have two albums with tracks in different folders, then the songs were all merged into one album. There is no way to stop that happening with the old functionality, other than disambiguate the album name.
philip, my issue is not with with _two_ albums in different directories, but with _one_ album in different directories. example: my GF has an album called: artist: Wolfsheim album: Casting Shadows directory: ..\GF's music\.. i have: artist: Wolfsheim album: Casting Shadows directory: ..\my music\.. this is historic: we were not always a couple and we prefer(red) different tracks from the same album, so only those were ripped. merging all of these together is impractical, because she (as my GF) dictates what is easy for her to use (happens to be itunes), whereas i detest itunes. result: songs must stay in separate folders. dont ask - it is just "a case of the way it is". having _two_ artists, both called "wolfsheim", which are actually the _same_ show up is totally illogical to both of us. worse: when selecting one or the other from the "artists" menu on the SB3, we never really know which tracks we will be listening to: hers or mine. if we want to listen to _all_ wolfsheim, we always have to select _both_ wolfsheims... sorry guys, we both fail to see any logic in this system whatsoever. we still think a simple checkbox which will toggle SC's behavior is both simple and obvious.
>philip, my issue is not with with _two_ albums in different directories, but >with _one_ album in different directories. My comment #6 was in reply to comment #5. In response to your problem, there must be some other issue that is causing this? You shouldn't have two artists with the same name, no matter what. I bet this isn't the case. If you Browse Artists, do you really see two artists with exactly the same name? Multiple albums of the same name (one for each artist) is probable, and the option you are asking for would not necessarily help you. Your "Casting Shadows" album should be listed as one album by one artist, even if some tracks are in different folders. If this is not the case, it's simply a bug in my opinion. The problem comes when you have albums with the same name but are different albums by different people. eg. the songs for "Greatest Hits" by Queen in one folder, and "Greatest Hits" by Squeeze in another folder should not be merged together into one folder. You wouldn't want that to happen, otherwise you'd end up with a single compilation album called "Greatest Hits" containing songs by both artists. So, the use of the directory structure to disambiguate this is required (otherwise the only solution to fix the "Greatest Hits" problem would be to rename album tags where the name is not unique). But the directory structure should only disambiguate albums by different artist names, not when the artist name is the same.
so many wonderful logics... dominique, i take it that when you see the same artist twice, its also in the webui under home > albums, yes? or is it ONLY on the SB3? i'm just trying to ascertain what you're seeing where... you might want to post some files to the bug so slim can try to recreate it.
here is a _simple_ example. note that it does not even use a compilation, but rather a regular album! in this example: artist=Underworld album=Beacoup Fish directory=.\music\mp3\. and artist=Underworld album=Beaucoup Fish directory=.\music\ogg-vorbis\. this results in the album "Beaucoup Fish" showing up twice in the SC web UI and on our SB3s. as far as i can tell, the artist and album tags on all tracks are identical, but SC still insists on listing "Beaucoup Fish" twice. please also see this thread: http://forums.slimdevices.com/showthread.php?t=39863 which i posted a while ago. note also that the "black soul" example i used in the thread has also been manually eliminated/merged, as per slimpy's suggestion in the thread.
Created attachment 4390 [details] search results for underworld
Created attachment 4391 [details] search results for beaucoup fish
Created attachment 4392 [details] after clicking "underworld", i get beaucoup fish twice
Created attachment 4393 [details] these are the tracks in the "one" album beaucoup fish
Created attachment 4394 [details] these are the tracks in the "other" album beaucoup fish
Created attachment 4395 [details] directory + file structure for the "one" album
Created attachment 4396 [details] directory + file structure for the "other" album
Created attachment 4397 [details] foobar shows that all tracks have identical album + artist tags
sorry, just noticed i forgot some important information: SqueezeCenter Version: 7.2 - 22900 @ Tue Aug 26 10:59:02 PDT 2008 - Linux - EN - utf8 Server IP address: 192.168.0.102 Perl Version: 5.8.8 armv5tejl-linux-thread-multi MySQL Version: 5.0.27 Platform Architecture: armv5tejl-linux Hostname: Turbonas Server Port Number: 9001 Total Players Recognized: 2 this machine is running SSOTS 3.15 and qnap turbonas firmware 2.1.0 Build 0904T. Player InformationName: Bedroom Model: Squeezebox v3 Firmware: 112 The IP address for this player is: 192.168.0.5:30510 The Ethernet MAC address for this player is: 00:04:20:07:4e:dc Wireless Signal Strength: 62 however, this problem has been around for as long as i can remember, at least since SS/SC version 6.x.
sorry for spamming this thread, but a thought just occurred to me. why not let SC use other tags to "disambiguate" (i like that word) as well? if SC used album AND artist (and/or composer, album artist, etc.) to disambiguate, the problem would be gone, no? because then artist=Queen album=Greatest Hits and artist=Squeeze album=Greatest Hits would obviously not be identical, no matter what their paths are.
>why not let SC use other tags to "disambiguate" (i like that word) as well? >if SC used album AND artist (and/or composer, album artist, etc.) to >disambiguate, the problem would be gone, no? No, SC can't tell if tracks by Queen and tracks by Squeeze should be merged onto one compilation album called "Greatest Hits". It has been suggested that additional information, such as examining the track numbers, could be used to determine if tracks should be merged into one album or appear as different albums. The rules would be too complicated to work out (or indeed explain) to people, and would appear even more like guesswork. It would also be a change that would affect other people's libraries that are also working well with the established scanner logic. eg. a compilation album "Greatest hits of the 80's", with track 1 by Queen, track 2 by Squeeze, etc. In this case, artists with tracks sharing the same album name are expected to be merged into one compilation album. If the tracks are in the same folder, the scanner will assume they are all part of the same compilation album. If they are in different folders, they are assumed to be different albums by each artist.
ok - got that. still not helping me tho... my GF spent years using itunes, which also arranged her music in the same way (see the thread i mentioned). after copying that repository in to my SC, we now have myriads of albums showing up multiple times. if itunes is somehow capable of distinguishing (i am only assuming this, since i refuse to use itunes) tracks properly, surely SC can replicate that, right? it seems that people are telling me that i must completely re-design my ~7500+ track repository according to SC's requirements? sounds strange to me, i am used to a software doing what i want, not vice-versa... there is a major reason i do not want to re-design my repository: we make extensive use of playlists. changing the directory structure will break them all. not an option, since we both spent the equivalent of many, many man-days putting these lists together. asking her to repeat the procedure with me will not help to improve the GF-approval rating! this bug has 6 votes, which is not a huge amount, but still significant and indicates that there is some urgency here. surely that merits putting some thought into this? and last but not least: is the effect above with the beaucoup fish album normal? if not, should i file a bug-report? (this here is only an enhancement request)
iTunes doesn't really have a concept of albums, artists, etc, as separate browsable lists. Just a grid containing names, that you can filter and sort by columns. Depending how you sort, you get the data presented in different ways. eg. I have some music loaded into iTunes: "Greatest Hits" by "Queen" "Greatest Hits" by "Lenny Kravitz" "Greatest Hits" by "The Cure" In iTunes, if you sort by album, where the track numbers and album names match these appear as multiple albums for each single track. i.e. one album for the first song by Queen, one album for the first song by Lenny Kravitz, one album for the first song by The Cure, one album for the second song by Queen, etc. As I have more songs by Queen than on the other Greatest Hits albums, tracks 18-34 appear grouped together as another "Greatest Hits" album. Sorting by artist works better. SC has a proper relational database that holds lists of artists, albums, songs, etc. This has many more benefits, but means there must be more permanent relationships between artists, albums and songs when the information is scanned. Artists relate to Songs, which relate to an album, and an album relates to an artist, etc. To work out what songs are on an album, requires some logic. Tags alone cannot answer that question, if the album names are not unique. Songs that should be part of a single album, but that appear in different folders is a fringe case that is not the standard way of organising music that is required by SC, without giving more information. You can try adding COMPILATION=0 tags. This is an easy thing to do using a tagger, such as Mp3Tag, to mass-tag your non-compilation albums that are spread over several folders.
i understand the general issue now - thanks for the detailled (and simple) explanation! :-) it does not help me/us to solve the problem. as far as i can tell, there seem to be three options to resolve this (short of modifying SC with a radically new sorting/grouping algorithm): 1. i must re-arrange all 7500+ songs in our entire repository. 2. we simply live with it. 3. i try some kind of alternative tagging scheme (as you suggested), which will positively identify tracks that belong to the same album. but here are the caveats: a. if i perform 1.), all our playlists will break. and we spent literally days putting them together - they include tracks which we both like from her and my collection. doing that again is not really an option. (unless someone knows a utility which can search for moved tracks and update their paths in an m3u playlist?) b. living with it means listening to my GF's nagging "itunes is much better and easier and didnt do this weird stuff...", greatly reducing her acceptance factor. logic (such as explaining to her itune's very rudimentary sorting/grouping and that it is technically inferior to SC) will not work - she is used to clicking two or three buttons max to start playing her selection. the technical reasons are of no interest and consequence to her, she just needs it to WORK. fast. easy. c. option 3 seems most likely. i will have to find a day or two of time to try some schemes out. i can see where this is going though - there will be no fix to this in the near future. so as far as i am concerned, this thread can be closed.
where is the new_schema keyword? also, Dom, 8.0 should fix it, or so i think. its listed as a block.
Brandon: Have you considered this for 8.0?
Dominique, should this bug now be closed? it sounds to me like you couldn't put all your files for one album into one folder, so you were subjected to the "greatest hits logic." the suggested workaround seemed to be that you use comp tags to get items from the same album listed as one album by SBS. did that work for you? if so, can the bug be closed or are other issues remaining?
honestly guys - do i/we have a choice? ;-) in all seriousness now, i still feel it is a bug or at the very least a significant functionality and usability impairment. but to be honest, the priority is not as high as it used to be when i first filed this bug. my GF and i have changed our usage habits with the SBs so that we now rarely play albums or artists directly, we mostly select saved playlists and internet radio. we also dont use itunes anymore, so any new additions to our repository are done the "right" way. keeping that in mind, we aren't noticing this issue anymore. that doesnt mean others don't... but as far as i am concerned, you can close this bug.