likely a dupe of bug503 and bug519 where non-latin1 character are not currently
supported

Created attachment 122 [details]
Modified FLAC parser from Slim/Formats/FLAC.pm

Changes:
  Line 21: Includes Unicode::String from CPAN (Debian 3.0R2 uses version 2.06).

  Line 54-61: Translation of tags from UTF8 to ISO-8859-1 (Latin1).

Sorry, my comments were somehow lost in the first tries... Details:

The SlimServer does not deal correctly with FLAC files with tags containing
international characters. The central issue is that FLAC uses VORBIS comments,
which are defined as UTF8 (Unicode), whereas SlimServer seems to expect ISO-8859-1.

While there are other issues with localization, just fixing the display would be
very nice - I've attached a proposed patch that translates the tags upon
scanning the FLAC flies.

PS: Not sure if this is the proper avenue for suggesting patches.

PPS: The 2nd half of the problem is getting the international characters
correctly into the FLAC tags: As a hint for other SLIMP users, it can be done by
tagging with "metaflac --no-utf8-convert" and using UTF8 encoded tag values.

does the patch work with Perl 5.6 as well?

Yes, I'm running Perl 5.6.1 (Linux).

I've created a FLAC file with all of the printable ISO-8859-1 characters (beyond
ASCII) encoded as UTF8; this could be useful for your regression tests:
  Artist: All symbols (0xA1-0xBF)
  Album:  All upper-case letters (0xC0-0xDE)
  Title:  All lower-case letters (0xDF-0xFF)

This displays correctly in the browser (give-or-take a few characters with which
I am not familiar), and mostly correctly in the SLIMP (I believe all letters are
correctly displayed, but a few symbols are not) - probably a hardware limitation.

I'll attach the test file to this bug report...

Created attachment 124 [details]
Test FLAC file with UTF8 VORBIS comments corresponding to ISO-8859-1 0xA1-0xFF.

Anyone, who's doing any development on this, plase read my comments, submitted to bug 
report #503. It's important to notice, that all the server components handle utf-8 encoded tags 
correctly (with my3s and oggs at least, didn't test other formats), so do not bother to fix thigs 
there. 
 
 There are "only" two thnigs to do: 
- Fix the web-interfaces (did it myself to test my idea): change the encoding of all htmls to utf-8
(put a Content-Type meta tag in, or fix the one that says ISO-8859-1). This is reeeealy easy. 
(see included screenshot @503 for proof) 
- Fix encoding problems related with the Squeezebox. Don't know how hard, as I don't own a 
box myself. YET ;-) 
 
Zsolt 
 
P.S.: Submitted this to bugs #31, #519 and #534 

SlimServer fully supports UTF-8 in the 6.0/trunk CVS tree.

There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006.  I am setting them to targets of 6.2.1 to keep them from showing up in my queries.

Routine bug db maintenance; removing old versions which cause confusion.  I apologize for the inconvenience.