Bugzilla – Bug 9488
No playback of flac files with non standard characters in filename when bitrate limiting is on.
Last modified: 2009-07-31 10:29:51 UTC
I have confirmed this on my new boom: When bitrate limiting is on, playback of my flac files which contains non standard characters, eg. é - æ ø or å is not possible. The files are found and displayed correct by the sacnner, and also a browse music folder shows the correct names, both on the web ui and on the boom display. All files that do not contain non standard characters are played back correct. If bitrate limiting is turned off, playback of the files with non standard characters in the file names works fine. My server setup is like this : SqueezeCenter Version: 7.2.1 - 23169 @ Sun Sep 14 02:08:26 PDT 2008 - Debian - EN - utf8 Perl Version: 5.8.8 i486-linux-gnu-thread-multi MySQL Version: 5.0.51a-3ubuntu5.1 Platform Architecture: i686-linux Total Players Recognized: 1 I have also tested the official 7.2 release, but the behaviour is the same. Regards Bebop
QA to reproduce and get logs
I have not been able to reproduce. Bebop, could you set player.source to debug in Settings > Advanced > Logging and try playing one of the problem files again and then attach the resulting log to this bug as text? Thanks!
Hi Steven Strange you can not reproduce the error... I will do the player logging on Friday when I am back in my house. Regards Bebop
I have the same problem, and after investigation I have this information (sorry for my poor English) : My system is Debian with perl 5.8.8 and UTF-8 filesystem. The problem is only when a FLAC file is transcoded, beacause the filepath is not correctly encoded in UTF-8. Perl owrk correctly with file path, and in Slim::Player::TranscodingHelper, line 356, the file exist and is not encoded in UTF-8 at line 357. But when flac command is used, the encoded of filepath generated a File Not Found error for the program. My investigation going to Slim::Utils::Misc and method pathFromFileURL. In This method, URL from squezzecenter database is transformed in path, and URI package don't encode correctly the path. I don't have good solution at this time, but if the method Slim::Utils::Unicode::utf8decode_locale is used on filepath, the FLAC file is correctly played.
For information if I use method Encode::Detect::Detector::detect($filepath) before line 356 in Slim::Player::TranscodingHelper, the result is UTF-8. After using method Slim::Utils::Unicode::utf8decode_locale on this string, the result is already UTF-8, but the filepath work correctly with flac bin.
Created attachment 4014 [details] Serevr log This is my log file with player.source debug.
I have more information : If I use Encode::Detect::Detector::detect on filepath, the result is UTF-8 but if I use Encode::is_utf8 on filepath, the result is false! The problem is generated by URI package in pathFromFileURL method, when the path is extracted from URL, the UTF-8 encode doesn't work correctly. We can solve this problem with using of Slim::Utils::Unicode::utf8decode_locale method if Encode::Detect::Detector::detect and Encode::is_utf8 dont result same result. But the original error is not resolved... Is just a hack.
Thanks for your insight and the log file Yann.
Created attachment 4032 [details] SC 7.2.1 Log file Here is the log file with player.source debug turned on. This is with my Duet set to 320K bitrate limit, the file without non standard characters played fine, the ones containning "ø & Å" did not produce any sound at all, but the progress bar in the web interface was incrementing. Regards Bebop
Although the symptoms are different, I think that the following problem may have the same general cause (happens on 7.2.1, not checked previously): I have the music in folders, some with non ASCII utf-8 characters (Linux XUbuntu 8.04, french). When browsing by folder on the Duet controller, the name of the folders and files with non Ascii characters are scrambled. However they show correctly when browsing by music folder on the web interface (tested multiple browsers, all ok). When browsing by genre, album, artist,... the names show correctly.on the Duet controller. If this is not related to the present problem, I can fill a separate report
(In reply to comment #10) > Although the symptoms are different, I think that the following problem may > have the same general cause (happens on 7.2.1, not checked previously): > > I have the music in folders, some with non ASCII utf-8 characters (Linux > XUbuntu 8.04, french). When browsing by folder on the Duet controller, the name > of the folders and files with non Ascii characters are scrambled. However they > show correctly when browsing by music folder on the web interface (tested > multiple browsers, all ok). > > When browsing by genre, album, artist,... the names show correctly.on the Duet > controller. > > If this is not related to the present problem, I can fill a separate report > i've reported this for 7.3 (bug 9430) and it was fixed for 7.3 in change 23180. As far as i see this change was not back ported to 7.2 so you may open a new bug and ask for a fix for 7.2 transcoding in 7.3 has changed completely and i can confirm, that i don't have the issue described in this case.
Could you please do a test: edit /usr/share/perl5/Slim/Player/TranscodingHelper.pm and comment out the following condition (around line 370): # if ( Slim::Utils::OSDetect::OS() eq 'mac' || !-e $filepath ) { $filepath = Slim::Utils::Unicode::utf8decode_locale($filepath); # } As you can see from the comments in that file this condition has been added/edited several times already. We're facing an issue which seems to be different depending even on what Ubuntu release you're running. This worked fine for me in 7.04. I then run an update to 8.04 (same machine) and it was broken.
> # if ( Slim::Utils::OSDetect::OS() eq 'mac' || !-e $filepath ) { > $filepath = Slim::Utils::Unicode::utf8decode_locale($filepath); > # } I resovle my probleme with this solution, but the source is utf encoding.
(In reply to comment #12) > Could you please do a test: edit > /usr/share/perl5/Slim/Player/TranscodingHelper.pm and comment out the following > condition (around line 370): > # if ( Slim::Utils::OSDetect::OS() eq 'mac' || !-e $filepath ) { > $filepath = Slim::Utils::Unicode::utf8decode_locale($filepath); > # } > As you can see from the comments in that file this condition has been > added/edited several times already. We're facing an issue which seems to be > different depending even on what Ubuntu release you're running. This worked > fine for me in 7.04. I then run an update to 8.04 (same machine) and it was > broken. Works for me after comment out the above line.
change 23382 - enable encoding for Debian/Ubuntu. Please test.
0(In reply to comment #15) > change 23382 - enable encoding for Debian/Ubuntu. Please test. I managed to update my 7.2 to the latest 7.3 as Markus Schiegl suggested before I saw this, since that had solved his problem, and besides the transcoding problems, I also saw the problem with filenames when browsing the musicfolder on my duet. The 7.3 update cured both problems, I can now transcode and play files with non standard characters, and they are shown correct in the browse music folder on the Duet. Regards Bebop
(In reply to comment #15) > change 23382 - enable encoding for Debian/Ubuntu. Please test. Works fine. Thanks. Kind Regards /Bernt
Great, thanks for the feedback!
Verified with SqueezeCenter Version: 7.2.1 - 23565
This bug has been fixed in the 7.3.0 release version of SqueezeCenter! Please download the new version from http://www.slimdevices.com/su_downloads.html if you haven't already. If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.
Reduce number of active targets for SC