Bugzilla – Bug 6299
UNC handling inconsistency
Last modified: 2009-10-05 14:26:14 UTC
Squeezecenter will translate UNC paths in playlists to their equivalent mapped drive paths and index them using the mapped drive path. However, it will not translate UNC paths contained to music files in Windows shortcuts or to the paths entered into its settings for Music and Playlist folder. The (not fully tested) result is that if you use any UNC paths in any of the three places SlimServer will index any music referenced in playlsts twice, once using its UNC path and once using its mapped drive path. Work around: do not use UNC paths My preferred (and uninformed) solution: Slimserver recognises a file as being the same file whether it is referenced via UNC or mapped drive path and used the mapped drive paths to index music (as they are shorter). --------------------------- Installation details: SqueezeCenter Version: 7.0 - 15013 - Windows XP - EN - cp1252 Squeezecenter ruuns as an application. SqueezeMySQL service runs under an administrator account (as requires network access). All music and Windows shorcuts to music directories are held on another machine. All connections wired.
This conversion is done in Slim::Utils::Misc::fixPath() (around line 700). Additionally it's only done when SC is not run as a service. We should definitely unify this. But I'd rather do it the other way round, replacing drive letters with UNC paths, as mount points can change easily, whereas servers and shares might change less.
(In reply to comment #1) > We should definitely unify this. But I'd rather do it the other way round, > replacing drive letters with UNC paths, as mount points can change easily, > whereas servers and shares might change less. I like this solution. I brought this up in bug 3604. With the new Windows installer always installing SC7 to run as a user process, and then having users to later change this to a service, it's much more likely that these drive letter mappings will fail after the switch.
The main problem is that it's very expensive checking every file whether it's on a remote drive or not. We'd rather not mess with mapping those paths at all. I'll very likely remove that conversion.
Would preferences to designate drive letter mappings (Windows installations only) be a good/necessary idea? I know, everyone hates creating more prefs. If you run SlimServer under a user account that doesn't recognize the mappings used in playlists, then it will fail to find any files referenced by those drive letters. Also, if you run the server or scanner under an account that _does_ recognize the mappings, then do you have any way of knowing that a path is using a drive letter mapping and should be translated to a UNC path? Subsequently run the server under another account (whether as a service or as a user process) and it will fail to find the files. I don't see a good way to handle this without actually telling the server what drive letters are mapped to what paths. It would probably simplify the code as well.
Change 15455 - For now I've removed the code which mangled UNC paths in _some_ cases. We'll have to review this later and find a correct solution. I tend to store mapped drives as UNC paths in all cases. BTW: the performance issue I feared wouldn't be worse than what we had anyway. It did the same check already.
There's more work to do than we can for 7.0. Change target to 7.1
This seems quite risky, and since there's not a huge amount of interest, we're going to push it off for now. Feel free to stir up support on the forums and have users add votes and cc's. :)
Push it off even further.
Michael: do you think this could be handled by the new schema Brandon is proposing?
Not sure. Might be a side-effect of rewriting relevant code. But per se not a solution to this problem.
Might be covered by the new schema. Re-target for next major release.
I think this bug is fixed by the change mentioned before. After looking in to the remaining issue (converting mounted drive letters to UNC paths) again I think it doesn't apply here. Drive letters are stripped out of the file path to get relative paths anyway. Feel free to re-open this bug if needed.
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.