*** Bug 6649 has been marked as a duplicate of this bug. ***

Suggest that we turn on NTP 

I've been using my JHB more than the MQP Controller due to wireless signal strength issues. This is something I noticed on the JHB; I didn't think to check the MQP. Controller firmware release is r1977.

Over the last few days, the clock on the JHB Controller drifts out of sync from the SC7 host by at least 2 minutes per day. My JHB is generally left in the cradle, with analog clock as the saver, but also with Dim Screen When Charging enabled, so the JHB screen is usually dark. Over the last few days I've only used it a very few minutes each day. Changing players seems to resync the JHB clock with the SC7 host as described by Richard. I suspect that this is tied to the power saving updates, as I had not noticed this before those updates were incorporated. NTP sounds like a good idea, especially if you could use SqueezeNetwork servers for the NTP source so it would "just work" out of the box. Giving the users a choice of timeservers might be nice for privacy and for those without always-on broadband.

I've also observed this clock drift on my MQP Controller, firmware r1985.

r2022 -- still a problem. After less than three days, my almost-always-docked Controllers are 11 minutes (JHB) and 15 minutes (MQP) off from system time. I respectfully suggest that this bug should be re-targeted for 7.0 -- think how it will look to new customers for a $300 network-enabled device to keep worse time than the cheapest windup wristwatch.

Full NTP might be overkill. Perhaps Lua code could update the drift file for a regular NTP client? I'm not sure how a "client" NTPd setup on the Controller would affect the time seen when the device wakes up, but I'd think
 1) best option is that the device shows a fairly accurate time the moment it wakes up
 2) decent fallback might be having Jive keep track of the last time the time was synced and at startup (and periodically) connect to wifi and resync the clock with SC7, so at worst, at wake-up there'd be a few seconds of showing the wrong time

I think I agree with Peter. Removing target this bug for discussion at triage.

jive checkin r2083 (7.0 branch) syncs system time with hw clock every 10 minutes to correct for drift

confirmed with debug, these calls were immediately after each other:
Feb 29 13:48:26 (none) user.warn jive: (SqueezeboxJiveApplet.lua:128) - syncing system clock to hw clock: Fri Feb 29 13:48:26 2008
Feb 29 13:48:31 (none) user.warn jive: (SqueezeboxJiveApplet.lua:131) - system clock now synced to hw clock: Fri Feb 29 13:48:31 2008

leaving bug open, targetted for 7.0.1 to revisit, as this is a bit of a band-aid fix to the problem of the system clock not keeping good time.

just an FYI, tracking the 7.0 workaround over the course of a day, it appears the clock drift is not constant.

For my test, I had it running hwclock -s to sync to the hw clock every 36 mins (checkin has it going every 10 mins). In 6 clock resyncs, adjustments were 2, 5, 3, 4, 8, and 1 seconds.
 
# cat /mnt/mmc/log/messages | grep 'hw clock'

Feb 29 13:12:25 (none) user.warn jive: (SqueezeboxJiveApplet.lua:128) - syncing system clock to hw clock: Fri Feb 29 13:12:25 2008
Feb 29 13:12:27 (none) user.warn jive: (SqueezeboxJiveApplet.lua:131) - system clock now synced to hw clock: Fri Feb 29 13:12:27 2008

Feb 29 13:48:26 (none) user.warn jive: (SqueezeboxJiveApplet.lua:128) - syncing system clock to hw clock: Fri Feb 29 13:48:26 2008
Feb 29 13:48:31 (none) user.warn jive: (SqueezeboxJiveApplet.lua:131) - system clock now synced to hw clock: Fri Feb 29 13:48:31 2008

Feb 29 14:24:30 (none) user.warn jive: (SqueezeboxJiveApplet.lua:128) - syncing system clock to hw clock: Fri Feb 29 14:24:30 2008
Feb 29 14:24:33 (none) user.warn jive: (SqueezeboxJiveApplet.lua:131) - system clock now synced to hw clock: Fri Feb 29 14:24:33 2008

Feb 29 15:00:32 (none) user.warn jive: (SqueezeboxJiveApplet.lua:128) - syncing system clock to hw clock: Fri Feb 29 15:00:32 2008
Feb 29 15:00:36 (none) user.warn jive: (SqueezeboxJiveApplet.lua:131) - system clock now synced to hw clock: Fri Feb 29 15:00:36 2008

Feb 29 15:36:35 (none) user.warn jive: (SqueezeboxJiveApplet.lua:128) - syncing system clock to hw clock: Fri Feb 29 15:36:35 2008
Feb 29 15:36:43 (none) user.warn jive: (SqueezeboxJiveApplet.lua:131) - system clock now synced to hw clock: Fri Feb 29 15:36:43 2008

Feb 29 16:12:47 (none) user.warn jive: (SqueezeboxJiveApplet.lua:128) - syncing system clock to hw clock: Fri Feb 29 16:12:47 2008
Feb 29 16:12:48 (none) user.warn jive: (SqueezeboxJiveApplet.lua:131) - system clock now synced to hw clock: Fri Feb 29 16:12:48 2008

FYI- Clock is not off this morning after 18hrs with new code

See also bug 7464 for daylight savings.

removing priorities from all 7.0.1 target bugs for re-prioritizing

Created attachment 3241 [details]
non-working patch

This is the patch of what I was trying to do with setting up a clock sync with SC/SN every hour. It seems that the closure in Timer() can't use self?

I don't understand how I can accomplish sending a periodic command to the server if I can't pass anything into the function.

Richard, I'm going to assign this to you. Pass back to me after comment.

Created attachment 3252 [details]
Updated patch

Ben, my attached patch seems to work. Not much different from yours, other than to add a missing , and remove the warn debugs? Not sure why you were having problems.

when you say "seems to work", does that mean you confirmed the cli command is actually being issued and a return value is coming back from SC?

I'll give your patch a whirl, but while I could show that I was entering the callback function, I was unable to get a confirmation that the command was being issued and returned. In fact, it looked fairly evident that it wasn't being issued.

I got debug saying "setting clock to SC/SN time:" every 10 seconds.

huh...well, your patch works for me too. Bizarre I couldn't get the same behavior from mine. Maybe one of my log:warn() messages was causing something to balk.

I'm not going to worry about it, your patch works and I (mostly) wrote it so I understand it well enough. I'll push the update back to 1hr from 10secs and checkin shortly.

fixed in 7.0 trunk r2268

while connected to a player, sync time to SC/SN once per hour. If player changes, start a new timer for that player/server and cancel the existing timer sync.

Verified 7.0.1 - 19422 Controller r2409

While the Controller does not update the time "instantly" it will update if you switch Music Source or on the 1hour timer as indicated

This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1

Please try that version, if you still see the error, then reopen this bug.

To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html