Bugzilla – Bug 5197
I18n: Strange shortcut links in Artist view.
Last modified: 2009-01-29 09:47:36 UTC
In artist view, I see the following shortcut links (also, see attachment): 1 2 5 7 A B C D E F G H I J K L M N P R S T U V X А Б В Г Д Е Ж З И К Л ла ле лю Н О П С Т У Ф Ч Э Ю The "ла ле лю" links are quite strange -- it's not clear what they are doing there, and they redirect to other initial letters when clicked: ла --> О ле --> Т лю --> Л SlimServer Version: 7.0a1 - 12431 - RedHat - EN - utf8 Perl Version: 5.8.8 i386-linux-thread-multi MySQL Version: 5.0.21-standard Web-browser: FireFox 2.0.0.5 You can try to access http://www.3amok.com:32180 (it might be up)
Created attachment 2077 [details] Artist view
Please leave targets undefined for qa reviews.
Do you have data imported via iTunes or MusicIP? Do the links go to files that display the same encoding problem? Are ALL of your files fully tagged on your current system with the current codepage setting? Some problem do occur when files are not tagged with a title (thus causing guessTags to kick in). This produces problems when the files may have been named with one codepage, then read later on a system with a different codepage.
> Do you have data imported via iTunes or MusicIP? All metadata was added by scanning the music folder with MP3 files, tagged with ID3v2. Nothing was imported. > Do the links go to files that display the same encoding problem? The links jump to the Artist list, as noted in the original description. All metadata for individual files displays correctly via Web and Squeezebox. > Are ALL of your files fully tagged on your current system with the current codepage setting? All MP3 are tagged with ID3v2 using ASCII for English, and UTF-8 for strings containing Cyrillic characters. t Hope this helps. Where would I look in the code if I tried to debug this?
Can someone point out the piece of code that generates the 'pagebar' element? I can't locate it...
Best way to get info is to post in the developer forum on our message board (http://forums.slimdevices.com). Do you have a small file or could you create a file that demonstrates the problem and attach it to the bug?
Created attachment 2112 [details] repro data The set of mp3 files that demonstrate the problem.
pagebar is generated in part from Slim/Web/Pages/BrowseDB.pm, from data generated by Slim/Schema/ResultSet/Album.pm and ...ResultSet/Contributor.pm. The root class is found in Slim/Schema/Pagebar.pm. The resulting data is then prepared for template toolkit by the pagebarcalc block in HTML/EN/hreftemplate
Solution found: In both places in [Slim/Web/Pages.pm], instead of Slim::Utils::Unicode::utf8decode(<expression>, 'utf-8'); we should use Encode::decode('utf8', <expression>); because the database returns UTF-8, and we know it! The problem with Slim::Utils::Unicode::utf8decode() is that it calls utf8decode_guess, which tries to *guess* encoding from the string. With short strings (like a single letter, in this case), the guessing fails, and the decoding produces something totally strange. I think Slim::Utils::Unicode::utf8decode() should be deprecated, because it's a piece of garbage -- it doesn't do what it advertises. Please apply the fix... Best regards.
a personal comment: please keep the judgemental terms to yourself (at least as long as you insist in hiding behind an obfuscated id). We get enough crap from ppl who don't know what they are talking about, and you are best served by not including yourself in that behaviour. As for the issue of garbage, please make sure that you have accounted for every case of slimserver installations before you make claims; a fair number of users end up with mixed encodings and expect some sort of result. It's not always as simple as just ignoring them. With that, I'll have no more to do with this bug. someone else may eventually deal with the fix.
Come on, what's with all the bitterness? ;-) Don't take "that function is garbage" personally. I write/test software for living and make comments like that whenever they are justified. To be fair, I haven't found evidence of automated testing going on with SlimServer, and as an end-user of (now) a Logitech product, I don't enjoy recurrent problems with character encoding. The truth is that Slim::Utils::Unicode::utf8decode was mis-used in Pages.pm, hence the bug. Now, this is personal: besides Comment #8 above, pointing me in the general direction of the problem, I haven't gotten many useful responses from you, KDF... whatever your real name is.
Andy would you review this proposed fix and see if it should go into 7.0?
Assigning to Andy to review. To the original poster: KDF is a valued contributor to our products, but he's not an employee of Logitech. We take your bug very seriously, and appreciate your contribution.
Thanks, committed as change 14423.