Bugzilla – Bug 1704
"Greatest Hits" Albums confused
Last modified: 2008-08-18 10:54:16 UTC
FC3/SB2/V6.1 (on Subversion) In a db of approx 670 albums / 10,000 songs I have 5 albums tagged as "Greatest Hits". Slimserver is running with "treat multi-disc albums as a single album" selected. Slimserver appears to confuse Bruce Springsteen & INXS (because they have the same date of 1994?) giving me 1 album with 36 songs by 2 artists. I assume this could also be a problem for other albums with the same title and same (or blank?) date. Possible solution: Songs on Greatest Hits/Best Of etc albums must match artist as well as title (and date) to be combined in a single item.
Your suggestion is what we *should* be doing today (check out the Server Settings > Behavior > Common Album Titles). The tracks in the two albums don't share a directory, do they?
"The tracks in the two albums don't share a directory, do they?" No - tracks are all organised Artist/Album/Track No_Track Name Actually even the Year tags are different: Bruce Springsteen\Greatest Hits\ files tagged 'Rock' '1995' INXS\The Greatest Hits\ files tagged 'Rock' '1994'
If I understand, you do have other albums that are also called "Greatest Hits" that are being listed separately, correct? Any chance I could get a copy of your slimserversql.db file? It may be too large to attach to the bug report, so you may have to put it up on a web server. Let me know if you can do that. If not, I may be able to arrange something.
"If I understand, you do have other albums that are also called "Greatest Hits" that are being listed separately, correct?" Yes that's right - it's just "The Greatest Hits"/INXS and "Greatest Hits"/Bruce Springsteen that are combined and appear as "Greatest Hits"/INXS - I don't know if the "The" is significant in the bug. 'find' doesn't find a slimserversql.db file on my FC3 server. Whereabouts is it?
~/.slimserversql.db or /usr/local/slimserver/Cache/.slimserversql.db or look at /etc/slimserver.conf and find where the cachedir is set. it will be .slimserversql.db under that dir.
Forgot it was hidden. It's 15MB and I have a web-site limit of 10MB so hosting's a bit of a problem. I'll try and email it to you.
Turns out that Bugzilla is OK with large attachments. Feel free to attach to the bug.
The limit is 10MB for attachments. Is there any other way I can get it to you (email bounced)?
Patrick, can you give it one more try. Dan just tweaked the maximum. Thanks!
No - still won't take more that 10MB
try zipping/gzipping/bzipping the file first. my 12mb db file, bzipped, goes down to 2.5mb.
Created attachment 609 [details] zip of .slimserversql.db
Do you know, I thought I'd tried that and it didn't make any difference. I must have been crosseyed or something! So (hopefully) here it is at last.
Aha...there's a problem in our logic. The INXS album title is "The Greatest Hits". It doesn't match the "common album titles" test because of the article "The"; hence, we don't also try to match on artist. When we actually look for a match, we ignore the article and hit the first "Greatest Hits" - Bruce Springsteen. I'm looking at possible options to fix this.
Created attachment 634 [details] possible fix The attached patch tries to find an album match based on the original album name, not the normalized (case-folded, articles removed) version of it. With this change, the INXS album will get its own, separate album object. This seems to make sense, assuming correct tagging, but I'm a bit wary of checking it in so close to a release. Can anyone think of a reason why we should match on the normalized name, as we're doing now, rather than the original version?
Will this work if you have two "The Greatest Hits" albums - with different artists? Not that I have, but somebody will ...
It will, if you add "The Greatest Hits" to your Server Settings > Behavior > Common Album Titles setting.
Sounds good to me.
Patch committed in change 3717.
This is fixed for me - many thanks.
This bug was marked resolved in Slimserver 6.1, which is several versions ago. If you're still seeing this bug, please re-open it. Thanks!