Bugzilla – Bug 12796
Trouble scanning files with diacritics
Last modified: 2009-10-05 14:37:29 UTC
eg. I have a playlist that references the path to a file #EXTINF:-1,Neunundfünfzig 49 M:\Music\Phil's Music\Electronic\Wolfram Spyra & Chris Lang\Achtundsechzig 24\01 - Neunundfünfzig 49.mp3 The new noweb-sqlite scanner doesn't seem to like this when processing playlists. The scanner log contains: [20:36:58.8625] Slim::Formats::Playlists::Base::playlistEntryIsValid (120) Warning: file:///M:/Music/Phil%27s%20Music/Electronic/Wolfram%20Spyra%20&%20Chris%20Lang/Achtundsechzig%2024/01%20-%20Neunundf found in playlist: file:///M:/Music/Slimserver/Playlists/Bad%20Tags.m3u doesn't exist on disk - skipping! [20:36:58.9443] Slim::Formats::Playlists::Base::playlistEntryIsValid (120) Warning: file:///M:/Music/Phil%27s%20Music/Electronic/Wolfram%20Spyra%20&%20Chris%20Lang/Achtundsechzig%2024/01%20-%20Neunundf found in playlist: file:///M:/Music/Slimserver/Playlists/Bad%20Tags.m3u doesn't exist on disk - skipping!
Andy will investigate this issue.
The M3U code has some nasty encoding checks, so lots of things could be going wrong... can you upload a copy of this playlist? FWIW I tested this on Mac and it worked fine for me.
Created attachment 5561 [details] Playlist that references a file with diacritics in the filename
Is this specific to the noweb-sqlite scanner?
No.
Andy - imho we have a very basic but important problem: File::Next fails on any non-latin character. Passing paths through Win32::GetANSIPathName() seems to fix the issue for me.
Created attachment 5790 [details] run filenames through GetANSIFileName() if needed
isn't this another occurence of bug 4578?
== Auto-comment from SVN commit #28486 to the slim repo by michael == == https://svn.slimdevices.com/slim?view=revision&revision=28486 == Fixed Bug: 12796 +4.5 Description: use Win32::GetANSIPathName() instead of home-grown string transcoder to fix non-latin character issues in m3u playlists
We might need to apply similar fixes in other places too. Helped with iTunes parsing before.
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.