PDA

View Full Version : sorting (ignoring "the" and case insensitivity)



Phillip Kerman
2005-05-16, 12:13
When I sort by artist, I see both:
Sisters of Mercy
The Sisters of Mercy

I thought that was supposed to be ignored as per "server settings > behavior
>Articles to ignore when sorting artist names"


Also, I get:
ABBA
abba

as two separate artists.

SlimServer Version: 6.0.2 - 3077

Please advise.

Thanks,
Phillip

kdf
2005-05-16, 12:27
Quoting Phillip Kerman <lists (AT) phillipkerman (DOT) com>:

> When I sort by artist, I see both:
> Sisters of Mercy
> The Sisters of Mercy
>
> I thought that was supposed to be ignored as per "server settings > behavior
> >Articles to ignore when sorting artist names"

the settings is just as it says: it ignores for sorting purposes. They shoudl
still be listed as tagged.

> Also, I get:
> ABBA
> abba
>
> as two separate artists.

they are different. slimserver has no way of knowing which tags are wrong and
which case it should then change to.

Best thing to do, find and fix the appropriate tags, also check if these exist
in cue sheets or in EXTINF tags in playlists.

-kdf

JJZolx
2005-05-16, 12:35
When I sort by artist, I see both:
Sisters of Mercy
The Sisters of Mercy

I thought that was supposed to be ignored as per "server settings > behavior
>Articles to ignore when sorting artist names"


Also, I get:
ABBA
abba

as two separate artists.

SlimServer Version: 6.0.2 - 3077

Please advise.

Thanks,
Phillip

I think the key phrase there is "ignore when sorting". The two strings for the artist names differ, so SlimServer calls them different artists. If you look at the track table in the database that SlimServer keeps you'll see a separate column used only for sorting purposes - with all punctuation removed (why?) and in all caps.

