Bugzilla – Bug 7610
Playlists with . seperating words have the . converted to a space
Last modified: 2011-03-16 04:34:07 UTC
I name my all encompassing playlist All.Jeff (see bug 4769 as to why the All. is added) and since upgrading to SqueezeCenter 7.0 and now 7.01 will take the "All.Jeff" that I enter and convert it to "All Jeff". While this is not a big problem it does concern me that the file is being renamed to something similar, but not exactly to what was entered. I save my playlist from the player UI. Version Info SqueezeCenter Version: 7.0.1 - 17963 - solaris - EN - utf8 Server IP address: 192.168.1.3 Perl Version: 5.8.8 i86pc-solaris MySQL Version: 5.0.51a
Jeff, I am unable to replicate this error using either .WPL or .M3U playlists. Can you please tell me which playlist format you are using Also, you can attach your scanner log
Created attachment 3135 [details] Scanner.log Ever since upgrading to SC 7.x I have had this issue. My original installation didn't work for reasons not directly related to SC, so I wiped out my Solaris installation and started over. I again fouled up my installation and couldn't resolve it so I'm back to a fresh Solaris installation. With the exception of the original installation the filename has always been renamed. I am saving it as an m3u (I didn't realize there was anything else) and am letting SC save it for me. In the attached scanner.log I had renamed a few files and did a wipe and rescan. All of the log settings are set to warn. Intrestingly, SC is expecting to find All.Jeff.m3u and complains that it's not found. SC seems to know the proper name, but why it's being saved as All Jeff.m3u is a mystery to me. For good measure I ran dtrace when saving the file and this is the output from dtrace (I ran a trace for files opened by process): 0 46923 open64:entry slimserver.pl /opt/squeezecenter/Playlists/All Jeff.m3u Clearly it's not being saved as I enter it.
The more I thought about all of the reinstallations of Solaris I have done I began to wonder if maybe there wasn't something up with the OS, so I grabbed a copy of SlimServer 6.5.4 and installed it, scanned my library, and saved a playlist called All.Jeff.m3u. I looked in the playlist folder for SlimServer (not shared with SqueezeCenter) and the playlist was saved as All.Jeff.m3u as expected. I did this on the same machine and only stopped SqueezeCenter long enough to do what I needed to do. The only caveat is that the source for all of the perl modules has changed, so I changed the build-perl-modules.pl to pull from http://svn.slimdevices.com/repos/slim/vendor/src/ which seems to have worked.
I can confirm this behavior on SC 7.0 running on Solaris Sparc: SqueezeCenter Version: 7.0 - 17793 - solaris - EN - iso-8859-1 Server IP address: 192.168.1.5 Perl Version: 5.8.8 sun4-solaris MySQL Version: 5.0.51a I received these warnings when saving the playlist from the Web UI: [08-03-27 12:37:58.2666] Slim::Utils::Misc::msg (1241) Warning: [12:37:58.2656] Use of uninitialized value in string eq at /export/home/slim/squeezecenter-7.0-17793-noCPAN/Slim/Player/Playlist.pm line 679. [08-03-27 12:37:59.1209] Slim::Utils::Misc::msg (1241) Warning: [12:37:59.1197] Argument "" isn't numeric in numeric gt (>) at /export/home/slim/squeezecenter-7.0-17793-noCPAN/HTML/Default/pageheader.html line 76. [08-03-27 12:38:39.2123] Slim::Utils::Misc::msg (1241) Warning: [12:38:39.2113] Argument "" isn't numeric in numeric gt (>) at /export/home/slim/squeezecenter-7.0-17793-noCPAN/HTML/Default/pageheader.html line 76.
Given the additional comment it appears this is an issue on Solaris, both Sparc and x86.
Confirmed on Ubuntu Gutsy i386 I tried enabling debugging on formats.playlists but didn't get anything in {server,scanner}.log. If you need more info please tell me which debug options needs enabling. SqueezeCenter version: 7.0.1 - 18234 - Debian - DA - utf8 IP adresse for server: 192.168.1.5 Perl version: 5.8.8 i486-linux-gnu-thread-multi MySQL version: 5.0.45-Debian_1ubuntu3.3 Platformarkitektur: i686-linux
Thanks everyone for the extra information, this helps.
This limitation has been added in change 8326 for renaming playlists - 21 months ago (Slim::Control::Commands::playlistsRenameCommand)! The command to save playlists has been changed more recently (change 12028). I'm not sure whether the filtering of dots only has been added later in this case. Can you rename in 6.5 using dots in the filename? The intention of this filtering is/was to not allow potentially critical characters in playlist names. Using the dot at the front of the name would eg. break scanning it on *X systems.
Up through 6.5.4 (official release) I was saving my playlist as All.Jeff with no issue. With the installation of 7.0 the name was then changed to use a space. Because it worked before it looked more bug than feature. I understand the logic behind the change and don't really have an issue with it, what doesn't sit well with me is that I got absolutely no notification that the filename was being altered to something similar because of the use of "special characters." While this seems like a trivial issue that will only affect a handful of people somebody else will eventually run across it. In this particular case, the "." is only detrimental if it's the first character in the playlist name. If there has already been code added to strip out the special characters from the playlist filename why not modify it to allow a "." except as the first character, and give a warning to the user if the playlist begins with one, suggesting a new name or having a new name entered. For that matter, give the user a warning whenever the playlist is saved do disk with a name different than what was entered.
> Up through 6.5.4 (official release) I was saving my playlist as All.Jeff with > no issue. Have you also been able to _rename_ them? > While this seems like a trivial issue that will only affect a handful of people > somebody else will eventually run across it. In this particular case, the "." > is only detrimental if it's the first character in the playlist name. If there I too wondered whether we wanted to only check for the . when it's the first character.
It sounds reasonable to only prohibit leading . characters and leave everything else as-is. Displaying an error message also seems appropriate.
change 18481
change 18482 - return message in the browser window if "illegal" characters are used
Verified fixed in 7.0.1 - 19597
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1 Please try that version, if you still see the error, then reopen this bug. To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html
Reduce number of active targets for SC