Bugzilla – Bug 2677
SlimServer stops shortly after SB3 starts playing file with Japanese id3 tags
Last modified: 2008-09-15 14:39:24 UTC
When I play a track by my favorite Japanese rock group (Yura Yura Teikoku), SlimServer will show the Japanese characters in the ID3 tags ok, and the SB3 will start playing it, but then SlimServer will turn off, and the connection to the SB3 is lost and the track stops. It happens every time I try playing a file with Japanese characters in the ID3 tags.
For example, see http://www.mesh-key.com/yura_III.mp3 . This track has Japanese characters in its ID3 tags, and unless something is just wrong with my setup, SlimServer 6.5 will shut down shortly after it starts to play it.
what is in the log when slimserver crashes. it iss unlikely a character issue after playback starts, but without a log it could be anything. look in the windows event viewer (control panel, administration tools) or run: c:\program files\slimserver\server\slim.exe and look in the dos window for the crash. if the server does not crash, please turn on d_source in server settings->debugging and open the browser to http://serverIP:9000/log.txt
(In reply to comment #2) > what is in the log when slimserver crashes. I went to the event viewer in admin tools and this is what it says (application error): " The description for Event ID ( 0 ) in Source ( Application ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Wide character in send at /PerlApp/IO/Socket.pm line 218. "
hrm. This crash has been associated with large text on slimp3 before, but never squeezebox. This would, however, clearly confirm your original assumption. I'll forward this to Dan since this may be part of his current work. I assume that since you set the target to 6.5, that you are currently using the latest 6.5 nightly?
Chris: can you attach to the bug a track that causes the server to crash?
(In reply to comment #5) > Chris: can you attach to the bug a track that causes the server to crash? > I'm not sure exactly what you mean by "bug" and/or "track". How would I get a "track"? In response to the previous question, yes, I'm using the latest 6.5 nightly version of SlimServer.
The "bug" is this report. The "track" is the "track by my favorite Japanese rock group" that you mentioned in your original post. I believe Dean missed the link that you gave in comment 2, which would seem to be at least one track that causes the problem.
(In reply to comment #7) > The "bug" is this report. The "track" is the "track by my favorite Japanese > rock group" that you mentioned in your original post. I believe Dean missed > the link that you gave in comment 2, which would seem to be at least one track > that causes the problem. > Sorry, I was a little confused there. I will attach the track in question.
Created attachment 1064 [details] This is the mp3 track that keeps causing SlimServer to shut down.
(In reply to comment #9) > Created an attachment (id=1064) [edit] > This is the mp3 track that keeps causing SlimServer to shut down. > Ah-ha! The problem apparently stems from the comment.. maybe it's too long? When I deleted it from the id3 tags, the track played fine.
(In reply to comment #10) > Ah-ha! The problem apparently stems from the comment.. maybe it's too long? > When I deleted it from the id3 tags, the track played fine. > D'oh! Spoke too soon. It looks like the only reason it played was because the SB3 was in screensaver mode (analog VU mode), and I had started playing it from SlimServer. As soon as I tried to view the artist name (i.e., took the SB3 out of screensaver mode), it disconnected from SlimServer and stopped playback. So it's definitely a problem with the Japanese tags.
I've run into this problem also. Using a Mac. I noticed the problem when playing Random Song Mix for several hours, so presumably it eventually ran into a foreign language song.
I found an m4a track that consistently causes this crash: Wide character in send at /System/Library/Perl/5.8.6/darwin-thread-multi-2level/IO/Socket.pm line 218. I am running: SlimServer Version: 6.5b1 - 5378 - Mac OS X 10.4.3 (8F46) - EN - utf8 See attached file "Piano Concerto N� 2 in F, Op. 102 � I. Allegro.m4a" that causes this.
Created attachment 1076 [details] One of the french characters in the Album name of this track causes this crash.
I found some info on unicode character support in Perl here: http://www.ahinea.com/en/tech/perl-unicode-struggle.html which might help if someone is looking into fixing this.
I am changing the title of this bug to be more descriptive. Also changing Hardware to All, since it affects both Mac and Windows. And severity to critical since it crashes the slimserver. Not sure if Player UI is the right component but couldn't find a better one.
Well it wouldn't let me do those changes. Should I enter a new bug for this? Meanwhile, I am trying to learn more about unicode in perl...
Chris / Mark - do you have a Unicode TrueType Font installed for SlimServer to use?
I have not installed any special fonts. (Should I?) I simply installed Slimserver 6.5b1 (latest nightly that built for the Mac) and got the crash. I tried it on two different Macs--same crash. By the way it's the characters in the 'Album' name of this track (not the Song Name) that causes this crash. I was just experimenting a bit. I'll try to narrow it to which character is causing it.
Mark - the Wiki has more information: http://wiki.slimdevices.com/index.cgi?UnicodeFonts
OK, I've located these fonts. Now how do I install them? As *.font.bmp files? I found a tool "TtfToSbg" but it is a Windows-only app. Need more clues....
Mark - you only need one of them, and copy it to: ~/Library/SlimServer/Graphics/ then restart SlimServer
I tried all three font files (CODE2000.TTF, cyberbit.ttf, arialuni.ttf), one at a time, and I still get the crash when I press play for this song.
Mark - if you run SlimServer via Terminal - what is the crash message? cd ~/Library/PreferencePanes/SlimServer.prefPane/Contents/server perl slimserver.pl also - what version of OSX are you running on? And can you send the output of perl -V ? Thanks
Here is the info you asked for. Let me know what else you need. --Mark bulbous9-2:~ mak$ cd ~/Library/PreferencePanes/SlimServer.prefPane/Contents/server bulbous9-2:~/Library/PreferencePanes/SlimServer.prefPane/Contents/server mak$ perl slimserver.pl Wide character in send at /System/Library/Perl/5.8.6/darwin-thread-multi-2level/IO/Socket.pm line 218. I'm running Mac OS X 10.4.4 (8G22). This problem also happens on a stock 10.4.3 system. bulbous9-2:~/Library/PreferencePanes/SlimServer.prefPane/Contents/server mak$ perl -V Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Platform: osname=darwin, osvers=8.0, archname=darwin-thread-multi-2level uname='darwin b31.apple.com 8.0 darwin kernel version 8.0.0: sat mar 26 14:15:22 pst 2005; root:xnu-792.obj~1release_ppc power macintosh powerpc ' config_args='-ds -e -Dprefix=/usr -Dccflags=-g -pipe -Dldflags=-Dman3ext=3pm -Duseithreads -Duseshrplib' hint=recommended, useposix=true, d_sigaction=define usethreads=define use5005threads=undef useithreads=define usemultiplicity=define useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=undef use64bitall=undef uselongdouble=undef usemymalloc=n, bincompat5005=undef Compiler: cc='cc', ccflags ='-g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include', optimize='-Os', cppflags='-no-cpp-precomp -g -pipe -fno-common -DPERL_DARWIN -no-cpp-precomp -fno-strict-aliasing -I/usr/local/include' ccversion='', gccversion='3.3 20030304 (Apple Computer, Inc. build 1809)', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=4321 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=8 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc', ldflags ='-L/usr/local/lib' libpth=/usr/local/lib /usr/lib libs=-ldbm -ldl -lm -lc perllibs=-ldl -lm -lc libc=/usr/lib/libc.dylib, so=dylib, useshrplib=true, libperl=libperl.dylib gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=bundle, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-bundle -undefined dynamic_lookup -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES PERL_IMPLICIT_CONTEXT Locally applied patches: 23953 - fix for File::Path::rmtree CAN-2004-0452 security issue 33990 - fix for setuid perl security issues Built under darwin Compiled at Aug 21 2005 17:14:55 @INC: /System/Library/Perl/5.8.6/darwin-thread-multi-2level /System/Library/Perl/5.8.6 /Library/Perl/5.8.6/darwin-thread-multi-2level /Library/Perl/5.8.6 /Library/Perl /Network/Library/Perl/5.8.6/darwin-thread-multi-2level /Network/Library/Perl/5.8.6 /Network/Library/Perl /System/Library/Perl/Extras/5.8.6/darwin-thread-multi-2level /System/Library/Perl/Extras/5.8.6 /Library/Perl/5.8.1 . bulbous9-2:~/Library/PreferencePanes/SlimServer.prefPane/Contents/server mak$
I'm getting the same crash/error message: Wide character in send at /usr/lib/perl5/5.8.5/x86_64-linux-thread-multi/IO/Socket.pm line 218. This is in Gentoo Linux. Audio files are all FLAC. This started occurring before the 6.5 branch. I have the Cyberbit and CODE2000 fonts installed in the server/Graphics directory. I updated today to svn 5440 and still get these crashes. This always occurs for me when I'm listening in random mode at a track transition. The server crashes before the new track begins to play. Unfortunately, that means that I lose the playlist and any info as to *which* track caused the problem. I do have many tracks with Unicode characters in the tags.
Some additional info... (FLAC) Tracks with Unicode in the ARTIST tag seem okay, but those with Unicode in the TITLE will crash the server consistently every time I select them manually (either via the remote or the web interface). This track, for example... METADATA block #2 type: 4 (VORBIS_COMMENT) is last: false length: 315 vendor string: reference libFLAC 1.1.0 20030126 comments: 10 comment[0]: GENRE=Electronica/Dance comment[1]: ALBUM=Tango N' Vectif comment[2]: TRACKNUMBER=7 comment[3]: TITLE=μ-ziq Theme comment[4]: COMPOSER=Mike Paradinas comment[5]: ARTIST=µ-ziq comment[6]: REPLAYGAIN_TRACK_PEAK=0.99996948 comment[7]: REPLAYGAIN_TRACK_GAIN=-3.44 dB comment[8]: REPLAYGAIN_ALBUM_PEAK=1.00000000 comment[9]: REPLAYGAIN_ALBUM_GAIN=-4.63 dB
<sigh> I have to amend my previous comment... It appears that there were two different Mu characters in the previous example (although they appear exactly the same on the Linux box). An example of a track with an ARTIST (not just TITLE) tag which crashes the server: METADATA block #2 type: 4 (VORBIS_COMMENT) is last: false length: 272 vendor string: reference libFLAC 1.1.0 20030126 comments: 9 comment[0]: GENRE=Downtempo comment[1]: TITLE=ss/sadness-88 comment[2]: ARTIST=We™ comment[3]: ALBUM=As Is. comment[4]: TRACKNUMBER=13 comment[5]: REPLAYGAIN_TRACK_PEAK=0.85208130 comment[6]: REPLAYGAIN_TRACK_GAIN=+2.37 dB comment[7]: REPLAYGAIN_ALBUM_PEAK=0.99020386 comment[8]: REPLAYGAIN_ALBUM_GAIN=-3.44 dB Also, I have installed the official 6.2.1 release and playing this track does NOT crash the server. Sorry for the spam.
Fixed in change 5665.
Fix verified--no longer crashes for me.