I've been pretty careful tagging files (as you're pretty much forced to, given the unforgiving nature of SlimServer's cataloging), so I was unaware of the case sensitivity issue. I find it hard to believe that it was implemented like this on purpose. I can understand that if the underlying dbms is case sensitive then it can require some additional work to see these as the same artist. This should be done, though.
________
Yamaha FJ1100 (http://www.cyclechaos.com/wiki/Yamaha_FJ1100)

Simon Still
2005-05-16, 13:06
On 5/16/05, JJZolx <JJZolx.1p53on (AT) no-mx (DOT) forums.slimdevices.com> wrote:
> I've been pretty careful tagging files (as you're pretty much forced
> to, given the unforgiving nature of SlimServer's cataloging), so I was
> unaware of the case sensitivity issue. I find it hard to believe that
> it was implemented like this on purpose. I can understand that if the
> underlying dbms is case sensitive then it can require some additional
> work to see these as the same artist. This should be done, though.
>

I've got worse problems than that - tracks on the same album ripped by
itunes vs EAC/Lame are seen as being on two different albums and the
tags are identical as far as i can see. I've even renamed them all to
the same.

JJZolx
2005-05-16, 13:19
I've got worse problems than that - tracks on the same album ripped by
itunes vs EAC/Lame are seen as being on two different albums and the
tags are identical as far as i can see. I've even renamed them all to
the same.

You might try a mass tagging application (I use mp3tag, which despite its name, works well on my flac library) and retag the problem files.

http://mp3tag.de

The way I look at it, SlimServer 6 is still in its infancy. The cataloging problems are admittedly much lower priority than are the bugs that affect playback and system stability, so I can live with jumping through hoops to get SlimServer to behave the way I want. I'd expect to see many of these issues resolved as the software matures, though.
________
medical marijuana grow (http://growingmedicalmarijuana.org)

Phillip Kerman
2005-05-16, 14:44
> > Also, I get:
> > ABBA
> > abba
> >
> > as two separate artists.
>
> they are different. slimserver has no way of knowing which
> tags are wrong and
> which case it should then change to.
>


Why can't slimserver be case insensitive? Seems easy enough technology
wise.

Thanks,
Phillip

kdf
2005-05-16, 14:55
Quoting Phillip Kerman <lists (AT) phillipkerman (DOT) com>:

> Why can't slimserver be case insensitive? Seems easy enough technology
> wise.

and would you be happy if slimserver then chose Abba as the standard display?
or should all artists be all caps so that you get ABBA no matter what? Server
prefs perhaps, but then what if you have a mix? Do you want to waste resources
having slimserver processing everything by looking it up from cddb so that the
proper case is used? What is the point of tagging if the server is expected to
twist it all magically into something that isn't in the tags?

Why can't you fix your tags?

-kdf

JJZolx
2005-05-16, 15:32
and would you be happy if slimserver then chose Abba as the standard display?
or should all artists be all caps so that you get ABBA no matter what? Server
prefs perhaps, but then what if you have a mix? Do you want to waste resources
having slimserver processing everything by looking it up from cddb so that the
proper case is used? What is the point of tagging if the server is expected to
twist it all magically into something that isn't in the tags?

Why can't you fix your tags?

Display the first one returned by the query. You're right in that SlimServer has no way of knowing which is "correct". If the string displayed doesn't sit right with the user, only _then_ should he have to fiddle with the tags. The display question is less important than the idea that SlimServer should be case insensitive when it comes to deciding what to consider a distinct artist, album, etc. I can't think of a reason (maybe someone will give one) where you'd want "abba" to be considered different than "Abba". If there's no good reason to keep the current behavior then it should probably be changed to operate as most people would expect.

I'll make the same argument that the articles dropped for sorting purposes should also be dropped for the purposes of determining distinct artist names. "The Grateful Dead" should be equivalent to "Grateful Dead" and shouldn't require someone to retag files just to get that behavior.

As far as implementation goes, there's already a case insensitive column with the leading articles removed in the 'contributors' table ('namesort'), so why not just do lookups on that column in the SQL statements when cataloging tracks or when browsing by artist? Display the mixed case 'name' column.
________
volcano digital vaporizer (http://vaporizer.org/reviews/volcano)

Phillip Kerman
2005-05-16, 20:22
> > Why can't slimserver be case insensitive? Seems easy
> enough technology
> > wise.
>
> and would you be happy if slimserver then chose Abba as the
> standard display?
> or should all artists be all caps so that you get ABBA no
> matter what? Server
> prefs perhaps, but then what if you have a mix? Do you want
> to waste resources
> having slimserver processing everything by looking it up from
> cddb so that the
> proper case is used? What is the point of tagging if the
> server is expected to
> twist it all magically into something that isn't in the tags?
>
> Why can't you fix your tags?


Naturally, I can fix my tags. If this fix made the server come to crawl
then I'd say a) don't bother and b) what sort of funky design would really
cause this to make the server slow down? Anyway, to answer the question as
to the display--yeah, the display should show the artist as the file is
tagged (mixed case). After all, it displays song titles etc. based on the
song file. As for artist--and genre for that matter--these should not be
case sensitive. That's just plain wrong as far as a usabilty standpoint.
The fact that is is, is nothing to argue about. Is there some advantage
from a usability standpoint that I'm missing?

In fact, I'll bet that if the database only stored one case (so as to be not
sensitive to case) it would actually IMPROVE the server performance.

In the meantime, yeah, I'll go re-tag my files.

Thanks,
Phillip

JJZolx
2005-05-17, 06:01
Enhancement requests filed. Please vote or comment.

Artist, Album and Genre should be case insenstive:
http://bugs.slimdevices.com/show_bug.cgi?id=1548

Drop articles from artist name:
http://bugs.slimdevices.com/show_bug.cgi?id=1549
________
silver surfer vaporizer (http://vaporizer.org/reviews/silver-surfer)

Aaron Zinck
2005-05-17, 09:05
Is there any way to vote *against* enhancement or bug requests? The server
should show what's in your tags. Period. That way people can use their
tags however they want and they don't end up getting confused by having
Michael Jackson songs listed only under mICHAEL jACKSON simply because they
have 1 mis-tagged Michael Jackson song that was, for some reason, returned
first in the query. And I'm sure I've only scratched the tip of the iceberg
of other potential complications/confusion that could result from making
this change.

As far as I'm concerned, the "expected" behavior is for the software to read
your tags and show you what's in your tags. As KDF said earlier, what are
tags for if not to provide this information. Get your tags right. What you
suggest is the same sort of artificial "intelligence" that makes me shake my
fist at Microsoft Word whenever I try to use it and am baffled by the fact
that it's doing things that I never told it to do.

Richie
2005-05-17, 09:23
On 5/17/05, Aaron Zinck <azinck3 (AT) ufl (DOT) edu> wrote:
> Is there any way to vote *against* enhancement or bug requests? The server
> should show what's in your tags. Period. That way people can use their

I'd agree with this. As methodical as I try to be when tagging my
files I occasionally get it wrong. When I browse using the web
interface it's easy to spot mistakes and I can correct them straight
away. I'd much rather see the mistake than have SlimServer guess.

Richard

adhir
2005-05-17, 09:25
Speaking of spotting errors through the web interface, it sure would be
nice if we could fix them right there, within the web interface.
Perhaps a right click context menu on each song which allows selecting a
'edit tags' option...

Richie wrote:

>On 5/17/05, Aaron Zinck <azinck3 (AT) ufl (DOT) edu> wrote:
>
>
>>Is there any way to vote *against* enhancement or bug requests? The server
>>should show what's in your tags. Period. That way people can use their
>>
>>
>
>I'd agree with this. As methodical as I try to be when tagging my
>files I occasionally get it wrong. When I browse using the web
>interface it's easy to spot mistakes and I can correct them straight
>away. I'd much rather see the mistake than have SlimServer guess.
>
>Richard
>

Christian Pernegger
2005-05-17, 09:56
No question, the slimserver's way of handling tags can be improved.
Starting with supporting multiple instances of the same TAG in
VorbisComments, and proper support of 'ALBUM ARTIST', so people can
choose what to _display_ in the artist field for a various artists
album. At the very least there should be support for different
behaviour when sorting, when displaying, and when cross-referencing.
Above all, it should display what's in the tags, and a "try to find
inconsistencies in tagging" button would be nice.

Oh, and while I'm at it, integrate a masstagging utility, CDDB
support, and a p...

Seriously, there will never be a way to satisfy all people's
preferences with a static model. Why can't slimserver have a tagging
'language' like foobar2000's TAGZ and user customizable format strings
that can use any and all tags in a file? It could be used to customize
how songs / albums / ... are displayed, when a certain tag is to be
considered equal and what to consider part of an album for example.
Basically slimserver should let the user specify how it should expect
files to be tagged, including arbitrary tags. It would allow a
classical music mode that works without the established ALBUM / ARTIST
/ TRACK model. Even consistency checks could be defined that way:
(pseudocode)

if ( ( $num(%artist%) > 1 ) AND ( %album artist% = NULL ) ) assert
"%__filename% - more than one ARTIST tag and ALBUM ARTST not set."

This would require extending the db model to store arbitrary tags, how
difficult is that?

The TAGZ-like language would basically be a sugarcoated subset of perl
+ sql in slimserver's case. I can see regular expressions being
useful. For examples on what such an interface can do see the
capabilities of various "skins" for foobar2000's ColumnsUI out there.

C.

kdf
2005-05-17, 10:00
Quoting "Alok K. Dhir" <alok (AT) dhir (DOT) net>:

> Speaking of spotting errors through the web interface, it sure would be
> nice if we could fix them right there, within the web interface.
> Perhaps a right click context menu on each song which allows selecting a
> 'edit tags' option...

This has come up before, and often sparks a very heated response. There are a
large number of users who have very valid concerns ofver slimserver writing
over their carefully tagged files, as the front end is a publicly accessible
interface. Slimserver does not have more than a basic security system, and
even if it did, I expect the resistence to this change would still be strong.
There are plenty of really great tagging programs out there. The limited
resources for development of slimserver can be better spent optmising playlist
speed (just as one example)

-kdf

Christian Pernegger
2005-05-17, 10:06
> This has come up before, and often sparks a very heated response. There are a
> large number of users who have very valid concerns ofver slimserver writing
> over their carefully tagged files, as the front end is a publicly accessible
> interface. Slimserver does not have more than a basic security system,

It doesn't have write access to any of my music files either, so that's ok :)

C.

JJZolx
2005-05-17, 11:39
As far as I'm concerned, the "expected" behavior is for the software to read
your tags and show you what's in your tags. As KDF said earlier, what are
tags for if not to provide this information. Get your tags right. What you
suggest is the same sort of artificial "intelligence" that makes me shake my
fist at Microsoft Word whenever I try to use it and am baffled by the fact
that it's doing things that I never told it to do.

Somehow I don't see SlimServer as ever being intended as a "tag debugging" tool. Case insensitivity is hardly AI. We're not talking about spelling or grammar correction.

Is the intention for SlimServer to catalog your library in a useful manner or is it there so people can find trivial differences in capitalization in their tags? A _lot_ of people don't have the time or the desire to meticulously pour over the tags on their music files in order to make the SlimServer user interface more coherent.

If the dropping of leading articles is undesired then it could be made a server option, as suggested in the enhancement request. The article list could then be cleared and you'd have the same behavior you have now.
________
Triumph Scrambler (http://www.cyclechaos.com/wiki/Triumph_Scrambler)

kdf
2005-05-17, 12:08
a request that is already admitting a need to be optional presents a few issues:

1) not only does support have to implemented for feature on, and feature off,
but also feature going from on to off, and off to on cleanly, quickly, and
without harming any other feature (I'm sure you remember all the regression
rants). There is always someone who will insist they must change the settings
every so often and find it 'unacceptable' to have to restart the server because
of it.

2) another known complaint (admittedly not as often seen in these fora) is
that the huge volume of prefs currently available are already daunting to new
and potential users.

