Bugzilla – Bug 4705
Transcoding failure: AAC files with long filenames
Last modified: 2009-10-05 14:35:40 UTC
Slimserver will just skip the file if you try to play one. Renaming the file using less then 64 characters will allow the file to play. ALAC files did not produce the behavior. Mac OS X did not produce the behavior either. Files for testing are available at bug 4019. Chris, should Dan be assigned this one?
Does it also fail on Linux, or just Windows? What does a --d_source log show when the file is skipped?
Created attachment 1784 [details] Log file with d_source selected. Andy, I did not try with Linux just with Mac OS X and Win XP. Would you like me to try with Linux? I attached the log for your perusal.
Thanks. I expect it will work fine on Linux too. It's probably something to do with the length of the command line used for transcoding.
I did notice that ALAC files with long file names did not seem to be affected even though they have the same extension.
May be a duplicate of Bug 4206.
Some of the users that think they are experiencing bug 4019 may be actually affected by this bug. I have increased the severity accordingly.
The error getting reported in the log attached is the same one found in several of the other bugs fixed with the latest socketwrapper.exe. Is this specific problem still happening with 6.5.3? If so, is the log showing anything different this time?
Created attachment 2037 [details] New d_source log 6.5.3 Yes, I still see the problem with 6.5.3. However instead of just skipping the tracks it just stops playing. I think this is because of change 12211. New log attached.
I don't know why there are no track start events in that log. I still need to test my changes on Windows. I made another change today, so try tonight's nightly, but I don't know if it will help with this issue.
Created attachment 2038 [details] Log of first file playing then stopping after I reversed the order of the playlist so the shorter named file is first and thus plays then stops when it gets to the longer named second file. I hope the new log may shed some light.
I've put in a fix, change 12216, that should allow these tracks to be properly skipped. There is still a bug in socketwrapper that needs to be fixed here though.
This is actually a mov123 bug, and I found this reference on apple.com: http://developer.apple.com/qa/qa2005/qa1413.html A: There's a limitation in the current version of QuickTime which restricts any file name plus extension to 63 characters or less. The full path may still be MAX_PATH (see WINDEF.H) characters long, but the file name must be 63 characters or less. We hope to relax this limitation in a future version of QuickTime. But there is a workaround for this bug, to use faad instead of mov123 to decode AAC. See the instructions on the AAC wiki page, http://wiki.slimdevices.com/index.cgi?AAC 1. Download faad.exe from http://rarewares.org/aac.html, putting it in the server\Bin\MSWin32-x86-multi-thread directory. 2. Create slimserver-convert.conf from the example in the wiki page. 3. Under File Types, select only faad/flac. 4. Long file names should now play properly.
*** Bug 4206 has been marked as a duplicate of this bug. ***
Is using faad something we should consider moving to in the long term?
We can't distribute faad because of patent issues, but Dean said he would look into the licensing. Ideally we would like AAC support in the firmware. :)
Chris, should this one be unassigned?
No it looks like it should be assigned to Dean or marked as 'wontfix'
We'll move to faad after 7.0.
Whatever happened to the faad plan, dean?
On bug 8562 Dean says we're not doing FAAD.
(In reply to comment #20) > On bug 8562 Dean says we're not doing FAAD. Chris, I see no mention of FAAD in Bug 8562. Am I just missing it or did you intend a different bug number?
(In reply to comment #21) > (In reply to comment #20) > > On bug 8562 Dean says we're not doing FAAD. > > Chris, I see no mention of FAAD in Bug 8562. Am I just missing it or did you > intend a different bug number? It would help if Chris was on the CC list ;)
There's information on setting up FAAD on our forums at http://forums.slimdevices.com/showthread.php?t=41673
I think that the only solution here is to move to faad or note the restriction on 63-character filenames as a hard restriction. Assigning to Mickey concerning license issues for faad.
Still working with lawyers. Moving to future release.
SC now running with faad. Needs QA to verify this is no longer an issue.
The change from mov123 to faad for aac was actually implemented in 7.3.3 so this should no longer be an issue. Please reopen and add additional comments if you still see this issue with 7.3.3 or higher.
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.