Bugzilla – Bug 1106
Missing convertPath in exportFunction
Last modified: 2008-08-18 10:53:01 UTC
the exportFunction does not properly call the convertPath function before converting the file path into a URL. If the MusicMagic returns Win32 based paths then the Slim::Utils::Misc::fileURLFromPath($songInfo{'file'}); call generates a traceback. The following patch fixes the issue: *** Plugin.pm.orig 2005-03-15 22:42:47.460985494 -0500 --- Plugin.pm 2005-03-12 23:31:07.000000000 -0500 *************** *** 417,422 **** --- 417,424 ---- $songInfo{$song_field} = $song_value; } + $songInfo{'file'} = convertPath($songInfo{'file'}); + $cacheEntry{'TRACKNUM'} = $songInfo{'track'}; if ($songInfo{'bitrate'}) {
Michael - what's the error case for this? One of our more intense users of MMM is on Win32, and it hasn't come up before.
In my case, the error case is a hetergeneous environment. Slimserver executes on linux, MMM executes on Win32. MMM on Win32 returns win32 paths, linux expects UNIX paths the convert path function is used to convert the win32 path to the unix path using the "remotePath" MMM profile setting. I have not tried the inverse relationship (i.e. slim on win32 and MMM on linux)
ah, unfortunately. This feature is not properly supported by the musicmagic sofware. There was mention of remote access, so when I was given a patch from a user, I felt it was ok to go with it until something better came along. The eventual support from MusicMagic isn't quite what I had expect (tho may have some possible use in teh future). The implementation in slimserver for remote access is a weak hack, and is able to work in only specific setups, only covering a small group of possible configurations common to slimserver. As such, the remote access features are turned off as of yesterday. for example, this set doens't handle unc paths, or music from multiple paths. I'm personally not interested in taking on that support headache. however, I have said my peace, and I'm not going to complain either way if the official decision is to bring this back or not, or in some other form.
Removing the code that causes the problem is probably the best choice. However, there are probably better descriptive choices for the code than "weak hack". Please close the bug.
sorry, yes, bad choice of words. no offense was intended. it was meant as a descriptive of the ability of the code/api, not to its creator.