Given that there are perfectly workable solutions already out there that will
accomplish the same thing, you end up left with the obvious unending argument
over which is more conventient and which users convenience is more important
than another.

If someone needs assistence implementing such code, I'll of course help. I
certainly can't say I'll take in on of my own volition (speaking just as a
contributor) since I already know it will come with a support headache. If the
feature does come along, that would be cool. I'm not against new features,
just the attitude that it 'should be done' or 'it shouldn't be
that hard' (half the threads today seem to include those phrases, or something
similar). Now everyone can be aware of the obstacles, at least.

As a specific, removing the 'articles to ignore' pref would make me VERY happy.

-kdf

JJZolx
2005-05-17, 12:57
a request that is already admitting a need to be optional presents a few issues:

1) not only does support have to implemented for feature on, and feature off,
but also feature going from on to off, and off to on cleanly, quickly, and
without harming any other feature (I'm sure you remember all the regression
rants). There is always someone who will insist they must change the settings
every so often and find it 'unacceptable' to have to restart the server because
of it.

2) another known complaint (admittedly not as often seen in these fora) is
that the huge volume of prefs currently available are already daunting to new
and potential users.

Given that there are perfectly workable solutions already out there that will
accomplish the same thing, you end up left with the obvious unending argument
over which is more conventient and which users convenience is more important
than another.

