Bugzilla – Bug 15073
Need aliasing for library paths in iTunes logic for Squeeze Server.
Last modified: 2009-11-10 10:47:48 UTC
I have a large music library located on a Windows Home Server which runs Squeezebox Server. On the Squeezebox Server setup I have directed the software that my music folder is d:\shares\music. I also have an iTunes XML file that I use that references the same files but for the file location refers to them as being in \Volumes\music (the XML file comes from a Mac that points to the music share as an SMB volume). Squeezebox Server is able to sort this out and sets up iTunes library integration successfully. iTunes tracks\playlists are playable and life is good. Almost. I end up with two sets of all albums/artists/etc showing up in Squeezebox Server as a result of this minor difference in path reference between iTunes and the regular "music" setup path for Squeezebox. This is annoying and also uses up system resources dealing with 16,000 music tracks instead of the 8,000 I actually have. What would resolve this issue is an option for iTunes integration that either ignores differences in the music path (so that music only shows up one time) or the ability to equate the music path in the Library XML file with the music path populated on the main settings page of Squeezebox Server. If any logs, XML file structures, etc, are needed for inclusion of this much needed enhancement please respond to this bug report and I will attach them.
Steven thinks this is a duplicate bug, so he can figure out what it's a duplicate bug. Maybe the workaround is for the user to put the UNC paths into SbS instead of D:\foo
UNC path name was present in the music folder on the main settings page. However, you are correct, it was not set on the iTunes music folder setting. It was set to D:\foo as indicated. Changing this to the same UNC path name that appears in the main server settings appears to have resolved the problem. It's worth noting that the dialogue box on the iTunes page for the location of the XML library file will not accept a UNC path name however (it will only accept a "real" hard path on the local disks). This however does not appear to be breaking things at the moment.
Steven, the file path translation is long gone in iTunes. Originally patched in to allow users to place their xml file on a linux-server, it never worked correctly due to the huge variation of path formats, and mixed library locations. I don't believe there was any intent from that point on to support iTunes xml files from installations other than on the same computer as the server itself.
kdf, thanks so much for your comment. So really at this point if it works at all it is really just luck. This bug will probably be a wont fix. Andy, what do you think? canyoncarver, one thing I did want note that one should only use UNC paths on Windows Home Server. From the Windows Home Server Technical Brief - Drive Extender: Important If you want to access files in shared folders, always access them through the shared folder name (\\server\SharedFolderName or \\localhost\SharedFolderName). If you browse the file system through administrator's desktop, you will discover multiple places where you might think your data is stored, but your data is likely stored elsewhere. Accessing \\server\SharedFolderName or \\localhost\SharedFolderName from the administrator’s desktop ensures that you will find your file without a performance issue. The document is available here: http://www.microsoft.com/downloads/details.aspx?FamilyID=40C6C9CC-B85F-45FE-8C5C-F103C894A5E2&displaylang=en
Steve, That makes sense, but leaves me in a bind with pointing to the iTunes XML file, since the software will only accept a hard path to the iTunes XML Library file. Maybe there is room in a later version to specify access to this file via UNC pathname, etc. I manually copy the Library XML file from my iMac to the WHS and then need to point Squeezebox server to the file somehow so that it can build my iTunes playlists. (In reply to comment #4) > kdf, thanks so much for your comment. So really at this point if it works at > all it is really just luck. This bug will probably be a wont fix. > > Andy, what do you think? > > canyoncarver, one thing I did want note that one should only use UNC paths on > Windows Home Server. > > From the Windows Home Server Technical Brief - Drive Extender: > > Important > If you want to access files in shared folders, always access them through the > shared folder name (\\server\SharedFolderName or \\localhost\SharedFolderName). > If you browse the file system through administrator's desktop, you will > discover multiple places where you might think your data is stored, but your > data is likely stored elsewhere. Accessing \\server\SharedFolderName or > \\localhost\SharedFolderName from the administrator’s desktop ensures that > you will find your file without a performance issue. > > The document is available here: > http://www.microsoft.com/downloads/details.aspx?FamilyID=40C6C9CC-B85F-45FE-8C5C-F103C894A5E2&displaylang=en
On the plus side, xml is something easily adjusted with find/replace in any text editor. You can do the custom changes you require depending on what path matches work for your system. The reason the SbS import failed was because it was hard to deal with the different points of mounting/nameing and multiple paths (and worse, contents of the library that were NOT accessible from SbS). When it worked (to be honest, I think it really only worked with windows/linux anyway), it would only work if the share was directly to a mapped root and could all be found in one path accesible from SbS. It was also easily broken any time Apple tweaked their xml template. With find and replace, you can set up a script on the mac to make the changes any time you make a copy and it can be tailored directly to your needs. Perhaps, if there IS a 'fix' for this kind of case, it could be a sample script in the tools folder that copies and preps the xml file, customised with a few edits of the first few lines of the script.