Bugzilla – Bug 16319
Some files won't play -- depends on name of file
Last modified: 2018-01-15 04:35:32 UTC
I have SBS 7.5.1 on Mac OS 10.6.4. I find that some files won't play, but if I rename them, they will play. This is not a scanner and database issue. The result is the same if I try to play the files from the music folder browser, which apparently bypasses the database. The problem is very subtle, as I will illustrate with an example: Here is the name of a file, as seen from SBS music folder browser: 24 Rachmaninoff - Rhapsody On A Theme Of Paganini - Variation XXII - Un Poco Più Pivo (Alla Breve).m4a The file would not play. I changed the name of the file (from within itunes, so I also changed the title tag) to 24 Rachmaninoff - Rhapsody On A Theme Of Paganini - Variation XXII - Un Poco Più Pivo, Alla Breve.m4a Then the file would play. If instead, the file name ended in - Alla Breve it would not play. I changed back and forth between these variations on the name of the variation with consistent results. With the comma, it played, with parentheses or dash, no music. Everything clear, right? Well, no. This file is sitting in a directory with 31 files. If I made a test album with only one file in it, then the file would play with the original name, with parentheses, or with the dash.
(In reply to comment #0). > > This is not a scanner and database issue. The result is the same if I try to > play the files from the music folder browser, which apparently bypasses the > database. Browse Music Folder (BMF) uses the database just like all of the other browse modes. The scanner places the directory paths into the database and BMF gives the illusion of browsing through the directories.
> > Browse Music Folder (BMF) uses the database just like all of the other browse > modes. The scanner places the directory paths into the database and BMF gives > the illusion of browsing through the directories. The illusion is extremely effective! Changes I made in the file names were reflected immediately in BMF mode (upon refreshing the page in the web browser) without rescanning. Anyway, both the scanner + database and whatever mechanism BMF is using fail in the same way.
(In reply to comment #2) > > > > Browse Music Folder (BMF) uses the database just like all of the other browse > > modes. The scanner places the directory paths into the database and BMF gives > > the illusion of browsing through the directories. > > > The illusion is extremely effective! Changes I made in the file names were > reflected immediately > in BMF mode (upon refreshing the page in the web browser) without rescanning. > > Anyway, both the scanner + database and whatever mechanism BMF is using fail > in the same way. I verified the following: if I make a change in a file name, and then view the corresponding folder via Browse Music Folder, the change is then written to the database, so that I also see it in other browsing modes.
I looked around and found whole CD's worth of my music that won't play in 7.5.1 (also in 7.5.0). So, for me, this is not just a matter of a few oddball files.
Some more observations. First of all, 7.4.2 works fine. Second, there are effects of scale. My library has about 30,000 tracks and 2000+ albums. I chose from this library one album that will not play at all under 7.5.1 (but will play under 7.4.2). I changed my music folder to an empty folder, and copied the one "bad" album to this folder. From my new library of 29 tracks and 1 album, the files do play under 7.5.1.
Created attachment 6911 [details] error log
The error is occurring in transcoding from apple lossless. I have attached an error log, see previous comment. Note in particular at [10-07-11 15:29:50.0396] a "tokenized command" is formed with an o-umlaut changed to some other character.
Faad is failing. I tried running the command constructed by SBS to play the suspect file, from OS X terminal. The file made by faad failed as input to sox. [imac:~] fgoodman% "/Library/PreferencePanes/Squeezebox.prefPane/Contents/server/Bin/darwin/faad" -q -w -f 1 "/Volumes/Media drive/media/Music/iTunes Music/Gardiner, John Eliot; Monteverdi Choir & English Baroque Soloists/Bach_ Matthaeus Passion (Disc 1_3), Gardiner, Monteverdi Choir, English Baroque Soloists/01 1.Teil - Kommt, Ihr Töchter, Helft Mir Klagen - O Lamm Gottes, Unschuldig.m4a" | "/Library/PreferencePanes/Squeezebox.prefPane/Contents/server/Bin/darwin/sox" -q -t wav - -t flac -C 0 out.flac /Library/PreferencePanes/Squeezebox.prefPane/Contents/server/Bin/darwin/sox FAIL formats: can't open input `-': WAVE: RIFF header not found
The failure of faad depends on the whole path (or the complexity of the path) to the M4A file. I moved the file on which faad failed (comment 8) to a location with simpler path, and did the following: [imac:~/SQUEEZEBOX] fgoodman% "/Library/PreferencePanes/Squeezebox.prefPane/Contents/server/Bin/darwin/faad" -q -w -f 1 /Users/fgoodman/SQUEEZEBOX/01\ 1.Teil\ -\ Kommt,\ Ihr\ Töchter,\ Helft\ Mir\ Klagen\ -\ O\ Lamm\ Gottes,\ Unschuldig.m4a > out.wav [imac:~/SQUEEZEBOX] fgoodman% "/Library/PreferencePanes/Squeezebox.prefPane/Contents/server/Bin/darwin/sox" -q -t wav out.wav -t flac -C 0 out.flac A good flac was produced. Just to check that the failure in comment 8 was not dependent on the unix pipe, somehow, I did the experiment again with the file in its original location: [imac:~/SQUEEZEBOX] fgoodman% "/Library/PreferencePanes/Squeezebox.prefPane/Contents/server/Bin/darwin/faad" -q -w -f 1 /Volumes/Media\ drive/media/Music/iTunes\ Music/Gardiner,\ John\ Eliot\;\ Monteverdi\ Choir\ \&\ English\ Baroque\ Soloists/Bach_\ Matthaeus\ Passion\ \(Disc\ 1_3\),\ Gardiner,\ Monteverdi\ Choir,\ \ English\ Baroque\ Soloists/01\ 1.Teil\ -\ Kommt,\ Ihr\ Töchter,\ Helft\ Mir\ Klagen\ -\ O\ Lamm\ Gottes,\ Unschuldig.m4a > out.wav [imac:~/SQUEEZEBOX] fgoodman% "/Library/PreferencePanes/Squeezebox.prefPane/Contents/server/Bin/darwin/sox" -q -t wav out.wav -t flac -C 0 out.flac /Library/PreferencePanes/Squeezebox.prefPane/Contents/server/Bin/darwin/sox FAIL formats: can't open input file `out.wav': WAVE: RIFF header not found
I suspect that this is a duplicate of bug 10199, in which case it should be fixed in 7.6. It would be helpful if you could verify this.
I reported a proposed fix to this bug to Andy Gundman by private email in early December 2010. I don't know whether he ever had the chance to follow up. The fix consists in changing the length of three file path character arrays in main() in the SBS version of faad from [256] to [512]. I have been running SBS 7.5.2 with this fix since early December without any repetition of the problem, so I do think this fixed it. My hypothesis is that this has nothing to do with unicode, but rather with the length of the file path. Probably very few users would experience this problem, but I have long file paths because I pack a lot of information into the album title for classical music (actual album title, composer, performer). When, in addition, the track title is long and the path involves some unicode characters, which in OS X are multiple byte sequences, the file path length can get pushed over 256 characters. Then the path gets truncated by faad and the file is not found.
could you please attach your patch to this bug report?
(In reply to comment #12) > could you please attach your patch to this bug report? Sorry, I don't know how to use diff. My changes consist in changing the following lines in faad2-2.7/frontend/main.c char aacFileName[255]; char audioFileName[255]; char adtsFileName[255]; In each line, I changed [255] to [512].
I wonder if this couldn't be fixed at some point. It couldn't be take than a few minutes work. The fix is provided in the previous comment (comment 13). Thanks.
This should finally be resolved in 7.9.1. Thanks ralphy!
Latest LMS 7.9.1-1515659378 broke playback for me on Mac OS X. Previous version 7.9.1 - 1515216179 from several days ago works. Did FAAD get broken again? The behavior is similar to that which prompted this bug report but I haven't tried looking at server logs to work out what is happening.