If someone needs assistence implementing such code, I'll of course help. I
certainly can't say I'll take in on of my own volition (speaking just as a
contributor) since I already know it will come with a support headache. If the
feature does come along, that would be cool. I'm not against new features,
just the attitude that it 'should be done' or 'it shouldn't be
that hard' (half the threads today seem to include those phrases, or something
similar). Now everyone can be aware of the obstacles, at least.

As a specific, removing the 'articles to ignore' pref would make me VERY happy.
That's funny, because I don't think there are nearly enough preference settings. Their presentation in the server settings screens leaves a great deal to be desired, but I realize that's a very low priority at the time. They needn't be on ten different screens so that it takes minutes to find a pref. The explanations, while often wordy are too brief to fully explain the option or its ramifications. There needs to be an immediately accessible help system with full explanations (using mouseovers or popup windows or whatever). Support problems tend to be lessened when the interface is better and the help more complete, but that's a topic for another thread.

I realize that the articles setting requires a complete rescan of the library whenever it's changed. This something in the server settings that isn't explained sufficiently. I will agree with you, though, a pref that requires a rescan to repopulate the db is generally undesirable. But sometimes unavoidable given the overall db implementation.

I suggested previously just using the existing article-stripped, case insentive 'titlesort' and 'namesort' columns in SQL statements. It would be interesting to see if that was a workable approach to these enhancement requests.
________
Suzuki GSX-R1000 (http://www.cyclechaos.com/wiki/Suzuki_GSX-R1000)

Richie
2005-05-17, 13:16
> Somehow I don't see SlimServer as ever being intended as a "tag
> debugging" tool. Case insensitivity is hardly AI. We're not talking
> about spelling or grammar correction.
> --
> JJZolx

But surely getting SlimServer to guess the correct tag would be
classed a form of debugging. I'd like to have errors highlighted so I
can fix them, you'd like SlimServer to ignore the errors. It seems we
want the same result (correct tags) just we're taking different routes
to get there.

Richard

Phillip Kerman
2005-05-17, 14:39
> Somehow I don't see SlimServer as ever being intended as a "tag
> debugging" tool. Case insensitivity is hardly AI. We're not talking
> about spelling or grammar correction.
>

Totally. If making the server ignore case is really going to ruffle that
many peoples' way of doing things then it should just be an option. I read
all these emails and what I still don't understand is why someone would even
WANT it the way it is now. Seriously, where does the case-sensitivity
become an advantage?

Why would anyone want "PUNK" and "Punk" and "PUnk" to sort differently?
Please tell me because I'm sincerely curious.


Also regarding:
> Given that there are perfectly workable solutions already out
> there that will
> accomplish the same thing,

This point fails to appreciate that the few hours invested to add the
feature to the product (or, what I'd say... fixing a flaw in the design)
will mean COUNTLESS hours saved by all of us meticulously "fixing" our tags.
I went through my library of 8000 songs and it took an hour to fix all the
tags. What a pain. And I didn't catch them all. Had to clear the
cache/rescan. Multiply that by all the users and this issue seems so
obvious to me. But... whatever, I didn't mean to start WWIII.



Thanks,
Phillip

stinkingpig
2005-05-17, 18:50
Alok K. Dhir wrote:
> Speaking of spotting errors through the web interface, it sure would be
> nice if we could fix them right there, within the web interface.
> Perhaps a right click context menu on each song which allows selecting a
> 'edit tags' option...

I've looked at implementing this, but it's currently over my head. The
Slimserver uses a (to me) complex library named Template Toolkit to
generate web pages, and I need to learn how it works in order to make
this happen. Still on my todo list, but it's been there for 6 months so
if someone else is more motivated...

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

stinkingpig
2005-05-17, 19:01
Phillip Kerman wrote:
>>Somehow I don't see SlimServer as ever being intended as a "tag
>>debugging" tool. Case insensitivity is hardly AI. We're not talking
>>about spelling or grammar correction.
>
> Totally. If making the server ignore case is really going to ruffle that
> many peoples' way of doing things then it should just be an option. I read
> all these emails and what I still don't understand is why someone would even
> WANT it the way it is now. Seriously, where does the case-sensitivity
> become an advantage?
>
> Why would anyone want "PUNK" and "Punk" and "PUnk" to sort differently?
> Please tell me because I'm sincerely curious.
>

Because the Slimserver is not the only place I play this music. My
iRiver and my wife's iPod will also display the tag content, and it's
annoying to both of us when the content is wrong. Music I've had ripped
for a long time is generally tagged correctly, but when I get new music
and it's not tagged correctly, listening to it in Slimserver makes that
obvious. Since I'm home instead of noticing it on my iRiver at 35,000
feet, I can fix it.

Maybe a shorter answer is that "some of us want the tag information to
be right." I understand that some of us just want the information to
look right, and don't care if it actually is right. However, Slimserver
is currently implemented for the people in the first group.

>>Given that there are perfectly workable solutions already out
>>there that will
>>accomplish the same thing,
>
>
> This point fails to appreciate that the few hours invested to add the
> feature to the product (or, what I'd say... fixing a flaw in the design)
> will mean COUNTLESS hours saved by all of us meticulously "fixing" our tags.
> I went through my library of 8000 songs and it took an hour to fix all the
> tags. What a pain. And I didn't catch them all. Had to clear the
> cache/rescan. Multiply that by all the users and this issue seems so
> obvious to me. But... whatever, I didn't mean to start WWIII.
>

If you haven't at least tried to patch it yourself, you have no right,
no capability, and no business trying to estimate how long it will take
to fix. Writing software is a lot closer to brain surgery than it is to
rebuilding a carburetor.

--
Jack at Monkeynoodle dot Org: It's a Scientific Venture...
Riding the Emergency Third Rail Power Trip since 1996!

Phillip Kerman
2005-05-17, 21:59
> Phillip Kerman wrote:
> >>Somehow I don't see SlimServer as ever being intended as a "tag
> >>debugging" tool. Case insensitivity is hardly AI. We're
> not talking
> >>about spelling or grammar correction.
> >
> > Totally. If making the server ignore case is really going
> to ruffle that
> > many peoples' way of doing things then it should just be an
> option. I read
> > all these emails and what I still don't understand is why
> someone would even
> > WANT it the way it is now. Seriously, where does the
> case-sensitivity
> > become an advantage?
> >
> > Why would anyone want "PUNK" and "Punk" and "PUnk" to sort
> differently?
> > Please tell me because I'm sincerely curious.
> >
>
> Because the Slimserver is not the only place I play this music. My
> iRiver and my wife's iPod will also display the tag content, and it's
> annoying to both of us when the content is wrong. Music I've
> had ripped
> for a long time is generally tagged correctly, but when I get
> new music
> and it's not tagged correctly, listening to it in Slimserver
> makes that
> obvious. Since I'm home instead of noticing it on my iRiver at 35,000
> feet, I can fix it.
>

> Maybe a shorter answer is that "some of us want the tag
> information to
> be right." I understand that some of us just want the information to
> look right, and don't care if it actually is right. However,
> Slimserver
> is currently implemented for the people in the first group.


Thanks for trying to answer my question but I still don't understand the
reason you want slimserver to show the genres or artists with case
sensitivity. I sort of appreciate the "I want it to be right" reason--but
the only practical benefit you cite is that you can use slim server as your
"wrong tag finder tool". Compared to the purpose of slimserver (in my
opinion to run my SB) I don't see how this is a benefit at all. I'm really
only trying to understand if this is anything more than some users' desire
for the tags to reflect exactly what's in the file at the expense of what
I'd call practical.



>
> >>Given that there are perfectly workable solutions already out
> >>there that will
> >>accomplish the same thing,
> >
> >
> > This point fails to appreciate that the few hours invested
> to add the
> > feature to the product (or, what I'd say... fixing a flaw
> in the design)
> > will mean COUNTLESS hours saved by all of us meticulously
> "fixing" our tags.
> > I went through my library of 8000 songs and it took an hour
> to fix all the
> > tags. What a pain. And I didn't catch them all. Had to clear the
> > cache/rescan. Multiply that by all the users and this
> issue seems so
> > obvious to me. But... whatever, I didn't mean to start WWIII.
> >
>
> If you haven't at least tried to patch it yourself, you have
> no right,
> no capability, and no business trying to estimate how long it
> will take
> to fix. Writing software is a lot closer to brain surgery
> than it is to
> rebuilding a carburetor.
>

Huh? I actually write software and when someone points out a bug or a place
for improvement my first reaction is to say thanks. I do think I can make
an educated guess on the time involved but that's not even my point. I'm
simply saying that even if it takes 1 million man hours to address this,
it's merely a matter of time before that time is recovered in saved time
from users who don't have to review their library's tags with a fine toothed
comb every week from now to eternity. That is, there's a return on
investment over time.

Thanks,
Phillip

P.S. Really, seriously, I don't understand why someone would want sorting to
be based on case when finding music. After all, when you search for a song
by entering a few characters those are not case sensitive. Please tell me
you wouldn't want it to be in that case. "Search for Punk" found 0 results
(because you tagged your collection as "punk")... fun.

Christian Pernegger
2005-05-18, 01:36
> P.S. Really, seriously, I don't understand why someone would want sorting to
> be based on case when finding music. After all, when you search for a song
> by entering a few characters those are not case sensitive. Please tell me
> you wouldn't want it to be in that case. "Search for Punk" found 0 results
> (because you tagged your collection as "punk")... fun.

I don't think anybody is saying that the _search_ should necessarily
be case-sensitive. Instead there should be checkboxes in advanced
search for 'case sensitive' and 'allow substring match', but for the
search on the player and live search case insensite is fine.

What some people (including me) don't want, is two tags that only
differ in case be treated as equal for display and cross referencing
purposes. After all, if there's Jazz, jazz and jAZZ - how should
slimserver determine which is correct?

C.

Phillip Kerman
2005-05-18, 06:53
> > P.S. Really, seriously, I don't understand why someone
> would want sorting to
> > be based on case when finding music. After all, when you
> search for a song
> > by entering a few characters those are not case sensitive.
> Please tell me
> > you wouldn't want it to be in that case. "Search for Punk"
> found 0 results
> > (because you tagged your collection as "punk")... fun.
>
> I don't think anybody is saying that the _search_ should necessarily
> be case-sensitive. Instead there should be checkboxes in advanced
> search for 'case sensitive' and 'allow substring match', but for the
> search on the player and live search case insensite is fine.
>
> What some people (including me) don't want, is two tags that only
> differ in case be treated as equal for display and cross referencing
> purposes. After all, if there's Jazz, jazz and jAZZ - how should
> slimserver determine which is correct?

slimserver obviously has to track each file uniquely... for all I care it
can know the case of the tags. But from a purely practicaly perspective
this is what I often do that doesn't work as I think it should:

--browse by artist.... find an artist... dig into their albums... loop
through a few times to find the album I want is listed under the same artist
case.
--browse by genre... same issue.

I can't think of why anyone likes the fact browse by artist/genre is case
sensitive. The more I think about it the more I KNOW I'm right. Again,
maybe there's some reason I just can't think of but no one has stated it
yet.

Thanks,
Phillip

Phillip Kerman
2005-05-18, 09:18
> --browse by artist.... find an artist... dig into their albums... loop
> through a few times to find the album I want is listed under
> the same artist
> case.

Or, despite having said "ignore articles" in the settings... If find
"Rolling Stones"... go through all the albums and it looks like one is
missing... nope, I have to go back up then move on to the OTHER artist...
"The Rolling Stones".

Why is this an advantage?

Thanks,
Phillip

Christian Pernegger
2005-05-18, 10:06
> If find "Rolling Stones"... go through all the albums and it looks like one is
> missing... nope, I have to go back up then move on to the OTHER artist...
> "The Rolling Stones".

The point of the ARTIST tag is that tracks by the same artist should
share a common tag. For one artist you have to use one canonical name
in tags, one or the other. Alternatively you could add multiple ARTIST
tags and wait for slimserver to support that.

C.

Phillip Kerman
2005-05-18, 12:03
> > If find "Rolling Stones"... go through all the albums and
> it looks like one is
> > missing... nope, I have to go back up then move on to the
> OTHER artist...
> > "The Rolling Stones".
>
> The point of the ARTIST tag is that tracks by the same artist should
> share a common tag. For one artist you have to use one canonical name
> in tags, one or the other. Alternatively you could add multiple ARTIST
> tags and wait for slimserver to support that.
>

But the question remains, does anyone like this fact? Especially because
one would think that when you say ignore "the" it should let you find all
the songs by "The Rolling Stones" and "Rolling Stones" without going back
and forth through the hierarchy.

Thanks,
Phillip

Christian Pernegger
2005-05-18, 12:17
Maybe you're confusing searching for / finding something with displaying it?

Searching for 'rolling' in any case or combination of cases should
give you 'Rolling Stones' and 'The Rolling Stones', but as two
seperate results and not merged together - there's no way to
dertermine which of the two spellings is correct.

C.

kdf
2005-05-18, 12:22
Having done a bit of poking around at another device in my possession, I think a
compromise can make sense for both camps.

Search could be case insensitive (match as much as you can, right)
Browse lists can use whatever comes first (subsequent variations as the list is
compiled can match case insensitive to previous cases)

Song info, current playlist and now playing would all display the tags AS IS.

This appears to be just the way that my Rio Karma operates, as well as my old
NexII. This makes the listings simpler, yet still shows raw info when the song
is live, or queued. It also means no real munging of tag info, just more
lenient matching when doing a search or sort (for browse)

-kdf

Phillip Kerman
2005-05-18, 12:27
>
> Maybe you're confusing searching for / finding something with
> displaying it?
>
> Searching for 'rolling' in any case or combination of cases should
> give you 'Rolling Stones' and 'The Rolling Stones', but as two
> seperate results and not merged together - there's no way to
> dertermine which of the two spellings is correct.


I get that.

But... because the browse folder is way slow now... this is what I often do:
browse artist>pick an artist> look for an album > pick a song

It's a big pain that, as punishment for my sloppiness (say tagging some
albums "The Beastie Boys" and some "Beastie Boys") that I must get carpel
tunnel syndrome looking for the song I want when it's time to rock.

I'm not sure if kdf's latest proposal solves this issue for me. I think not
because I want "The Anything" to be merged with "Anything" during browse
artist or browse genre.



Thanks,
Phillip

kdf
2005-05-18, 12:31
Quoting Phillip Kerman <lists (AT) phillipkerman (DOT) com>:


> I'm not sure if kdf's latest proposal solves this issue for me. I think not
> because I want "The Anything" to be merged with "Anything" during browse
> artist or browse genre.

I was only speaking about case sensitivity. I'm specifically refraining from
stating any opinion on the articles issue.

-kdf

Christian Pernegger
2005-05-18, 13:18
> Search could be case insensitive (match as much as you can, right)

Exactly.

> Browse lists can use whatever comes first

I'm fine with everything that can be turned off ;)

C.