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...

[ncarver]

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...

It wouldn't matter whether I had put the squeezecenter directory from the tar file under /opt or /usr/local, Perl is going to look in its system directories by default (/usr/lib/perl5).

The bootstrap.pm file is informative, however it identifies exactly the problem that I am encountering, yet it claims that it fixes it (which it obviously doesn't completely):
# This causes a problem in that when we 'use' one of these modules,
# the CPAN/Foo.pm would be loaded, and then Dynaloader would be
# called, which loads the architecture specifc parts - But Dynaloader
# ignores @INC, and tries to pull from the system install of perl. If
# that module exists in the system perl, but the $VERSION's aren't the
# same, Dynaloader fails.
#
# The workaround is to munge @INC and eval'ing the known modules that
# we include with SqueezeCenter,....

I will look at this a bit more, but I am not willing to learn a great deal of Perl to fix this, so pretty soon I will get in touch with technical support. Thanks for the pointers! At least I know what is basically wrong and that the SC code is supposed to be able to deal with it.
Norm

[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??

[dsf]

I'm having a similar problem on my new machine. Rescanning worked fine when I added 12-15 albums or so, but last night I added 8GB of music and the scan was doing nothing this morning. I changed /var/lib/squeezecenter/prefs/log.conf so the scanner logs at DEBUG level, not just ERROR, and restarted the scan a few times. Each time it gets so far (but to a different point/file each time) and then just hangs Nothing in the logs saying anything's wrong. I have no symlinks, circular or otherwise, and all the mp3s are tagged etc. Any more suggestions gratefully received!