> 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. _______________________________________________ Discuss mailing list Discuss@lists.slimdevices.com http://lists.slimdevices.com/lists/listinfo/discuss
