I recently installed the SqueezeCenter 7.0 release version on Windows XP Pro SP2 using the installer EXE.  Then I ran the service enabler to install the Windows service.

Editing the service's ImagePath entry in the registry to add the startup options, this is what I now have (it's also necessary to specify the server's IP address, since there are other SlimServers and SqueezeCenters running on the same machine):

"C:\Program Files\SqueezeCenter\server\squeezecenter.exe" --prefsdir D:\slim\dot2\prefs --cachedir D:\slim\dot2\cache --logdir D:\slim\dot2\logs --playeraddr 192.168.9.2 --cliaddr 192.168.9.2 --streamaddr 192.168.9.2 --httpaddr 192.168.9.2

My experience is that of the three directory options --prefsdir, --cachedir, and --logdir, only --logdir is recognized.

Jim - could you please try again with some recent build? I did a few changes to silence warnings which could have fixed this as a side effect. 

Where will I find it?  Since this bug is targeted for 7.1, is the fix only in the 7.1 nightlies, or also in 7.0.1?  And will it be in the current 4/23 nightlies?  I can't use SVN since I need to test the Win EXE.

It would be in 7.0.1 (bug 5833)

Jim - any news?

Hi Michael, 

Ok  I have tried using the startup line:

"C:\Program Files\SqueezeCenter\server\squeezecenter.exe" ---prefsdir D:\Server Data\Squeeze\Center\prefs --cachedir D:\Server Data\SqueezeCenter\cache --logdir D:\Server Data\SqueezeCenter\logs" 

under the "imagepath" in the currentcontrol set for the squeezebox service on version "SqueezeCenter Version: 7.0.1 - 19522 @ Wed May 7 06:16:01 PDT 2008 - Windows Server 2003 - EN - cp1252" and I am sorry to say that it still does not appear to work. It appears that know of "relocations" work for me.  Also tried 7.1 from a couple of nights back and that also did not work.

Any ideas?

