Bugzilla – Bug 4313
Softsqueeze won't play MP3s using Java MP3 Plugin
Last modified: 2008-12-18 11:12:53 UTC
This is with SlimServer v6.5.1 - 10207 - Windows XP - EN - cp1252, Perl v5.8.8 MSWin32-x86-multi-thread & MySQL v5.0.22-community-nt. With the r10207 v6.5.1 nightly and Softsqueeze v3.2, MP3s don't play using the Java MP3 Plugin. JLayer works fine. I've pointed the same Softsqeeze to a v6.5 server and they play fine. See: http://forums.slimdevices.com/showpost.php?p=143220&postcount=14 Thanks.
looks like a fix was mentioned in the same thread, at least for one case. in short...an updated java, then re-install the mp3 plugin.
Additional test info on http://forums.slimdevices.com/showthread.php?p=145905#post145905. Jlayer does not work either. Had to roll back to 6.3.1 to get mpr working correctly.
I have solved my problem with MP33 not playing on Softsqueeze. I had tagged all my files using MP3tag v2.36a with ID3v1 and ID3v2.3 tags. When I removed the ID3v2.3 tags with foobar, I found the tracks played. I then reset all the tags to 1d3v1 and ID3v2.4 UTF8, and they worked. The problem is with how the XP version of Slimserver 6.5.* handles the beginning of the mp3 file. This is not an issue with Linux. This of course is a palliative solution as SS needs to be able to handle all types of tags.
Created attachment 1648 [details] MP3 with does not work with Java MP3 Plugin MP3Tag shows APEv2 and ID3v2.3 tags (not sure of encoding).
Created attachment 1649 [details] MP3 which does work with Java MP3 Plugin Has ID3v2.3/APEv2 tags (encoding should be ISO-8859-1)
For the MP3 that doesn't work, I'm not sure which program last edited the tags (could be MP3Tag or Mp3/Tag Studio). Either way, I suspect that it was set to ID3v2.3 and ISO-8859-1). Before or after that, I would have added APEv2 MP3 Gain tags. If you touch the MP3 file that doesn't work with MP3Tag (set to remove ID3v1 tags, keep/update APEv2 and ID3v2.3 ISO-8859-1) then the file plays okay. The odd thing is that if you then replace the working MP3 with the original (without SlimServer rescanning) then that MP3 will play okay.
Also, touching the broken MP3 with MP3Tag as ID3v2.3 UTF-16 or ID3v2.4 UTF-8 also fixes it.
Retagging is not an option. I have over 20,000 files. JLayer fixed it for me on some tracks, at least. I see this using 6.5.1 from 10/14 on SUSE Linux, with any SoftSqueeze version from 2.8 to 3.2.1 This is a critical bug IMHO.
Halfway through an album, I had to switch back to the Java MP3 to hear the rest of the tracks.
My old mp3s play just fine. The problems are with the ones I ripped using the latest 5.3 version of WinAmp. They made "improvements" in things like unicode support (http://www.winamp.com/player/version_history.php). But right now, I have had to stop using softsqueeze for mp3s :-(
I think the problem is with 6.5 in general. 1) I tried going back from 6.5.1 to 6.5 and still see this problem. 2) I see the same thing in SoftSqueeze 2.8 3) The first track of one album plays just fine with the mp3 plugin, but not the other tracks. They all have the same type of mp3 tags, so I do not think it can be the tags. And I tried retagging it to the .4 tag as suggested by ramage, with no effect. 4) JLayer does not always do the trick either. On another album, JLayer plays a very distorted version of the music. 5) This seems to have only crept in since switching to the latest WinAmp for riping. Foe example, they now use new codecs. 6) I still have problems with the latest SoftSqueeze jumping back to a previous screen and freezing its display. It was much improved from 6.5 to 6.5.1, but, for example this morning, the clock kept returning to 2 AM. No one seems to be looking at this serious issue. Is there a way I can provide more diagnostics?
I turned on debugging and looked at the SoftSqueeze console. This happens on a track that will not play (even with JLayer): 2004453 [SlimTCP-1] DEBUG player - buffer null state 0 2004453 [SlimTCP-1] DEBUG player - status=STMh fullness=0 bytesRx=0 elapsedSeconds=0 2004453 [SlimTCP-1] DEBUG player - initStream: state 1 2004453 [SlimTCP-1] DEBUG javasound - new decoder. ptr=0 2004453 [AudioStream-19] DEBUG javasound - audio stream started 2004563 [SlimTCP-1] DEBUG javasound - conversion required for MPEG1L1 48000.0 Hz, unknown bits per sample, stereo, unknown frame size, 125.0 frames/second, [javazoom.spi.mpeg.sampled.file.MpegAudioFormat] 2004563 [SlimTCP-1] DEBUG javasound - CONVERSION PROVIDER: javazoom.spi.mpeg.sampled.convert.DecodedMpegAudioInputStream@871e65 2004563 [SlimTCP-1] DEBUG player - autostart: state 2 2004563 [SlimTCP-1] DEBUG player - autostart: fullness=0 threshold=261120 2004563 [AudioDecoder-19] DEBUG javasound - decoder started 2004563 [AudioDecoder-19] DEBUG javasound - decodeFrame: fill buffer. available=0 fillLen=4096 slowStart 4096 2004563 [SlimTCP-1] DEBUG player - audg oldLeft=106 oldRight=106 newLeft=0.5000076 newRight=0.5000076 2004563 [AudioDecoder-19] WARN javasound - player thread exception java.lang.ArrayIndexOutOfBoundsException: 15 at javazoom.jl.decoder.LayerIDecoder$SubbandLayer1Stereo.read_allocation(Unknown Source) at javazoom.jl.decoder.LayerIDecoder.readAllocation(Unknown Source) at javazoom.jl.decoder.LayerIDecoder.decodeFrame(Unknown Source) at javazoom.jl.decoder.Decoder.decodeFrame(Unknown Source) at javazoom.spi.mpeg.sampled.convert.DecodedMpegAudioInputStream.execute(Unknown Source) at org.tritonus.share.TCircularBuffer.read(TCircularBuffer.java:135) at org.tritonus.share.sampled.convert.TAsynchronousFilteredAudioInputStream.read(TAsynchronousFilteredAudioInputStream.java:189) at org.titmuss.softsqueeze.audio.AudioDecoder.decodeFrame(AudioDecoder.java:367) at org.titmuss.softsqueeze.audio.AudioDecoder.run(AudioDecoder.java:333) at java.lang.Thread.run(Unknown Source) 2004563 [SlimTCP-1] DEBUG javasound - gain=0.5000076293945312 replayGain=1.0 dB=-6.0204673 max=6.0206 2005453 [Player Status] DEBUG player - write count 1081344 available 1017343
Today's build seemed to have fixed this. However, you need to use Softsqueeze 3.2.1 which is on the Sourceforge site, but NOT included in this build.
Does anyone else looking at this bug care to chime in about whether this is fixed or not? Richard, do you think this is fixed? :)
SlimServer v6.5.1 r10511 and Softsqueeze v3.2.1 work fine for me now. I've haven't tested it since the I opened the bug, so I have no idea when it was fixed. Since then I have done a complete uninstall and re-install, and a few wipe and re-scans (for reasons other than this bug), so I'm probably not the person to say "close". If it was fixed, then thanks to whoever did the fixing!
Unable to confirm whether recent builds have got to the root of the problem as I had already "fixed" my tags, and now not sure whether the problem is reproducable. I'm now running 6.5.1 build 10495, but only ever had this problem on WinXP - linux was OK.
I'm marking this as fixed as since it works for me. I don't having any MP3s anymore, so if it's still broken for someone else then it can be re-opened.
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.