Bugzilla – Bug 5884
Running scanner.pl produces different results than scanner.exe
Last modified: 2011-11-06 23:23:20 UTC
Install the latest ActiveState Perl on a Windows box. Try to run scanner.pl manually and look at any cue/bin file that has a single quote / apostrophe in the album or artist's name. Notice that the "Now playing" display gets messed up on both the Transporter/SB3 as well as the web browser window. I've traced this down to the fact that when I run scanner.pl manually, C:\Program Files\SqueezeCenter\server\CPAN\URI.pm is being loaded instead of C:\Perl\Lib\URI.pm. Normally, this would seem correct, except for: The character set "$mark" in SC's URI.pm doesn't include a single quote, whereas ActiveState's URI.pm does. Simply renaming SC's URI.pm seems to workaround the problem. I think this all has something to do with perlapp picking up different versions of the libraries than bootstrap.pm does at run time. It does make me wonder what other problems I could be having by running scanner.pl manually (or if the linux users have the same issue). NOTE: The ability to run scanner.pl manually is very helpful in that it allows me to easily debug and fix problems directly on a windows distribution of SqueezeCenter. I care about this because I use this technique to implement a workaround for bug #4276.
Dean states it should be loading our URI.pm, of course. It looks like 135 is the latest, and it hasn't changed in a long time. Andy states $mark should not include a single-quote. What specific differences are you seeing in the scanner behavior between the two? Thanks!
Hmm... Dan indeed changed this a while back: http://svn.slimdevices.com/trunk/server/CPAN/URI.pm?rev=2793&r1=1514&r2=2793
Regarding your question in comment #1: I see no differences while running the scanner, only afterwards when playing my library. Any cue/flac file pair with a single quote in the album/artist's name (e.g. "Live at Joe's blues shack") will cause problems in the "now playing" display when you play those tracks.
The real problem here is that the wrong URI.pm is being used when running the .pl file and some Bootstrap.pm bug is probably the issue. We'll need to look at this post-7.0, but in the mean time output from --d_startup would be helpful here.
(In reply to comment #4) > The real problem here is that the wrong URI.pm is being used when running the > .pl file and some Bootstrap.pm bug is probably the issue. If I'm reading the orginal report correctly, it sounds like the opposite is true. The .exe is loading the wrong module. However, SC's URI.pm module has a bug and causes errors when running the .pl. I've seen and reported a number of bugs and unexpected behaviors running the .pl code vs the .exe. This may explain some of it. It's also potentially a major problem if the .exe, which most Windows users run, isn't loading some of the SC supplied modules.
Unassigned bugs cannot have a priority.