Bug 4150 - Duplicate album names, tracks not grouped correctly
: Duplicate album names, tracks not grouped correctly
Status: RESOLVED WONTFIX
Product: Logitech Media Server
Classification: Unclassified
Component: Misc
: 6.5b3
: All All
: P2 normal with 2 votes (vote)
: Future
Assigned To: Chris Owens
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-09-19 09:13 UTC by John Scudder
Modified: 2007-11-21 09:11 UTC (History)
5 users (show)

See Also:
Category: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description John Scudder 2006-09-19 09:13:00 UTC
Slimserver is treating tracks found in different directories as being in different albums.  Some of my albums, notably compilations, are spread out across multiple directories (by artist).  Slimserver presents these as N instances of the album title, each containing the tracks from one of the directories.

This bug is also discussed, with some possibly useful code analysis, in this post in the Beta forum -- http://forums.slimdevices.com/showthread.php?t=27424
Comment 1 Chris Owens 2006-09-19 09:27:24 UTC
Ross could try to reproduce this please?
Comment 2 Chris Owens 2006-09-19 09:27:43 UTC
cc'ing Dan as well
Comment 3 Dan Sully 2006-09-19 12:27:03 UTC
This works as designed.

Please put all tracks from a single album in the same directory.
Comment 4 John Scudder 2006-09-19 12:43:07 UTC
Regarding Dan's comment -- Forgive me, but this seems like a significant loss of functionality vs. earlier versions and "works as designed" doesn't seem like a good answer.  From my point of view, it renders 6.5b3 unusable.

There are any number of good reasons one might not want to put all tracks from one album in a single directory.  Some folks like to arrange their music by artist.  The poster in the Beta forum thread referenced in the bug description has another organization he uses (which is mysterious to me but it's his library, and to each his own).  In my case I'm fairly agnostic about how I organize my tracks -- but I have no desire to have to comb through every album I've ripped and rearrange them to suit slimserver's new behavior.  The point is that slimserver used to Do The Right Thing and not impose a particular directory structure, so many people will be blindsided by the new, more brittle slimserver if 6.5 is released without fixing this problem.

Is there some fundamental reason to insist on forcing a particular directory layout?
Comment 5 Dan Sully 2006-09-19 12:47:11 UTC
Yes - it's nearly impossible for everyone to have it there way.

We needed to pick a reasonable way of doing things that worked for most people, didn't create duplicates, works with multidisk and compilation albums, and doesn't exhibit the 'Greatest Hits' problem.

I'm sorry that you fall into the other category.

I've not closed this bug as 'WONTFIX', as there may be other ways to do this, but to be honest we've tried a lot of them, and this is the simplest and works the best.
Comment 6 John Scudder 2006-09-19 13:35:04 UTC
OK then.

I'm curious how you decided this works for "most people".  I'm pretty boringly mainstream in how I manage my library (or so I think).  I rip my music with iTunes and let iTunes put it where it likes.  Up until recent versions, iTunes didn't automatically set the "part of a compilation" checkbox when ripping multi-artist albums.  This means I have some unquantified but definitely large percentage of my almost 2000 albums spread across multiple directories.  Just the work of identifying which ones have been thus divided so that I can move them into the same directory (by checking the "part of a compilation" box) seems very unattractive to me.

One imagines that iTunes is a pretty commonly used ripper which would make me uncomfortable about the "most people" thing.  But maybe you have more data than I do.
Comment 7 Dan Sully 2006-09-19 13:40:25 UTC
The way iTunes used to do it, and the way your music is organized is what I consider broken. (No offense).

iTunes changed they way it organizes music in recent versions to stop scattering tracks from the same album into different directories.

Most music programs work this way, including recent versions of iTunes, MusicIP (MusicMagic), Winamp, MusicMatch, etc.
Comment 8 Bill Scott 2006-09-22 12:43:09 UTC
I experienced this same bug in an earlier version of SlimServer - I think it was around the upgrade to 6.0 or 6.1. - I exchanged some emails with tech support who told me the same thing, that I had put my tracks in the wrong place. I too had several thousand albums and couldn't face the thought of having to move them around. So I complained a bit more, and in the next release it was fixed. This saved my life at the time!

So imagine my horror to find it back again in 6.3.1.

Being busy, I just assumed someone else would find it and report it and it would get fixed quickly again. I've just downloaded 6.5 and was firstly mildly dissapointed to find that the bug is still there. Things got a lot worse when I read the trail of comments on this bug report....

I used to use Creative MediaSource to rip my tracks, and now I use iTunes. Both of those default to putting the tracks in a folder belonging to the artist, so that's where they went.

Surely, the only thing that should matter is the tag information embedded into each track? If the album name is the same, then the tracks should be grouped together, shuoldn't they. I did have two "Greatest Hits" albums, but fixed that problem by changing the tags - that was easy.

To Slim Devices - Please don't change the behaviour of SlimServer like this. It was working fine before and "if it ain't broke ...."

This is a major pain for lots of people. I love my Squeezebox and slimserver, but I will have to go back to 6.2. It just isn't practical to go and update all my compilations - I have a lot.

Regards
Bill
Comment 9 Bill Scott 2006-09-23 11:19:22 UTC
Further to this, I have just downloaded iTunes 7 (I was on 6 before) and have ripped a compilation. It does now put it into the Compilations folder, with the name of the album afterwards, so for compilations I rip from now on, SlimServer should treat them as one.

I estimate that I have at least 150 compilations that I have ripped over the last 3 years. If each compilation has 20 tracks then that's something like 3000 tracks I would have to move around to fix this problem.

I think that if you are going to change the behaviour of SlimServer in such a way that anyone who has used the default functionality of iTunes and Creative MediaSource to rip tracks now has a problem then there should be either an option to retain the old behaviour or some sort of utility to automate moving the tracks around.

I can see how the new behaviour is better and if I was starting out ripping now, I'd wonder what all the fuss was about and be very happy about this. But I'm not!

Please either return things to the way they were, add an option to have either the old or new functionality or provide some sort of program that could automatically group compilations into the same folder somehow.

Regards
Bill



Comment 10 Dan Sully 2006-09-23 17:04:17 UTC
Bill, if you tell iTunes to 'Organize your Music' again, does it do the right thing and put your compilations into the Compilations directory?

Unfortunately it's not as easy as 'just returning things to the way they were'.

The fixes we put in solve a host of problems for the 99% case. It's unforunate that you have been caught in that 1% case.
Comment 11 John Scudder 2006-10-07 14:13:22 UTC
Dan, in response to your question in comment #10, just telling iTunes to 'Organize your Music' again doesn't do the job.  The problem is that the "Part of a Compilation" flag didn't exist when the earlier rips were done, so it's not set, so iTunes won't organize the compilations into the Compilations folder.  The net effect of this is that one has to comb through one's library to set the flag wherever needed.  

I've posted to the forum thread http://forums.slimdevices.com/showthread.php?t=27424 with an Applescript which automates the process of setting the flag.  It may make this change somewhat less annoying for others.

BTW, I think that if you don't want to make the new "better" behavior optional as Bill suggests, the LEAST you could do would be to document the change so that others don't have the same nasty surprise he and I did.  I've combed through the release notes pretty thoroughly and didn't see a word about it.  Seems like basic code release hygiene to document this kind of major change.
Comment 12 Chris Owens 2007-10-22 09:32:21 UTC
Per Dean