Bugzilla – Bug 5128
Socketwrapper errors when using LAME
Last modified: 2007-07-23 14:02:52 UTC
When i try to use lame to lower the bitrate for remote streaming i will get socketwrapper errors It's working fine if i don't use lame to transcode to lower bit rate try both 6.5.2 and 6.5.3 same issue attach snapshot of the error from my windows XP machine
Created attachment 2054 [details] Socketwrapper error
Is this for remote radio streams or for local files? If local files, the latest 6.5.3 should avoid using socketwrapper and not have this problem.
The files are MP3 320kbps and the customer try to transcode them to 128mbps to stream it over the network. I will ask the customer to try the streaming with 6.5.3
I also have a customer trying to listen to local WMA files via LAME; he gets the Socketwrapper crashes also. What was changed exactly between 6.5.2 and 6.5.3 re: Socketwrapper?
Latest 6.5.3 does not use socketwrapper when transcoding is performed for local files. Socketwrapper is only used when transcoding of a remote radio stream is performed. This does not remove the case of crashing socketwrapper, but stops using socketwrapper in most cases. It actually reverts use of socketwrapper to its original intention prior to the original fix for bug 4318 in 6.5.2.
I created version 1.9b of socketwrapper to fix the socketwrapper (1.8 and earlier) crash reported in comment 43 of bug 4544 but nobody has tried it out or reported success/failure. Can you try it out to see if it fixes the socketwrapper crash you are experiencing. The new veraiobn can be found here. Unzip and replace current socketwrapper.exe. http://homepage.eircom.net/~altondsl/slim/socketwrapper19b.zip
I spent some time testing socket wrapper 19b yesterday and wasn't able to produce any problem. I tested Internet radio, transcoding, and bitrate limiting all without issues.
Were you able to create the crash with 1.8 ? I found it hard to reliably crash 1.8 and so it is desirable for somebody else to make 1.8 crash and then test with 1.9b to ensure it didn't crash under same tests.
I've been trying to reproduce the crash with 1.8 and I've not been able to. Tomer is it specific to some flac files?
Ross When i tested it myself i was using MP3 with 320kbps and transcoding it to 64kbps I didnt try with Flac but i think it will be the same if you use the option to lower the bit rate
Tomer, Describe the remote streaming - are you using an SB3 or a Player such as winamp, WMP on the remote link ?
Bryan I'm using iTunes on my MAC to play the stream with the http://localhost:9000/stream.mp3 option to stream MP3 from my PC using the LAME encoder to lower the bit rate to 64/128mbps
Tomer, does the crash happen if the stream plays without interruption or have you used "pause" at some time ? The crash situation is very similar to Olivier's report in bug 4544 - streaming using stream.mp3 to a remote PC over a network connection and using a generic player such as Winamp for Olivier or iTunes for Tomer.
I just started to play the stream in iTunes using the URL option it was working fine for a min and then i change the settings in SLimServer to limit the bit rate to 128mbps and the error come right up
Tomer, Can you replace your socketwrapper by version 1.9b to be found at this link http://homepage.eircom.net/~altondsl/slim/socketwrapper19b.zip This version fixed one form of socketwrapper crash - your crash may be the same so it would be useful to test it.
This will be my 3rd comment to this bug mentioning that I cannot reproduce this. Has anyone outside of Tomer managed to reproduce this, maybe could you attach a file? Are we certain we should hold up committing the new socketwrapper which fixes bug 5164 based on this bug?
If no one can reproduce, it could be marked as "WORKSFORME" and if Tomer can get around to testing again with the new socketwrapper then it can later be marked as verified or reopened. I don't think it should hold up committing a fix for another bug.
Shadowboxer had the crash repeatedly and has recently confirmed that only changing socketwrapper to v1.9b the crashes stopped. So I think the bug can be marked as kdf suggested. See this thread - post 12 is the confirmation http://forums.slimdevices.com/showpost.php?p=215869