PDA

View Full Version : [Developers] Utf8 support for WMA files



Meshoulam, Arnon
2004-10-25, 08:49
Will do the --diag.
Slimserver_prod is 5.3.1 fresh from slimdevices
Slimserver is 5.3.1 with your modifications for utf8 and mine for hebrew
so I was trying to see if we caused the problem

Arnon

-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of dean
blackketter
Sent: Monday, October 25, 2004 4:43 PM
To: Slim Devices Discussion
Subject: [slim] [Developers] Utf8 support for WMA files

Arnon,

Can you run SlimServer with the --diag option? That will give us a
little more information about the problem.

Also, is this output from two different runs of the server? The first
part references

/usr/local/slimserver

and the last part references

/usr/local/slimserver_prod

-dean

On Oct 25, 2004, at 8:26 AM, Meshoulam, Arnon wrote:

> I have been working with Dan Sully (he is working I am testing) to get
> utf8 support on Slimserver
> However, I seems that some flac files are crashing the server. To
> verify
> just ran a production 5.3.1 server, no modifications and still crashed
>
> Output of logfile:
>
> Use of uninitialized value in pattern match (m//) at
> /usr/local/slimserver/CPAN/
> MP3/Info.pm line 535, <$fh> line 1.
> Use of uninitialized value in pattern match (m//) at
> /usr/local/slimserver/CPAN/
> MP3/Info.pm line 535, <$fh> line 1.
> Use of uninitialized value in pattern match (m//) at
> /usr/local/slimserver/CPAN/
> MP3/Info.pm line 535, <$fh> line 1.
> Use of uninitialized value in pattern match (m//) at
> /usr/local/slimserver/CPAN/
> MP3/Info.pm line 535, <$fh> line 1.
> Use of uninitialized value in pattern match (m//) at
> /usr/local/slimserver/CPAN/
> MP3/Info.pm line 535, <$fh> line 1.
> Use of uninitialized value in pattern match (m//) at
> /usr/local/slimserver/CPAN/
> MP3/Info.pm line 535, <$fh> line 1.
> Use of uninitialized value in pattern match (m//) at
> /usr/local/slimserver/CPAN/
> MP3/Info.pm line 535, <$fh> line 1.
> Use of uninitialized value in pattern match (m//) at
> /usr/local/slimserver/CPAN/
> MP3/Info.pm line 535, <$fh> line 1.
> UTF-16:Unrecognised BOM 656e at
> /usr/lib/perl5/5.8.3/i386-linux-thread-multi/Enc
> ode.pm line 184, <$fh> line 1.
> Can't use an undefined value as an ARRAY reference at
> /usr/local/slimserver_prod
> //Slim/Player/SqueezeboxG.pm line 123.
>
> Any ideas?
>
> Arnon
>
> -----Original Message-----
> From: Dan Sully [mailto:daniel (AT) electricrain (DOT) com]
> Sent: Saturday, October 16, 2004 11:49 PM
> To: Meshoulam, Arnon
> Subject: [Developers] Utf8 support for WMA files
>
> * Meshoulam, Arnon <arnon.meshoulam (AT) intel (DOT) com> shaped the electrons to
> say...
>
>> I have done some more investigation with the tags, using FLAC as it
is
>> the easiest.
>> I don't think it is a decoding issue, as the same junk we see coming
> out
>> is stored in the tag. It seems to be an encoding
>> Issue that the programs writng the tags on MS env are not doing it
>> correctly.
>> What baffles me is that I have tried EAC -> Flac, Tag and Rename, and
>> FooBar 2000 and all behave the same.
>> i.e. a char(224) is not being encoded as the correct two hexes I
would
>> expect of it.
>
> Ok - that's entirely possible. I don't know enough about the tagging
> part to
> be able to say. Vorbis/FLAC tags do specify a strict UTF-8 though.
>
> Could the WMA tag issue be little endian vs big endian?
>
> -D
> --
> "A good messenger expects to get shot." --Larry Wall
>
>