gharris999;414803 Wrote: 
> take a look at the contents of /var/log/squeezecenter/srvrpowerctrl.log.

My alarms are set for 9:00 Mon-Fri and 10:00 on Saturday. This is not
to get me up ;-) but for a particular radio program in the morning,
hence why I don't want the backup alarm beep. Here's a snip from
/var/log/squeezecenter/srvrpowerctrl.log from before and after the
change from GMT to BST, and also interestingly from before and after a
system upgrade that changed my kernel to one that uses the new method
for setting the RTC; both methods work BTW.

Code:
--------------------
    
  Wed Mar 25 12:40:34 GMT 2009: /usr/bin/scwakeup.sh 1238057880
  Setting /proc/acpi/alarm to 2009-03-26 08:58:00
  Thu Mar 26 10:13:30 GMT 2009: /usr/bin/scwakeup.sh 1238144280
  Setting /proc/acpi/alarm to 2009-03-27 08:58:00
  Thu Mar 26 18:28:36 GMT 2009: /usr/bin/scwakeup.sh 1238144280
  Setting /proc/acpi/alarm to 2009-03-27 08:58:00
  Fri Mar 27 11:02:30 GMT 2009: /usr/bin/scwakeup.sh 1238234280
  Setting /proc/acpi/alarm to 2009-03-28 09:58:00
  Sat Mar 28 14:41:09 GMT 2009: /usr/bin/scwakeup.sh 1238399880
  Setting /proc/acpi/alarm to 2009-03-30 07:58:00
  Sun Mar 29 10:59:45 BST 2009: /usr/bin/scwakeup.sh 1238399880
  Setting /proc/acpi/alarm to 2009-03-30 07:58:00
  Sun Mar 29 11:58:38 BST 2009: /usr/bin/scwakeup.sh 1238399880
  Setting /proc/acpi/alarm to 2009-03-30 07:58:00
  Sun Mar 29 17:12:00 BST 2009: /usr/bin/scwakeup.sh 1238399880
  Setting /proc/acpi/alarm to 2009-03-30 07:58:00
  Sun Mar 29 18:47:21 BST 2009: /usr/bin/scwakeup.sh 1238399880
  Setting /proc/acpi/alarm to 2009-03-30 07:58:00
  Mon Mar 30 15:03:33 BST 2009: /usr/bin/scwakeup.sh 1238486280
  Setting /sys/class/rtc/rtc0/wakealarm to 1238486280
  Mon Mar 30 16:24:49 BST 2009: /usr/bin/scwakeup.sh 1238486280
  Setting /sys/class/rtc/rtc0/wakealarm to 1238486280
  
--------------------


I was going to suggest that if both the RTC and local time can be read,
then the plugin really should know exactly what offset to use when
setting the RTC wake-up event. Looking at the output from the following
command, It's even stated in plain english ("Assuming hardware clock is
kept in local time." or "Assuming hardware clock is kept in UTC
time.").

Code:
--------------------
    $ sudo hwclock --debug
  hwclock from util-linux-ng 2.14.2
  Using /dev interface to clock.
  Assuming hardware clock is kept in local time.
  Waiting for clock tick...
  ...got clock tick
  Time read from Hardware Clock: 2009/04/12 10:29:11
  Hw clock time : 2009/04/12 10:29:11 = 1239528551 seconds since 1969
  Sun 12 Apr 2009 10:29:11 BST  -0.562264 seconds
  
--------------------


Since I suspect I'm not the only one who's BIOS clock is changed by the
OS (I'm pretty sure that Windows does this by default, in fact I think
that maybe why I may have selected that the harware clock is in local
time, since on dual boot machines in the past I had problems with the
time being out by one hour in Ubuntu) it would make sense to apply a
fix for this before the realese of the plugin.

For now as a workaround I've increased my idle time-out to 65 mins. I
may modify my /etc/default/rcS to set UTC=yes, but I haven't had
problems anywhere else with its current setting of UTC=no.


-- 
rickwookie
------------------------------------------------------------------------
rickwookie's Profile: http://forums.slimdevices.com/member.php?userid=6397
View this thread: http://forums.slimdevices.com/showthread.php?t=62339

_______________________________________________
plugins mailing list
[email protected]
http://lists.slimdevices.com/mailman/listinfo/plugins

Reply via email to