PDA

View Full Version : Slimserver seems to break albums by genre



jezbo
2008-01-16, 14:56
If I have one album, but the songs are tagged with different genres, slimserver seems to create two or more different albums, one per genre. Is there any way I can have it ignore genre in album accumulation ?

jezbo
2008-01-16, 15:02
Oh hang on, it may be breaking it because the files are split across directories - I've seen some other threads on this. Is there any resolution to this yet ? Cos I don't see why it has to be so:

Arrange albums by:
Artist Name + Album Name

Except when the compilation flag set, then arrange by:
Album Name only

No need to arrange by directory name.

So, two artists with "Greatest Hits" albums are separated correctly, multiple artists on the same album are also grouped correctly (when the compilation flag set).

radish
2008-01-16, 16:04
I can think of two problems:

1) Your suggestion requires COMPILATION to be correctly set. I would expect that to be less commonly done in most people's libraries than keeping to a 1 album per directory model. EAC, for example, doesn't have a way of setting COMPILATION.

2) What if I have two different compilations with the same title?

jezbo
2008-01-17, 10:39
1) So make it an option - everyone's happy.

2) Can you think of two compilation albums with exactly the same title?

amcluesent
2008-01-17, 10:47
>2) Can you think of two compilation albums with exactly the same title?<

Lady Sings the Blues

nolesrule
2008-01-17, 10:55
EAC, for example, doesn't have a way of setting COMPILATION.

No, but you can pass the tag to an encoder using the additional command line options, at least for something like FLAC. I explicitly set the compilation tag to 0 for all albums, and then manually change it when I am tweaking tags on compilation albums.

kdf
2008-01-17, 13:06
1) So make it an option - everyone's happy.


some, not everyone. for example:
-QA who have to test every option

-Support who have to keep track of every option and it's effects when helping customers diagnose an issue

-Developers who have to continually track each option, and it's effects throughout the code any time some aspect of the feature changes, or have to replicate each option on the ever increasing interface paths (jive, cli, http, playerUI) and have to make each option act take effect immediately and completely.

- Last but not least, Users - Those who are confused by the massive number of options and those who discover that their take on the option is that some other case is missing, or find that in fact the effect isn't immediate and they end up waiting for a scan. Also, the users who feel that the wrong option has been made the default.

I'm not trying to enter a debate, or block the progress, but the idea that changes of this kind are simple doesn't properly address the reality of the issues.
-kdf

jezbo
2008-01-17, 16:59
Whole-heartedly disagree.

I'm a developer myself, and our happiness is not the issue, a product must be flexible enough to satisfy the majority of customers. Making some rule rigid so that it only satisfies half the customers, even if it makes things simpler, is not good practice. And the rule of thumb on introducing a new option - make what it did before the default.

As it is, I won't be using the SlimServer web interface since browsing of albums is such a pain; I'm writing my own interface that builds it's own database. I'll have to put up with duplicates in browsing via the remote I suppose.

snarlydwarf
2008-01-17, 17:20
Whole-heartedly disagree.

I'm a developer myself, and our happiness is not the issue, a product must be flexible enough to satisfy the majority of customers. Making some rule rigid so that it only satisfies half the customers, even if it makes things simpler, is not good practice. And the rule of thumb on introducing a new option - make what it did before the default.

Making a rule more rigid so that it works better for 99% of the customers and keeps code more consistent is better, though.

I doubt 50% of customers separate an albums tracks by genre. I doubt it is even 1%.

A ton of customers Just Work with the dropping of Common Album Names and the must-be-same-album-if-in-same-directory code. Common Album Names sucked.



As it is, I won't be using the SlimServer web interface since browsing of albums is such a pain; I'm writing my own interface that builds it's own database. I'll have to put up with duplicates in browsing via the remote I suppose.

It would be much easier to modify the scanner to do as you want. Then it would work consistently across the web and remote interfaces.

Robin Bowes
2008-01-17, 17:34
snarlydwarf wrote:

> A ton of customers Just Work with the dropping of Common Album Names
> and the must-be-same-album-if-in-same-directory code. Common Album
> Names sucked.

Agreed. I don't think it's an unreasonable requirement that tracks from
the same album are in the same directory.

R.

radish
2008-01-17, 17:41
I'm a developer myself, and our happiness is not the issue

Depends on whether you're paying said developers ;)



As it is, I won't be using the SlimServer web interface since browsing of albums is such a pain; I'm writing my own interface that builds it's own database. I'll have to put up with duplicates in browsing via the remote I suppose.

Or you could just reorganize your directory structure...I know which I'd rather do :)

Robin Bowes
2008-01-17, 17:58
jezbo wrote:
> Whole-heartedly disagree.
>
> I'm a developer myself, and our happiness is not the issue,

Correct. The customers much be happy, which most are.

> a product must be flexible enough to satisfy the majority of
> customers.

Which it does.

> Making some rule rigid so that it only satisfies half the customers,
> even if it makes things simpler, is not good practice.

No, but making a rule rigid so that the product is more satisfactory to
the majority of customers is very good practice.

Keeping customers happy is not always about giving them what they ask
for - sometimes they need to be educated as to the "right" way to do things.

R.

jezbo
2008-01-18, 14:20
Forget genre - that turned out not to be the issue, but the folder location of the files is.

I doubt I'm in a 1% minority. True enough, most of my real albums are stored in the same directory (except when I have downloaded one or two tracks then later downloaded the rest of the album on the strength of those), but I also like to collect tracks together and tag it with the same Album name so that it will appear as an album eg. "Mozart" is the artist, "Concertos" is the album - and these are rarely if ever in the same folder (and I don't want to have to move them - iTunes wouldn't find them).

slimkid
2008-01-18, 14:29
... but I also like to collect tracks together and tag it with the same Album name so that it will appear as an album eg. "Mozart" is the artist, "Concertos" is the album - and these are rarely if ever in the same folder (and I don't want to have to move them - iTunes wouldn't find them).

What I do in such situation is:
Artist: Mozart
Album: Mozart: Concerto for Clarinet in A Op. xxx
Genre: Classical; Concerto; Clarinet
Album Artist: Joe the Clarinetist

Track: Concerto for Clarinet in A - 1. Allegro
Track: Concerto for Clarinet in A - 2. Addagio
.....

so, as long as the tracks from the same album are in the same directory this works fine.

jezbo
2008-01-19, 11:04
It would be much easier to modify the scanner to do as you want. Then it would work consistently across the web and remote interfaces.

How would I go about doing that ?

dcote
2008-01-21, 01:33
hi jezbo!

i find this issue also mightily irritating, so i opened an "enhancement request" in bugzilla at:

http://bugs.slimdevices.com/show_bug.cgi?id=6208

if you are in the same camp, you may want to vote for the enhancement.

more votes = more people want this = higher likelyhood of it being implemented! ;-)