Bugzilla – Bug 589
Transcoding WMA files fails when filename contains $
Last modified: 2008-12-18 11:55:31 UTC
Transcoding WMA files that have a $ dollar sign in them do not transcode into MP3 and stream. If you open task manager and watch it, you'll see LAME and WMADEC repeatedly run and stop, run and stop, run and stop. Simply rename a WMA file to have a $ in it. Add it to a playlist and click play. This problem does not occur when you stream MP3 files with a $ in them.
Have you tried the latest nightly? This issue shoudl already be fixed for the 5.3.1 release. http://www.slimdevices.com/downloads/nightly/latest/
I just installed the nightly build named SlimServer_v2004-09-29.EXE The bug still repros. No improvement seen.
can you try one more thing for this. got into server settings, performance click 'wipe cache' I belive we haven't marked the dbversion yet, so you have ot manually rescan like this in the nightly.
Created attachment 154 [details] wma file that won't transcode to mp3 I created this file with sound recorder. Encoded it into WMA, then used windows media player to add tags. I renamed the file to have the $ in it. Also changed the title tag to match. If you try to stream this file from slimserver allowing it to transcode from WMA to MP3, nothing streams. If you watch windows task manager, you will see it start and stop WMADEC and LAME yet nothing is streamed.
I downloaded the nightly named SlimServer_v2004-09-29.exe modified 29-Sep-2004 02:21. I wiped the cache as you asked. Sorry, the problem continues. I did find that WMADEC and LAME are stop/starting over and over because the slimserver UI had the REPEAT function set to all. When I set it to OFF, I only see them spawn once. But still nothing streams. I suspect they are failing immediately.
I just tried one of my own wma files renamed and it worked fine. I suspect there might be something else going on, but I'll try out yoru file. In the meantime, can you go into server settings, debugging. check d_source. open a browser window to http://serverIP:9000/log.txt play the wma in question and refresh the log.txt. paste that log here and we'll see what command line is coming up for the conversion
The file you have attached falls under bug5, where short clips are not played becuase the buffer doesn't fill. I'm not sure what the lower limit is, but for testing lets aim at something over 30 seconds at least.
Created attachment 155 [details] d_source debug log trying to play file with $ in it debug log as you asked. A suspicious backslash before the $ is present on the which shows the command its going to use.
the suspicious backslash is what should be there to escape the special character "$" from being interpreted as a command code. The problem in this snip of log really looks to be the duration of the track. I'd like to see a longer track played with the same debugging. I have only 3 WMA's to test with, but all play fine with $ in the filename, so I am curious to see the log if you are still having trouble with a full length song.
Created attachment 157 [details] 50+ sec file that won't transcode another file now 50+ seconds long. It fails to transcode. Save it and play it. It will fail to stream to mp3. Rename the file by taking out the $. Save it and play it. It will stream fine to mp3.
the longer sample works fine for me. again, if you are renaming files, you MUST wipe cache for the server to properly reindex the new filename. other than this, Dean may have to have a look at it, because I'm stumped.
lets let dean look at it. I'm pressing wipe after I rename it to include the $. And I wait until it no longer says its reindexing the db.
Dean, it appears this fails under windows, and NOT linux. it must be a problem with WMA dec accepting any filename with $ in it, even if its escaped.
vidur: is $ a reasonable character for wmadec?
Error code reported from wmadec: Opening stream failed with error code 0x80070003 this was done under win2k, sp4 using ffmpeg under linux, it works fine.
If $ is a reasonable character in a Windows filename, them wmadec should be able to deal with it...I'm just passing it along to the WM decoding methods. I'll see if it's being mangled somewhere along the way. If not, it's a Windows Media bug.
Yes, from the WindowsXP command line, I can name a file with a $ in it. I suspect the problem lies when you execute wmadec and try to escape the $ with a backslash. In the log above, notice that the $ has a backslash before it. In windows, that indicates a directory. So I suspect the file i/o system is looking for a directory named "Me saying test " and then a file named "$ here- Dale Phurrough.wma"
Backslash escaping is a bad idea. Source.pm line 1628 should be modified to not happen on windows. Vidur's typing it now.
Fixed in trunk. Will move to the branch shortly.
The trunk revision is change 3031, the branch is change 3032.
Using http://www.slimdevices.com/downloads/nightly/latest/6.0.2/SlimServer_v2005-04- 23.exe I verified that songs with a $ in their filename now play. Thanks.
This bug has been fixed in the latest release of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Routine bug db maintenance; removing old versions which cause confusion. I apologize for the inconvenience.