Bugzilla – Bug 4892
iTunes scanner problems with case in filenames
Last modified: 2011-11-06 23:23:08 UTC
Background - I am running slimserver on an Ubuntu box with a samba share. - I manage my music using iTunes on a Windows box hanging off the Samba share. - I create my slimserver database by using the iTunes scanner - slimserver is not finding all of my iTunes music when it scans the xml file (manual scan log and itunes xml files attached) - I have checked for this bug in bugzilla, but haven't found anything that seems to address this particular problem. Issue: The problem appears to be that iTunes is creating all of the Album folder names with capitalised letters. For example: - A Passage In Time - Business Of Punishment - Feast Of Wire However, iTunes is recording the path name for the files in the xml file using the exact case of the album name. For example: - A Passage in Time (lowercase in) - Business of Punishment (lowercase of) - Feast of Wire (lowercase of) (iTunes stupidity indeed!) The scanner then fails to find the file as it is looking for an exact case match ("file not found" error in the log files). I believe this would not normally be a problem when using Windows because of the case insensitivity in file names. However, the system is falling over because I am running slimserver on the Ubuntu box, which is requires the correct case for file names. As a work around - you can run a manual scan - find all of the "file not found" albums in the log - change the case of the album folder name to match the iTunes path (e.g. Business *Of* Punishment to Business *of* Punishment) - rescan (I also tried changing the album name in iTunes, but this had no impact on the path name - I suspect that iTunes tends to force lowercase on short words like "in" and "of" when creating pathnames). However, this is a bit of a pain. Could we instead have slimserver check if the xml file was generated by a Windows version of iTunes and if so, can it then use case insensitive methods for filename/filepath manipulation? I also understand that this is a piece of iTunes stupidity rather than a slimserver problem, but I really doubt that Apple will care enought to fix it (I'm guessing it shouldn't be too hard to address in slimserver). Thanks Larry
Created attachment 1896 [details] Zip file containing scan log and itunes xml folder
Hmmmm - looks like iTunes is only consistent when importing the album. The Dead Kennedys "Give Me Convenience Or Give Me Death" folder was created with a lower case or, but the iTunes path name was an upper case Or
Hopefully this will be my final addition to this report. After a bit more digging, I think I can explain how this problem arises. - When iTunes creates a folder for an artist or an album, the case in the file name matches the information taken from CDDB or mp3 tags as appropriate. For instance, addding the artist "K. D. Lang" creates a folder using that case. - If new albums are created for the same artist, iTunes using the existing folder. Likewise when adding new tracks to an existing album (such as may happen when replacing an AAC collection with an MP3 collection), the existing folder name is used. - The problem arises if the new album or artist name is imported with a different cases to the cases used in folder creation. iTunes is smart enough to recognise that "k.d. lang" and "K. D. Lang" are the same artist and puts their albums in the same folder. - However, iTunes isn't smart enough to correct the xml path names, so in the artist case we end up with the path name for one album including "k. d. lang" and the other including "K. D. Lang". In the case of importing the same album twice with slightly different cases, iTunes puts all tracks in the one album folder, but creates two xml file paths with different cases.
Maybe a simple solution would be to have the iTunes xml scanner be case insensitive when it comes to file paths. I am not sure what kind of impact that would have at the moment and more investigation would be needed. I believe another workaround for now would be to disable "Keep iTunes Music folder organized" under the Advanced tab in Preferences. I believe this would only work for files added after this option was changed though. I also wonder if there is a way to force iTunes to update the xml before SlimServer scans it.
Larry, see if this works for you: 1. Make sure that iTunes is not running, this may not matter 2. Rename the "iTunes Music Library.xml" to "Old iTunes Music Library.xml" or similar for backup 3. Run iTunes, verify everything looks as it should 4. Quit iTunes, should create new "iTunes Music Library.xml" 5. Run a Rescan in SlimServer, may have to do a "Clear library and rescan everything" 6. See if missing files are found Moving or renaming the "iTunes Music Library.xml" should force iTunes to create a new one and hopefully update the file paths with the proper case. I have not tried this myself yet but it may turn out to be an easier workaround for now.
(In reply to comment #5) > Larry, see if this works for you: > Steven, I gave your process a try - unfortunately it appears that iTunes maintains all of the original case data within the .itl file and recreates the .xml file without reference to the actual filenames or file paths. Thanks for the suggestion though. I'm quite surprised this hasn't turned up as a bug previously - a lot of people seem to run slimserver on Linux based NAS/sever boxen and also use iTunes. Cheers, Larry
I was afraid of that, thanks for trying though. Something else to try would be to delete all the files from within the iTunes program, without deleting the actual files of course, and then import them again using the add to library function. I don't know if this would fix any preexisting playlists in iTunes though. More information about this on the Apple site: http://docs.info.apple.com/article.html?artnum=93313 http://docs.info.apple.com/article.html?artnum=301509
(In reply to comment #7) This will deal with the album problem, but won't deal with artists with names in two cases. It will also result in losing data such as ratings. At this stage, I'm happy enough with the available workarounds (with luck, I will even get to putting some on the wiki). I can now happily wait until the bug is resolved. Cheers, Larry
Larry, can you update on this bug? i am kinda confused. what does itunes have to do with the SBS scanner? are you saying the SBS scanner isn't ignoring case properly in folders and files?
(In reply to comment #9) Mike, Short answer - On a Linux box, the scanner is case sensitive. This causes problems when running a) iTunes on Windows with the library stored on a Samba share on Linux box. iTunes pays no attention to case in creating file and folder names (per windows convention), but the Samba box follows case sensitive naming conventions. b) running slimserver on the linux box, where the scanner can't find some files because the filepaths in the itunes .xml file don't have consistent cases with how they are stored. This is a 4 year old bug for 6.5.1. Since this time, I have given up on using Linux. Slim devices have also since managed to alternately break and fix iTunes integration around scanning in several new and interesting ways (my personal favorite being accented characters, which alternate randomly between working and completely borked in any given release). Larry
ah, i see... but just concerning this bug then, do you have an idea or suggestion as to how to fix it? what needs to happen to make it work?
(In reply to comment #11) > ah, i see... but just concerning this bug then, do you have an idea or > suggestion as to how to fix it? what needs to happen to make it work? I'm not sure that it hasn't already been addressed in later releases - I no longer use this set up, so the problem went away for me. Here would be my suggestion: - Add a switch in the iTunes menu that allows the user to select "Case insenstive scanning" (this is effectively the default). - When the scanner looks for a file defined in the iTunes .xml file, it should use a case insensitive file read/lookup/touch (I would expect the perl functions would support this out of the box to allow interoperability between case sensitive and case insensitive operating systems). As I noted in my comments on this, the problem is iTunes side, not slim devices. But also as noted below, we are less than likely to see a fix from Apple. Cheers, Larry
Unassigned bugs cannot have a priority.