Bugzilla – Bug 17411
UNIX SBS bad pathname translation of playlist paths containing backslash
Last modified: 2011-08-21 16:53:07 UTC
I am unable to include a pathname containing a backslash in a playlist. Example Playlist: daisy% cat /shared/playlists/test.m3u /music/misc/Radius System - Escape\Restart/06-RadiusSystem-IntoOrbit.mp3 /music/misc/Bourbonese Qualk - Laughing Afternoon/spanner_in_the_works.mp3 daisy% ls -l '/music/misc/Radius System - Escape\Restart/06-RadiusSystem-IntoOrbit.mp3' -rw-r--r-- 1 ip wheel 5681280 Jan 29 2010 /music/misc/Radius System - Escape\Restart/06-RadiusSystem-IntoOrbit.mp3 daisy% After a playlist rescan, I only see the second file in the browser, because: [11-08-07 12:46:16.6401] Slim::Formats::Playlists::Base::playlistEntryIsValid (120) Warning: file:///music/misc/Radius%20System%20-%20Escape/Restart/06-RadiusSystem-IntoOrbit.mp3 found in playlist: file:///shared/playlists/test.m3u doesn't exist on disk - skipping! This appears to be an attempt at making things easier for people moving playlists between Windows and everything else by mapping backslashes into forward slashes. But a backslash is a valid character in a UNIX pathname, and I don't see a way of turning this off. What would be nice is user-definable mapping as suggested on the Beta forum recently and in several bugs (dating back to 2005!).
I can't reproduce your problem using 7.6.1rc3 on a QNAP NAS (running Linux): [/share/Multimedia/Musique/flac/Royksopp/Melody A.M.] # ls -1 *40* 10. 40 Years Back\Come.flac [/share/Multimedia/Musique/playlists] # grep 40 Test.m3u #EXTURL:file:///share/Multimedia/Musique/flac/Royksopp/Melody%20A.M./10.%2040%20Years%20Back%5CCome.flac #EXTINF:285,40 Years Back\Come /share/Multimedia/Musique/flac/Royksopp/Melody A.M./10. 40 Years Back\Come.flac This playlist scans and plays perfectly from SBS (which is cool since SBS has generated it.)
Have you tried just putting the pathname into a text file and scanning it? The reason it works for you is that SBS created the playlist file. As you can see, it embeds URL-encoded versions of the pathnames in comment lines, and uses these rather than the raw pathnames. OK, I'll confess. Logging this bug is a bit of a troll (thanks for biting!). I know that this is easily fixed for me by removing $file =~ s/\\/\//g; from fixPath in Slim/Utils/Misc.pm. But this breaks the kludged translation of Windows paths in playlists when SBS is run on a non-Windows system (bug 236). What I'd really like to see here is the ability to tailor the pathname translation. So, for example, people who run SBS on their NAS but edit their playlists on Windows could specify a mapping from their music folder as seen on Windows (e.g. M: or \\server\\music) into how it appears on their NAS (e.g. /data/music), and also be able to enable/disable the translation between "/" and "\". The code to do that is pretty simple, but unfortunately involves adding one or more items to server.prefs, which looks rather complicated. Also, arguably, these pathname translations would need to be set up via the GUI (because people can't edit prefs files), which is a huge task if you don't know what you're doing. Otherwise this epistle would contain a patch rather than a whine. :)
(In reply to comment #2) > Have you tried just putting the pathname into a text file and scanning it? > > The reason it works for you is that SBS created the playlist file. As you can > see, it embeds URL-encoded versions of the pathnames in comment lines, and uses > these rather than the raw pathnames. You're right, the file's ignored although the backslash character is correctly escaped in the m3u file: /share/Multimedia/Musique/flac/Lisa Ekdahl/Give Me That Slow Knowing Smile/01. Give Me That Slow Knowing Smile.flac /share/Multimedia/Musique/flac/Royksopp/Melody A.M./10. 40 Years Back\\Come.flac /share/Multimedia/Musique/flac/Zero 7/The Garden/07. Today.flac (this is what the m3u file looks from vi) Confirmed.