PDA

View Full Version : ALBUM in caps bug resurfaced



Christian Pernegger
2005-04-11, 13:55
Today I added "The Police - Live!" to my collection. I've tagged the
ALBUM as "Live!" in foobar2000, where it shows up correctly.
Slimserver sees it as "LIVE", though - i. e. all in caps and without
the ! at the end. Even recreating the db from scratch doesn't fix it.
(A similar bug has existed in prior 6.x version that capitalized the
album title when the album was added to the db via browse music
folder, but a wipe of the DB fixed it.)

At first I thought it was due to the !, but Jump Up! by Elton John is fine.

C.

narya
2005-04-11, 20:58
I've seen things like that as well: slimserver displaying information
that wasn't there in my ID3 v2.3 tags. I tracked that down to
differing ID3 v1.x tags in the files. After removing all v1.x tags
from my mp3 files (and leaving only the "real" v2.3 tags) and a "wipe
cache" all was fine again.

Alexander.

Christian Pernegger
2005-04-12, 00:51
> I've seen things like that as well: slimserver displaying information
> that wasn't there in my ID3 v2.3 tags. I tracked that down to
> differing ID3 v1.x tags in the files. After removing all v1.x tags
> from my mp3 files (and leaving only the "real" v2.3 tags) and a "wipe
> cache" all was fine again.

Those were flac files uning vorbis comments, but I found the culprit
anyway. Not sure why it does what it does, though.

Relatively early in the scanning progress slimserver finds an .mp3 in
my misc folder, with "ALBUM=LIVE", only later in the scanning process
it finds the Police album in question. As long as "Live" is included
popular album title which requires an artist match the .mp3 doesn't
show up in the same album as the Police .flacs but they still
"inherit" its title, including capitalization.

But why would slimserver assume the album titles to be the same in the
first place? One is "LIVE", the other is "Live!" At the very least
it's not case sensitive and even that would only explain it if the !
at the end of the second album's title either got stripped or if it
were determined by the directory name at this point, which is just
"Live" to avoid any special char problems.

I retagged the .mp3 to use "ALBUM=__LIVE" for testing and suddenly the
Police one came out fine, as "Live!" As sonn as I reverted it was all
"LIVE" again.

When's ALBUM read anyway, i couldn't find it in the --d_info output?

C.

michael
2005-04-12, 12:08
Christian Pernegger <pernegger (AT) gmail (DOT) com> writes:
....
> Relatively early in the scanning progress slimserver finds an .mp3 in
> my misc folder, with "ALBUM=LIVE", only later in the scanning process
> it finds the Police album in question. As long as "Live" is included
> popular album title which requires an artist match the .mp3 doesn't
> show up in the same album as the Police .flacs but they still
> "inherit" its title, including capitalization.
>
> But why would slimserver assume the album titles to be the same in the
> first place? One is "LIVE", the other is "Live!" At the very least
> it's not case sensitive and even that would only explain it if the !
> at the end of the second album's title either got stripped or if it
> were determined by the directory name at this point, which is just
> "Live" to avoid any special char problems.
>
> I retagged the .mp3 to use "ALBUM=__LIVE" for testing and suddenly the
> Police one came out fine, as "Live!" As sonn as I reverted it was all
> "LIVE" again.

It seems that internally the server matches things by their sort
order, which is case insensitive and ignores special punctuation and
the specified "ignore" articles. I suspect what you're seeing may a
result of that. One other bug I've seen as a side effect of this is
where an inconsistent tsop tag (sort order for artist) leads to
duplicate artist entries with the exact same displayed name.

I'm not sure exactly why it's done this way internally. Slimserver
does a lot of guessing to match individual songs to their respective
albums, which can be tricky when you get into various artist albums
and albums named things like "Greatest Hits", or in this case "Live".
Maybe this way of matching somehow made that easier, especially if
people have inconsistent tags? I'm just guessing here.

Perhaps slimserver needs a "competency" setting that means, "my tags
and my directory structure are consistent. Things in this dir belong
to the same album, and things elsewhere in my collection belong to
something else, and trust the displayed name of artist/album/track for
matching."

In the mean time, you should probably file a bug.

-michael

--
"Lately, the only thing keeping me from being a serial killer
is my distaste for manual labor." -dilbert

Simon Still
2005-04-12, 12:23
On Apr 12, 2005 8:08 PM, michael <michael (AT) fallenangel (DOT) com> wrote:
> It seems that internally the server matches things by their sort
> order, which is case insensitive and ignores special punctuation and
> the specified "ignore" articles. I suspect what you're seeing may a
> result of that. One other bug I've seen as a side effect of this is
> where an inconsistent tsop tag (sort order for artist) leads to
> duplicate artist entries with the exact same displayed name.

Something odd is going on - i'm getting two albums called XO by Elliot
Smith. One contains only track one, the other the remaining tracks.
I cant see any difference in the tags in iTunes (and Slim 5.4 was fine
with it). I've also seen the multiple artist entries but not withy
6.01

Christian Pernegger
2005-04-12, 12:25
> It seems that internally the server matches things by their sort
> order, which is case insensitive and ignores special punctuation and
> the specified "ignore" articles. I suspect what you're seeing may a
> result of that.

Sounds like it. I wouldn't even mind the matching if a track's tag
were displayed with correct case and punctuation. As it is, it just
uses the first "match" and uses that as value for the others.

> In the mean time, you should probably file a bug.

It seems quite deeply ingrained in the server, not trivial to fix at
all ... maybe I'll file it anyway.

C.

Christian Pernegger
2005-04-12, 12:27
> Something odd is going on - i'm getting two albums called XO by Elliot
> Smith. One contains only track one, the other the remaining tracks.
> I cant see any difference in the tags in iTunes (and Slim 5.4 was fine
> with it). I've also seen the multiple artist entries but not withy
> 6.01

Stop the server, move the .db away in case someone from SD wants a
look at it, and let the server recreate it from scratch. Worked for me
when I had this issue.

C.

Dan Sully
2005-04-12, 13:00
* Simon Still shaped the electrons to say...

>Something odd is going on - i'm getting two albums called XO by Elliot
>Smith. One contains only track one, the other the remaining tracks.
>I cant see any difference in the tags in iTunes (and Slim 5.4 was fine
>with it). I've also seen the multiple artist entries but not withy 6.01

Are you using iTunes importing and no Music Folder?

-D
--
"You can usually recover from production flaws...but you can never recover from a bad design".

superbad
2005-04-12, 14:36
Something odd is going on - i'm getting two albums called XO by Elliot
Smith. One contains only track one, the other the remaining tracks.
I cant see any difference in the tags in iTunes (and Slim 5.4 was fine
with it). I've also seen the multiple artist entries but not withy
6.01


That sounds like it might be related to bug 1318 (http://bugs.slimdevices.com/show_bug.cgi?id=1318). I'm not seeing duplicated albums, only artists, but it's definitely something new with 6.0.x and iTunes.

Simon Still
2005-04-12, 14:43
On Apr 12, 2005 10:36 PM, superbad
<superbad.1neakn (AT) no-mx (DOT) forums.slimdevices.com> wrote:

> That sounds like it might be related to bug 1318
> (http://bugs.slimdevices.com/show_bug.cgi?id=1318). I'm not seeing
> duplicated albums, only artists, but it's definitely something new with
> 6.0.x and iTunes.

that sounds like it. The newer tracks were ripped with EAC, the older
with iTunes.