epoch1970;374008 Wrote:
> Hi all,
> I was pleasantly suprised about this ticket being opened and fixed in
> my back :-)
> 'Bugzilla Bug 7995 Send WOL from Boom before alarm is due'
> (http://bugs.slimdevices.com/show_bug.cgi?id=7995).
> I can't really tell if it works on the Boom as advertised (I use RTC
> wake) but I am almost sure it doesn't work yet on SB3 (unless it's
> sophisticated and doesnt fire the WOL packets when the last known
> server is SN). I would be amazed to see the SB3 doing the trick too one
> of these days.
>
> Soon it's going to be very hard for a server to find an excuse being
> late to an alarm...
>
>
> In other news, for Gordon: I am wrapping-up my Xmas gifts; I did a last
> check on the strings.txt file for srvPowerControl, and I found 2 or 3
> instances of lines labeled like this:
> EN <text in english>
> EN <texte en français>
> instead of EN and FR, of course.
> If those errors are in the file I posted, please correct. Sorry for
> this.
> And, merry holidays, of course.
>
> Ah. Also, a reminder:
> http://forums.slimdevices.com/showthread.php?t=56877 => SBC applet
> communication to SC can be unsollicited. And its asynchronous as well.
I believe that the Boom is the only player that, at this time, will
fire off a WOL packet in advance of an alarm time. I'm hoping that
we'll next see this capability added to the SBC. The SB3 and
Transporter will lag in this capability since neither of them have a
hardware RTC. I think there are firmware enhancement requests filed
for the SB3 & Transporter to institute a "fake" RTC in firmware.
I'm looking closely at your getalarms_2.pl acript and I'm in the
process of adding rtc wakeup capability to the next version of
SrvrPowerCtrl. So far, getting the next alarm seems as simple as:
Code:
--------------------
sub GetNextAlarm {
my @clients;
my $curclient;
my @alarms;
my $curalarm;
my $nAlarmTime;
my $nNextAlarmTime;
$nNextAlarmTime = 0;
@clients = Slim::Player::Client::clients();
foreach $curclient (@clients) {
$curalarm = Slim::Utils::Alarm->getNextAlarm($curclient, 1);
if (defined($curalarm)) {
$nAlarmTime = $curalarm->findNextTime(time());
if ( (!$nNextAlarmTime) || ($nAlarmTime <
$nNextAlarmTime) ) {
$nNextAlarmTime = $nAlarmTime;
}
}
}
if (defined($nNextAlarmTime)) {
$g{log}->debug ( "The next alarm is: " . $nNextAlarmTime . " ==
" . Slim::Utils::DateTime::shortDateF($nNextAlarmTime) . " " .
Slim::Utils::DateTime::timeF($nNextAlarmTime) . "..\n");
return $nNextAlarmTime;
}
return -1;
}
--------------------
For this next version, I think I'll just ignore the whole DST change
problem. Really testing DST change conditions on both Linux & Windows
will take more time than I've got at the moment.
In fact, testing the rtc wakeup code on Windows will be what delays
this next SrvrPowerCtrl release anyway. My Windows development machine
is a cranky old box that requires an hour's worth of updating every time
I turn it on. So, I experience a disincentive every time I try to test
new windows features in the plugin.
Re EN mais en Français: yes, I saw those. But thanks for reminding me.
I have several new strings that will need translating. I you'd like to
take a crack at those when I post the next version, I'll be very
appreciative. And again, thank you for being patient with yours
truly, a confirmed francophobe.
--
gharris999
------------------------------------------------------------------------
gharris999's Profile: http://forums.slimdevices.com/member.php?userid=115
View this thread: http://forums.slimdevices.com/showthread.php?t=48521
_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/plugins
