Fetching 7.8 from Git and running on an SSD

[Philip Meyer]

You probably can get the 64 bit version to run on Windows, but you will need to compile a lot of the binaries yourself. Do yourself a favour and run perl 32 bit. It will run out of the box (it's how we are developing on Windows)

Okay, I didn't realise there would be a problem - I just instinctively download 64 bit installers whenever I see the option these days!

I just need to figure out which plugin is using Zip, and figure out what that problem is, because it wouldn't run even with Perl x32.

[Philip Meyer]

This is a bug, I think. Modify line 16 in CPAN\Compress\Raw\Zlib.pm. Change it to:

$VERSION = '2.037';

Then you'll be able to install plugins using the extension downloader. I have no idea why this only crops up with the git code on windows.

I'll have a go at this later... thanks!

[gharris999]

This is a bug, I think. Modify line 16 in CPAN\Compress\Raw\Zlib.pm. Change it to:

$VERSION = '2.037';

Then you'll be able to install plugins using the extension downloader. I have no idea why this only crops up with the git code on windows.

OK, I don't think this is a bug, per se. It appears that the windows ActiveState perl 5.14.2 installer also installs a newer version of Compress-Raw-Zlib (2.037) by default. So when LMS bootstraps it's own 2.033 Zlib.pm, perl sees a version conflict.

My understanding of perl is still vague enough that I don't really understand why this should be...why LMS's Zlib isn't loaded in preference to the system installed one.

From the documentation on DynaLoader:

All arguments to bootstrap() are passed to the module's bootstrap function. The default code generated by xsubpp expects $module [, $version] If the optional $version argument is not given, it defaults to $XS_VERSION // $VERSION in the module's symbol table. The default code compares the Perl-space version with the version of the compiled XS code, and croaks with an error if they do not match.

If I understand that right, what a @#$% PITA. How the hell does one support different versions of perl with this code?? Who knew that perl had its very own version of "dll hell".

Anyway, as far as I know, just updating the $VERSION string as above is harmless and gets things working.

[Philip Meyer]

>Anyway, as far as I know, just updating the $VERSION string as above is
>harmless and gets things working.
>
I applied this frig, and it does seem to be working okay.

I installed Perl 5.14.2 x32, so if I were to install Perl 5.14.1 instead, I wouldn't have had this problem?

Phil

[gharris999]

>Anyway, as far as I know, just updating the $VERSION string as above is
>harmless and gets things working.
>
I applied this frig, and it does seem to be working okay.

I installed Perl 5.14.2 x32, so if I were to install Perl 5.14.1 instead, I wouldn't have had this problem?

Phil

I don't think we can know that without knowing what version of Zlib is bundled with ActiveState 5.14.1.

[mherger]

> No, that's exactly what I'm talking about - simultaneous instances. I've
> run as many as 10 or 12 instances on my server simultaneously with the
> SVN checkouts.

BTW: why would you want to run that many instances?

--

Michael

[erland]

> No, that's exactly what I'm talking about - simultaneous instances. I've
> run as many as 10 or 12 instances on my server simultaneously with the
> SVN checkouts.

BTW: why would you want to run that many instances?

Not sure why he does it but I can think of a number of reasons:
1. To get support for multiple libraries (without using Multi Library plugin), for example one fore each family member or house area or type of music (classical vs pop/rock). Sometimes you even want different configuration to be used depending on the user or type of music the server provides.
2. To make it easy to help users with problems:
- by always having an instance running with the same version and similar configuration which they are using
- by having different library sizes making it easy to test how it works in a certain library size
- by having different configuration settings making it possible to verify how the system works in a certain setting
3. By helping Logitech with testing by being able to easily test and compare behavior of the latest version of all active branches. (when MySQL->SQLite, onebrowser and SBS->LMS was all done in parallel I can imagine that this point can easily use up a few instances by itself)
4. To make it easy to switch to a working configuration if something is committed to trunk temporarily breaks the latest nightly
5. To make it easy to do testing of own scripts/plugins towards multiple server versions if you want to support multiple server versions and not just the latest major release

Personally, I've only 4 instances running simultaneously
- One which is used for production usage (my own music listening).
- One on a SheevaPlug which is sometimes used to test on slow hardware.
- One on a VortexBox installation on a laptop which is used for ripping and to verify that the music looks ok before I scan it into my production setup.
- One which is used for development, this instance can easily be switched between different versions and configurations but I only run one at a specific time.
(I would probably be able to merge the production setup with the VortexBox, but sometimes it's flexible to have them separate)

And of course, in my case I actually run each server on separate hardware/virtual machines and I'm mainly needing them for development/test purposes, but they do run simultaneously.
The main reason for a "normal" end user to run multiple servers would probably be to get support for multiple libraries to avoid putting the music from the whole family into one single library.

[gharris999]

Not sure why he does it but I can think of a number of reasons:
1. To get support for multiple libraries (without using Multi Library plugin), for example one fore each family member or house area or type of music (classical vs pop/rock). Sometimes you even want different configuration to be used depending on the user or type of music the server provides.
2. To make it easy to help users with problems:
- by always having an instance running with the same version and similar configuration which they are using
- by having different library sizes making it easy to test how it works in a certain library size
- by having different configuration settings making it possible to verify how the system works in a certain setting
3. By helping Logitech with testing by being able to easily test and compare behavior of the latest version of all active branches. (when MySQL->SQLite, onebrowser and SBS->LMS was all done in parallel I can imagine that this point can easily use up a few instances by itself)
4. To make it easy to switch to a working configuration if something is committed to trunk temporarily breaks the latest nightly
5. To make it easy to do testing of own scripts/plugins towards multiple server versions if you want to support multiple server versions and not just the latest major release

Personally, I've only 4 instances running simultaneously
- One which is used for production usage (my own music listening).
- One on a SheevaPlug which is sometimes used to test on slow hardware.
- One on a VortexBox installation on a laptop which is used for ripping and to verify that the music looks ok before I scan it into my production setup.
- One which is used for development, this instance can easily be switched between different versions and configurations but I only run one at a specific time.
(I would probably be able to merge the production setup with the VortexBox, but sometimes it's flexible to have them separate)

And of course, in my case I actually run each server on separate hardware/virtual machines and I'm mainly needing them for development/test purposes, but they do run simultaneously.
The main reason for a "normal" end user to run multiple servers would probably be to get support for multiple libraries to avoid putting the music from the whole family into one single library.

Humm...so, Mormon family, then?

[JJZolx]

Not sure why he does it but I can think of a number of reasons:

...

What he said. I normally just run one each of 7.5, 7.6, 7.7 and 7.8. For the Squeezeboxes that I use around the house I go back and forth between using 7.8 and 7.5 for long periods of time. The newer versions are faster and the different user interfaces are consistent, but 7.5 doesn't have all of the browsing bugs that were introduced with onebrowser and never addressed.

Any chance that SVN repositories can be kept up to date for branches still in development?