Rescan Music Library does nothing in SqueezeCenter

[ncarver]

Had SlimServer running fine but had to change to SqueezeCenter for new Duet. Was unable to get RPM version to start, but was able to get tar version going. SC seemed to find library created by SlimServer, and interacts with Duet just fine. However, if I attempt to click on Rescan to rescan my collection, scanning does not take place (there is no disc activity and albums are not updated). Only thing that does change is that line below that normally says "View Previous Scan Details" changes to "Scanning - View Progress" but it never changes back.

I notice the follow messages in the Logs/server.log file resulting from starting SC:
[08-03-11 13:26:28.5498] Slim::Utils::Misc::msg (1241) Warning: [13:26:28.5493] Attempt to free unreferenced scalar: SV 0xaf72ab4 at ./slimserver.pl line 1.
[08-03-11 13:27:03.2090] Slim::bootstrap::tryModuleLoad (266) Warning: Module [Template::Stash::XS] failed to load:
Couldn't load Template::Stash::XS 2.15:
Template::Stash::XS object version 2.19 does not match bootstrap parameter 2.15 at /usr/lib/perl5/5.8.8/i386-linux/DynaLoader.pm line 253.
BEGIN failed--compilation aborted at /opt/squeezecenter/CPAN/Template/Stash/XS.pm line 27.
Compilation failed in require at (eval 529) line 2.
BEGIN failed--compilation aborted at (eval 529) line 2.
[08-03-11 13:27:13.2004] Slim::Networking::Select::select (245) Error: Select task failed: Can't call method "process" on an undefined value at /opt/squeezecenter/Slim/Web/HTTP.pm line 2332.

However, nothing is written to that log file or to Logs/scanner.log when I invoke the Rescan function.

I also tried directly invoking the scanner.pl code to see what happened and got this:
The following CPAN modules were found but cannot work with SqueezeCenter:
Compress::Zlib (loaded 1.41 but missing object file, need 1.41)
x this problem you have several options:
1. Install the latest version of the module(s) using CPAN: sudo cpan Some::Module
2. Update the module's package using apt-get, yum, etc.
3. Run the .tar.gz version of SqueezeCenter which includes all required CPAN modules.

Of course I am running the .tar.gz version, and my Linux has like version 2.0 of Compress::Zlib installed, so little help.


I am running Mandriva 2008.0, and would appreciate suggestions for diagnosing and fixing this issue.

Thanks, Norm

[mlsstl]

I had scanning problems with SC7 on my Linux box. You might check my thread below.

It ended up being a circular soft-link. Once it was removed everything ran fine. It did take me a number of hours to find the subdirectory which contained the bad link.

The mystery is why this bad soft-link caused Squeezecenter to fail but it never bothered Slimserver in the least. Never got an explanation for that but the tech support people did indicate they would alert the appropriate people on the design team.

[ncarver]

I had scanning problems with SC7 on my Linux box. You might check my thread below.

It ended up being a circular soft-link. Once it was removed everything ran fine. It did take me a number of hours to find the subdirectory which contained the bad link.

The mystery is why this bad soft-link caused Squeezecenter to fail but it never bothered Slimserver in the least. Never got an explanation for that but the tech support people did indicate they would alert the appropriate people on the design team.

Thanks, I already looked at your thread, but no symbolic links in any of the flac file directories.

I did find one interesting piece of information: if in SC you go to the Music Library view, you can see the unscanned artist directories, and if you click on one and then click on (open) each album directory, they get added as if they were scanned.
So this is not an issue that prevents new music from being added to the DB.

[snarlydwarf]

I did find one interesting piece of information: if in SC you go to the Music Library view, you can see the unscanned artist directories, and if you click on one and then click on (open) each album directory, they get added as if they were scanned.
So this is not an issue that prevents new music from being added to the DB.

Right, it is a failure of the scanner to compile correctly:

Template::Stash::XS object version 2.19 does not match bootstrap parameter 2.15 at /usr/lib/perl5/5.8.8/i386-linux/DynaLoader.pm line 253.
BEGIN failed--compilation aborted at /opt/squeezecenter/CPAN/Template/Stash/XS.pm line 27.

It looks like you have Template::Stash::XS in /opt/squeezecenter as well as somewhere else? Or the .so is for 2.19 is somehow being found when you have 2.15 in /opt/squeezecenter.

What does 'locate XS.so' say?

[ncarver]

Right, it is a failure of the scanner to compile correctly:

It looks like you have Template::Stash::XS in /opt/squeezecenter as well as somewhere else? Or the .so is for 2.19 is somehow being found when you have 2.15 in /opt/squeezecenter.

What does 'locate XS.so' say?

Thanks for the help!

Of course there will be other versions of some modules on the machine. Running "locate XS.so" gives:
/opt/squeezecenter/CPAN/arch/5.8/i386-linux-thread-multi/auto/JSON/XS/XS.so
/opt/squeezecenter/CPAN/arch/5.8/i386-linux-thread-multi/auto/Template/Stash/XS/XS.so
/opt/squeezecenter/CPAN/arch/5.8/x86_64-linux-thread-multi/auto/JSON/XS/XS.so
/opt/squeezecenter/CPAN/arch/5.8/x86_64-linux-thread-multi/auto/Template/Stash/XS/XS.so
/opt/squeezecenter/CPAN/arch/5.8.8/i386-linux/auto/JSON/XS/XS.so
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux/auto/Template/Stash/XS/XS.so

The /usr/lib/... system version is 2.19.

How does one get Perl to search in /opt/squeezecenter first? I am rather surprised this isn't set up already given that the tar version is supposed to have all the needed modules.

I will do some googling, but would appreciate additional help. Perl is not one of the languages I am familiar with.
Norm

[snarlydwarf]

How does one get Perl to search in /opt/squeezecenter first? I am rather surprised this isn't set up already given that the tar version is supposed to have all the needed modules.

Thats tricky, and why I think /opt is silly (it gets unruly very quickly when you have tons of junk in /opt and need to add /opt/foo/bin:/opt/bar/bin:/opt/foo/sbin:/opt/bar/sbin type junk to $PATH, and similar junk to ldconfig and tons of other stuff. I'm a usr/local guy.

What perl thinks is its path:
perl -e 'print join ":", @INC'

Look at wherever your bootstrap.pm file ended up in the /opt system.. that's where the paths are further mangled to handle plugins and such, and where you'll need to insert your own changes so it looks in /opt/squeezecenter/share/perl5 or whatever it is...

[mherger]

> Right, it is a failure of the scanner to compile correctly:
> Code:
> --------------------
> Template::Stash::XS object version 2.19 does not match bootstrap

Template::Stash::XS is an optional module. SC will work without, though a
bit slower.

Michael

[ncarver]

> Right, it is a failure of the scanner to compile correctly:
> Code:
> --------------------
> Template::Stash::XS object version 2.19 does not match bootstrap

Template::Stash::XS is an optional module. SC will work without, though a
bit slower.

So is this not the cause of scanning not working then??