Bugzilla – Bug 7507
Latest beta builds fail to scan dirs/files with names contaning non-latin chars
Last modified: 2009-07-31 10:18:03 UTC
For me it means that ~25% of my archive is not accessible anymore. Last known to work build: 17830. Note: seems like non-latin chars in tags are not an issue.
Forgot to mention: Debian/unstable, updated on daily basis. System-wide locale set as LANG=ru_RU.KOI8-R LC_MESSAGES=C ==== SqueezeCenter Version: 7.0.1 - 17830 - Debian - EN - koi8-r Perl Version: 5.8.8 i486-linux-gnu-thread-multi MySQL Version: 5.0.51a-3 Platform Architecture: i686-linux ====
Ok, now we're seeing a pattern. This issue seems to be related to change 17864 - targetted at fixing bug 6621 :-/. Could you please set logging for scan.* to debug, run a full scan and upload the scanner.log file to this bug? If you've got a large collection, try limiting the scan to some folder showing this issue. Steinar - I'm CCing you, as you reported that issue in 6621 first. Could you please do the same? Thanks!
Can you confirm that those files are found if you run the scanner manually from the command line? scanner.exe --wipe /path/to/your/music/files
Michael, I've sent logs you've requested over an e-mail. Sorry for delay. Thank you, Nick Orlov.
Thanks for the log - will take a look at it. What about the manual scan I mentioned in my previous comment? Would it work for you?
*** Bug 7529 has been marked as a duplicate of this bug. ***
Patch to revert the change causing this issue: Index: D:/eclipse/trunk/server/Slim/Utils/Prefs/Namespace.pm =================================================================== --- D:/eclipse/trunk/server/Slim/Utils/Prefs/Namespace.pm (revision 17894) +++ D:/eclipse/trunk/server/Slim/Utils/Prefs/Namespace.pm (working copy) @@ -29,7 +29,7 @@ use Slim::Utils::Prefs::Client; use Slim::Utils::Log; -$YAML::Syck::ImplicitUnicode = 1; +#$YAML::Syck::ImplicitUnicode = 1; my $log = logger('prefs');
Confirmed that this patch fixes the issue for me. Please let me know if you still want me to execute scanner manually.
Nick - that patch is reversal of a change we did to support non-latin characters in preferences (like player names etc.). It's not the solution we want, just a workaround for now.
change 17898 - this should solve your issue, without giving up non-latin characters in preferences. Please give it a try. Thanks!
Confirmed: the latest patch on top of 17866 and 17897 works for me (tm)
Thanks for the confirmation. But you shouldn't need any additional patch to the latest trunk version. Feel free to re-open if you still encounter this issue. Thanks.
change 17977 - adding a new class method to tag prefs which should not be utf8 encoded. Could you please verify this solution still works for you? It should basically do the same as the previous solution, but is much cleaner, prepared for other critical values, too. Thanks.
Works for me.
thanks!
Works here too. Tested with r17981: I'm too lazy to use svn snapshots, I'm using deb packages from http://debian.slimdevices.com There is a small glitch though which does not seem to be caused by this specific commit: when one watches "Scan Details" while scan is in progress file/dirs containing non-latin characters are not being displayed correctly ... Does not cause any trouble afterwards (Location is being displayed correctly in track details). Some builds affected, some not.
> Works here too. Great, thanks for the feedback! > There is a small glitch though which does not seem to be caused by this > specific commit: when one watches "Scan Details" while scan is in progress > file/dirs containing non-latin characters are not being displayed correctly ... That's bug 6689.
(In reply to comment #16) > Works here too. Tested with r17981: I'm too lazy to use svn snapshots, I'm > using deb packages from http://debian.slimdevices.com > > There is a small glitch though which does not seem to be caused by this > specific commit: when one watches "Scan Details" while scan is in progress > file/dirs containing non-latin characters are not being displayed correctly ... > Does not cause any trouble afterwards (Location is being displayed correctly in > track details). Some builds affected, some not. > Marking bug as closed. If you see the issue reappear, please reopen the bug
Reduce number of active targets for SC