Bugzilla – Bug 4206
Failure to transcode AAC encoded files with long file names
Last modified: 2008-12-18 11:12:53 UTC
System: Windows XP (all updates), Quicktime 7.1.3, SlimServer 6.5.0 - 9916 AAC files with very long file names fail to play. Culprit seems to be the mov123.exe (see: http://forums.slimdevices.com/showthread.php?t=22971 ), which chokes on the long names (more than 59 characters in any part of the file path or name, see post #5 in the forum thread mentioned above). Renaming the files to shorter names fixes the problems, but is quite tedious, when one manages a 25.000 song library with iTunes, which produces those long file names. Any way to fix mov123 to transcode files with longer file names? Thanks, Alexander.
Ross could you have a look at reproducing this?
I did eventually reproduce this by putting the attached file (1234567810123456782012345678301234567840123456785012345678601234567.m4a) in the directory "C:\Documents and Settings\Administrator\My Documents\My Music\iTunes\iTunes Music\Us3\This directory name has to be extremely long asdflkjaslkjhasdlkhjasdlasdlfaslflashalskjhlakhalskjhlas" 67 characters file name 87 characters to the end of the ...\Us3\ 102 characters in final directory name ---- 256 characters total, which seems to be a hard limit in XP. I.e. Windows won't let me type any more characters into the rename box. I'm not clear on exactly what's happening with mov123, but on my system from the Windows task manager it looks like mov123 is consuming a lot of CPU, and slimserver is relaunching it over and over. Is that the message board thread you meant to reference? It looks like that discussion is somewhat old, and talking about Slimserver 6.21.
Created attachment 1604 [details] itunes aac file with ridiculously long filename
Christopher, thank you for looking into this! I think I first noticed the bug last year in May when I startet using iTunes on my PowerBook to organize my music library. Since then I worked around by copying my library to my Windows server (which is running SlimServer) and consolidating the library using iTunes for Windows which would then truncate all long names to a length SlimServer was apparently able to handle. With the introduction of version 6.0 (or was it 5.0?) iTunes ceased to truncate the names, though. That's when I went out of luck. I just recently stumbled over this old post from April 2006, which led me to believe that indeed mov123 is to blame. From my experience it's not so much the total length of the path but the length of the file name itself, as described in post #5 of the aforementioned thread: http://forums.slimdevices.com/showpost.php?p=101997&postcount=5 Alexander.
> I'm not clear on exactly what's happening with mov123, but on my system from > the Windows task manager it looks like mov123 is consuming a lot of CPU, and > slimserver is relaunching it over and over. I havn't noticed this kind of behaviour. SlimServer just skips those "long" songs, simply playing the next in line ...
Bug 4705 may be a duplicate.
I've posted a workaround for this bug in bug 4705, it uses faad to replace mov123. These 2 bugs are really dups, so if someone wants to consolidate them, go for it.
*** This bug has been marked as a duplicate of 4705 ***
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.