Alarm fails only on Mondays.

[AKADAP]

Failed again today. I managed to wake up about 15 minutes before it was supposed to go off, and verified that the alarm icon was illuminated.
So, deleting & recreating the alarm did not fix the Monday failures.

[epoch1970]

This seems rather mysterious.
From the depths of the ServerPowerControl thread, I unearthed this message.

If you run the script attached to that message on a computer from Sunday night to Monday morning, you'll be able to spy on your player. You'll see alarms and statuses. Look at the message for an example of trace.
In the trace dates are printed in seconds; Days are numbered 0-6 as Sun-Sat. For example, alarm "33000@1,2,3,4,5" means alarm at 9h10, Mon-Fri.
Each line of the trace begins with a timestamp, an UTC date expressed in reference to the unix epoch. For example, "[1255271837]" means: Sun, 11 Oct 2009 14:37:17
http://www.epochconverter.com/ can do the math for you.

You can run this script from home, or from any other place connected to the internet. You need to set in clear text your login and password to mysb.com by editing the script. Also, using a lower frequency than the default 25 secs. for player lookup would probably be advisable.
The script needs some perl modules that may not be installed by default on every machine, but installing them shouldn't be too much of a problem. Just run the script and it will fail and complain if some modules are missing.

Before posting I checked and the code still works ok in 2012.

[AKADAP]

This seems rather mysterious.
From the depths of the ServerPowerControl thread, I unearthed this message.

If you run the script attached to that message on a computer from Sunday night to Monday morning, you'll be able to spy on your player. You'll see alarms and statuses. Look at the message for an example of trace.
In the trace dates are printed in seconds; Days are numbered 0-6 as Sun-Sat. For example, alarm "33000@1,2,3,4,5" means alarm at 9h10, Mon-Fri.
Each line of the trace begins with a timestamp, an UTC date expressed in reference to the unix epoch. For example, "[1255271837]" means: Sun, 11 Oct 2009 14:37:17
http://www.epochconverter.com/ can do the math for you.

You can run this script from home, or from any other place connected to the internet. You need to set in clear text your login and password to mysb.com by editing the script. Also, using a lower frequency than the default 25 secs. for player lookup would probably be advisable.
The script needs some perl modules that may not be installed by default on every machine, but installing them shouldn't be too much of a problem. Just run the script and it will fail and complain if some modules are missing.

Before posting I checked and the code still works ok in 2012.

running this script on Ubuntu 11.11 gets me:
$ ./mysbstatus_json.pl
Can't locate JSON/RPC/Client.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.12.4 /usr/local/share/perl/5.12.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.12 /usr/share/perl/5.12 /usr/local/lib/site_perl .) at ./mysbstatus_json.pl line 19.
BEGIN failed--compilation aborted at ./mysbstatus_json.pl line 19.

That does not give me much of a clue as to what package is missing.

[bpa]

running this script on Ubuntu 11.11 gets me:
$ ./mysbstatus_json.pl
Can't locate JSON/RPC/Client.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.12.4 /usr/local/share/perl/5.12.4 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.12 /usr/share/perl/5.12 /usr/local/lib/site_perl .) at ./mysbstatus_json.pl line 19.
BEGIN failed--compilation aborted at ./mysbstatus_json.pl line 19.

That does not give me much of a clue as to what package is missing.

It looks like you're missing the CPAN JSON::RPC::Client module.

Check the code to see what "use" modules are requested.

[epoch1970]

I think you need to invoke "apt-get libjson-rpc-perl libhttp-cookies-perl".
http://packages.ubuntu.com/oneiric/libjson-rpc-perl
http://packages.ubuntu.com/oneiric/libhttp-cookies-perl

use strict;
use HTTP::Cookies;
use JSON::RPC::Client;
use Data::Dumper; # use it when setting $run{debug} to 1.

[AKADAP]

I think you need to invoke "apt-get libjson-rpc-perl libhttp-cookies-perl".
http://packages.ubuntu.com/oneiric/libjson-rpc-perl
http://packages.ubuntu.com/oneiric/libhttp-cookies-perl

use strict;
use HTTP::Cookies;
use JSON::RPC::Client;
use Data::Dumper; # use it when setting $run{debug} to 1.

I installed libjson-rpc-pirl. libhttp-cookies-perl was already installed.
This seems to have worked.
Now I just have to remember to run this on Sunday night, and hope I can catch a failure.

[AKADAP]

Alarm failed with logger running, I'll see if I can attach the log file.
Does not seem that the log file shows any activity.

For reference, the alarm is set for 7:45 AM PDT, MTWTF

[epoch1970]

Does not seem that the log file shows any activity.

For reference, the alarm is set for 7:45 AM PDT, MTWTF

I understand PDT is GMT -7, 27900@1,2,3,4,5 is 7:45 Mon-Fri, so status should have changed between 1333957496 [Apr 09 2012 07:44:56 PDT] and 1333982721 [Apr 09 2012 07:45:21 PDT] (near the end of the file.)

If you look at the code, it tries to ride over "lost" players or connection glitches and changes "current status:" with "last known status:" when this happens. But it looks like the script never missed a beat, because that "last known status" trace can't be found in the log.
Connection was ok all the time between the place the script was running from, mysb.com, and the Boom. The only thing that I see in the log is that the script takes usually 11 secs to query and report status, and then sleeps for another 14 secs. But once mysb.com or the client running the script were slow enough to take up to 24 secs and the log says "sleeping 1 more seconds"; this happens near 7:47 PDT.

Not sure you need the webcam after all.
To prove the script works you could let it run tonight and show a change in the log file when the alarm starts as intended.

[AKADAP]

I understand PDT is GMT -7, 27900@1,2,3,4,5 is 7:45 Mon-Fri, so status should have changed between 1333957496 [Apr 09 2012 07:44:56 PDT] and 1333982721 [Apr 09 2012 07:45:21 PDT] (near the end of the file.)

If you look at the code, it tries to ride over "lost" players or connection glitches and changes "current status:" with "last known status:" when this happens. But it looks like the script never missed a beat, because that "last known status" trace can't be found in the log.
Connection was ok all the time between the place the script was running from, mysb.com, and the Boom. The only thing that I see in the log is that the script takes usually 11 secs to query and report status, and then sleeps for another 14 secs. But once mysb.com or the client running the script were slow enough to take up to 24 secs and the log says "sleeping 1 more seconds"; this happens near 7:47 PDT.

Not sure you need the webcam after all.
To prove the script works you could let it run tonight and show a change in the log file when the alarm starts as intended.

I tried to run it last night to have something to compare against, but it exited abnormally.

Alarm went off correctly, but this is what I found on my computer when I checked:

user@computer 22:06:08:~/programming
$ ./mysbstatus_json.pl >SqueezeBoxTuesday.log
Can't call method "is_error" on an undefined value at ./mysbstatus_json.pl line 179.
user@computer 03:48:47:~/programming
$

[epoch1970]

I tried to run it last night to have something to compare against, but it exited abnormally.

Alarm went off correctly, but this is what I found on my computer when I checked:

user@computer 22:06:08:~/programming
$ ./mysbstatus_json.pl >SqueezeBoxTuesday.log
Can't call method "is_error" on an undefined value at ./mysbstatus_json.pl line 179.
user@computer 03:48:47:~/programming
$

Ouch. I've modified the script a little bit to make it more robust, hopefully this new version will work better.
(In the old days when I used the CLI I would eval() everything; with JSON I thought this was not necessary anymore, but obviously I was wrong.)