PDA

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



Meshoulam, Arnon
2004-10-25, 08:26
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

dean
2004-10-25, 08:43
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
>
>