(In reply to comment #6)
> Any ideas?

Make sure you enclose any command line arguments containing spaces in double quotes.  I think I'd try:

"C:\Program Files\SqueezeCenter\server\squeezecenter.exe" ---prefsdir "D:\Server
Data\Squeeze\Center\prefs" --cachedir "D:\Server Data\SqueezeCenter\cache"
--logdir D:\Server Data\SqueezeCenter\logs" 

I purposely avoided spaces in the directory names for the relocated cache, prefs and log directories, as I've always had some problems with these command line arguments and sought to eliminate one possible hangup.

(In reply to comment #5)
> Jim - any news?

I just tried the May 7 nightly of 7.0.1, installed using the Window installer.  It looks like --logdir and --cachedir are now recognized, but still not --prefsdir.

Any way to get some debugging information for command line options?  What was read, what options were set, etc...  If when these things are parsed it's too early to write the info to the log (maybe the log file hasn't been initiated yet) then could the logging info be held in a string variable and then written out once the log is opened for writing?

> I just tried the May 7 nightly of 7.0.1, installed using the Window installer. 
> It looks like --logdir and --cachedir are now recognized, but still not
> --prefsdir.

Thanks for testing. I'll have to do some more analysis. Just hoped the issue had vanished by some other change.

Ok, I've run a few more tests. 

Contrary to what you said in comment #7 I think _all_ options but prefsdir are read correctly. This value is read in Slim::Utils::Prefs, _before_ the others are read. But it seems that if SC is run as a service, it has different entry points. And @ARGV isn't available yet under this condition.

I have contacted ActiveState support. We'll see what they have to say about this behaviour.

Thanks for looking at this issue still .... let me know when you need some more testing done.

(In reply to comment #10)
> Contrary to what you said in comment #7 I think _all_ options but prefsdir are
> read correctly.

I thought that was what I said in comment #8. :-)

Some more data, if it's worth anything: I'm seeing something again with SC 7.2, although I'm not running the EXE.  I've run SlimServer/SqueezeCenter in three different ways:

1. Running the Perl code as a Windows service using srvany.exe.
2. Running the Perl code from the command line console.
3. Running the bundled EXE as a Windows service.

And at any given time, any one of them may not work with respect to picking up all the command line options.  It may be only the prefsdir/file option, but I believe I've also had problems with the other directory options in the past.

SlimServer 6.5.x, which I still run using the method 1 above, fails to read the prefsfile option.  Both 7.0.x and 7.1 seem to be OK, but 7.2 also doesn't see the prefsdir option when run using method 1.

Ok, ActiveState confirm the issue. Will take a look at the workaround later this week:

------------------------------
 
It is correct that the stored commandline parameters are not set up until
the Startup() function is being called.  This is due to the fact that the
Service Control Manager is not passing in those arguments (He means that this
is a limitation of Service Control Manager -GS), and we have to
extract them ourselves, which is only done directly before we call the
Startup() callback.
 
I guess we could change PerlSvc so that @ARGV is set up earlier, but that
will need a new release.
 
A workaround for dealing with this right now would be to load the additional
modules from inside the Startup() callback using require():
 
sub Startup {
main::require_all();
main::initOptions();
main::init();
 
# here's where your startup code will go
while (ContinueRun() && !main::idle()) { }
 
main::stopServer();
}
 
sub Interactive {
main::require_all();
main::not_a_service();
}
 
package main;
 
my $prefs;
 
sub require_all {
    doALotOfInitialization();
    require Slim::Utils::Prefs;
    require Slim::Many::MoreModules;
    $prefs = Slim::Utils::Prefs::preferences();
}
 
 
sub init {}
 
sub initOptions {
Getopt::Long::GetOptions();
}
 
sub not_a_service {
# running interactively
}
 
------------------------------

I'm sorry, punting once again... this needs major changes in the main startup code.

Just one question:  Why does the behavior change?  Almost randomly with any given revision.  Sometimes is works, sometimes it doesn't.  Something is happening within SC, independant of limitations within ActivState's Perl.

The behaviour doesn't change, or didn't in a while. It depends on the Perl Development Kit and how it's handling parameters. While we've upgraded from PDK 7.0 (used up to SC7.0.1) to PDK 7.2 (SC7.1+) I didn't see a change in behaviour.

The SC EXE may be fairly consistent (I've seldom run the EXE) in never picking up the --prefsfile option.

The Perl code, when run as a service, is inconsistent.  My experience:

6.5 broken
7.0 ok
7.1 ok
7.2 broken

I realize that running the Perl code as a service may be unsupported.  But if the behavior is changing like this, it would seem to indicate something going on within SC.

My server is down right now.  When it's back up I'll double-check whether the list above is completely accurate.

> The Perl code, when run as a service, is inconsistent.  My experience:
> 
> 6.5 broken
> 7.0 ok
> 7.1 ok
> 7.2 broken

Jim - please get me some facts here. Just saying it's broken won't tell us in which way it is. I'd be surprised if 7.2 was, as there are basically no changes to the general code compared to 7.1.

I'm sorry, need to prioritize...

Waiting for new ActiveState PDK

New PDK has arrived. Let's give it another try.

Is this still an issue? Six months and no feedback have me doubt it.

(In reply to comment #22)
> Is this still an issue? Six months and no feedback have me doubt it.
> 

It's only an issue with the EXE, correct?  The Perl code via ActivePerl works fine.  I don't run the EXE except for occasional testing, but it only takes a few minutes to install it and see if it's still broken.  I'll do so tonight or tomorrow.

We'll have to test this whenever a new PDK is available.

FYI, with the 2009-04-11 r27509 build of 7.4, the --prefsdir option is still unrecognized when run as a Windows service.

Isn't someone working on changes to the startup code to permit running up without a database?  Maybe it would be a good opportunity to fix this bug.

Jim - now at PDK 8.0.1 are you still seeing this issue?

Version: 7.4.0 - r28607 @ Wed Sep 23 06:01:56 PDT 2009, still ignoring --prefsdir.

Update on latest release: Logitech Media Server Version: 7.7.0 - r33614 @ Tue Oct 18 11:17:52 PDT 2011. Still doesn't see --prefsdir option.

Try to work around PerlSvc issue causing @ARGV to be empty. Read the parameters from Windows' registry instead.