Bugzilla – Bug 12253
Auto-detect timezone, provide timezone in Settings, use NTP
Last modified: 2009-10-05 14:35:30 UTC
r5995 is really bad about this, but I have observed it was as early as r4875. Typically after a firmware upgrade, right after boot the date/clock will be reset to 12:00 AM and 1/1/1970 (unix 0 time)
This also happens after a 'system crash' event now
Mine has been stuck in the 70's for weeks (although it did spend a while in the 80s, somehow). Is there any additional information that is needed that would help diag. this issue? Windows XP MCE sp3. Latest SC 7.4 nightlies and Touch firmware (several different versions) installed over time without having any effect. Wired connection. Factory reset has no effect, regular reset has no effect, power plug pull has no effect, switching to SN and playing a radio stream and then back did not have an effect (with either connection). All other SB3s, booms, controller display the correct time.
This partially happens because we don't detect or set time zones.
Here's my current thoughts for timezone: On SP startup, after network is available, check if /etc/localtime points to the default "Factory" file. If so, fetch http://<sn>/public/tz which will return a text string of a guess at the user's timezone. Check that /usr/share/zoneinfo/<string> exists and symlink it. Sync the time. There are a couple ways to do this: using rdate or SNTP. We should run time servers on SN rather than hitting other public time servers. Also need to think about how to sync the time on an ongoing basis. Would prefer to avoid using the SC/SN 'date' command as it doesn't take /etc/localtime into account and returns time using the timezone configured on the remote system. We also need to build a Settings -> Timezone UI with the same set of timezones in the current SN list.
I tried out msntp. It seems to work fine and I think that it is small enough. I could add this to the build. We would also need to deal with two other issues: 1. What to do when we have a local SC and no Internet connection - just use SC time 2. What to do when we have a local SC and an Internet connection - we need to avoid a conflict between getting the time (hourly?, how?) from the local, possibly-not-time-synchronized, SC and getting it from the NTP servers.
*** Bug 10843 has been marked as a duplicate of this bug. ***
I think accurate time is important for Baby, don't you?
Brandon, since other people are busy, we decided to see if you could work on this?
I've added public NTP service on SN now via time.(sv|dc|de).squeezenetwork.com. Andy's plan sounds great, re: adding an initial timezone lookup service via an SN URL, and then letting the user mod it from there if its wrong. Combining that with msntp should work great in the world where we can assume an internet connection. I think even if SC is available, we should pretty much ignore it if NTP-via-SN is also available, which should be the norm. It doesn't seem like there's any sane answer for the SC-only case (behind a restrictive firewall or on an isolated network) using the existing date command that doesn't run into complications. Would it be acceptable to add a new type of date command that returns UTC time + local timezone spec? Is that even possible reliably on platforms like Windows?
Another option for local SC is we could bundle an ntpd implementation with SC and run it if we detect nothing running on port 123. The bundled ntpd would be configured just to serve the local clock as if it were the only reference. Then we can just dynamically add any available local SC's to the list of msntp servers along with the SN ones and let msntp sort it out from there. This again assumes that bundling ntpd on windows is reasonable, and that it can figure out what UTC time is there, and it also means if the player has never had a connection to the outside world (to source initial TZ guess from SN), that the user will have to manually set the TZ to see the right time.
OpenBSD has a lightweight ntpd implementation that daemonizes and polls multiple servers, etc. It looks like a better and more robust fit than msntp for the client side. Strips to 35KB w/ no shlib deps on x86, so it should be plenty tiny, and it's BSD-licensed, so I'm looking at going that route on the player for an NTP implementation. Another option for dealing with the isolated network SC-only thing is just to make it a manual option under Advanced. Basically in that scenario we would look for an NTP server list from DHCP (or manual network config?), and if no override we use the SN NTP server list. We handle timezone via the initial SN-based guess + the ability to manually change it in the config options. Then we have an advanced config option to use local SC time only. If this option is checked, we never start the ntp daemon, and SP periodically polls the date command on the connected SC server and resets local time to that, and just flatly assumes the user has manually configured the same timezone on both. Anyone have a problem with that scenario? It's less complicated (in terms of detecting and handling all of the possible scenarios wrt to network/SN/SC availability and firewalls and intermittent packet loss) than the other options to implement, and it only puts a burden on those who have no (unfirewalled) internet access combined with no local NTP service being served by DHCP.
This needs to work without adding any user options. One possible problem with always using SN time, as the alarm clock. If the player is connected to SC, and the SC time is slightly wrong then it would appear that the alarm clock does not work correctly. I still think it would be best to sync the time to the current server, not always SN. Does Perl have a ntp server that could be included with SC, maybe running on a different port? If we could modify it to run on port 3483 that would be the least problem for support as we already own that port.
(In reply to comment #12) > This needs to work without adding any user options. Does this include the user option to set the timezone? I don't see how we can do anything sane and reliable without that - SN's guesses won't be perfect, and the player could later move timezones anyways, which would then require a fac reset just to change TZ. > One possible problem with always using SN time, as the alarm clock. If the > player is connected to SC, and the SC time is slightly wrong then it would > appear that the alarm clock does not work correctly. I still think it would be > best to sync the time to the current server, not always SN. Because the alarm is actually triggered from SC when SC is connected? I assume the alarm is based on the local time when disconnected - why isn't it just doing that always? In any case it wouldn't just appear to be incorrect, it would actually be incorrect, and the fix would be for them to set the time correctly on their SC box. > Does Perl have a ntp server that could be included with SC, maybe running on a > different port? If we could modify it to run on port 3483 that would be the > least problem for support as we already own that port. I don't know of (and can't seem to Google) any NTP server implementations in Perl. I could probably write a very imprecise one pretty quickly though just to make this work. Using an alternate port isn't too hard to do regardless of which option we choose.
Getting from only (or primarily) one foreign source (SN) sounds problematic and potentially unreliable. I'd vote for getting it from the current server SC or SN. It is the user's responsibility to make sure that the SC time is correct (or off by the desired amount - I know lots of people that like their alarm clock 5 minutes fast for some reason). A user must be able to set the timezone and I'd also think it would be a good idea to let them actually set the time manually, as well (for the above mentioned people).
(In reply to comment #14) > Getting from only (or primarily) one foreign source (SN) sounds problematic and > potentially unreliable. Keep in mind that "one source" (SN) is actually 3 time server addresses (one located on each coast of the US and one in Germany), each of which is a virtual address that fails over between two pieces of hardware locally. They're part of a 10-machine global NTP peering network, all of which upstream to random members of the public pool.ntp.org locally for reference clock access. The 3 locations are all in extremely well built datacenters that virtually never see facilities failures, and the backbone uplinks at all 3 locations are some of the most reliable that money can reasonably buy. Your player getting struck by an asteroid is probably more likely than a failure to get a valid time synch from SN, assuming you have internet access at all. > I'd vote for getting it from the current server SC or > SN. That's pretty much how it will have to be, I think, given the alarm time issue. The problem is that SC's date command doesn't give us TZ info to work from. We need SC to source to us the date in UTC (unix time) rather than SC's unknown local TZ. We can do that over either NTP or some other facility, it doesn't really matter. There will be a step adjustment of the local time on server switch (between different SCs and/or SN), but there's no avoiding that if we want to be in sync with whatever server is chosen. > It is the user's responsibility to make sure that the SC time is correct > (or off by the desired amount - I know lots of people that like their alarm > clock 5 minutes fast for some reason). Agreed, although I don't like it :) > A user must be able to set the timezone Yes, which is going to require a new config setting at this time. > and I'd also think it would be a good idea to let them actually set the time > manually, as well (for the above mentioned people). I don't think that's feasible or a great idea, at least right now. If they want bad time they can always change their SC server's time and connect to that. I don't even know where to begin on speccing out why people want clocks to intentionally be wrong, what they're really trying to accomplish re: wakeup times, and how to best support that, but it can be a future feature request :)
Maybe it's just the beta but I recall a couple of times in the past month where SN has been unavailabile. :) Also, much more importantly, I've had even more times in the past month where my internet was out (comcast issues). Unreliable includes all aspects of the communication link, unfortunately, and it has a single point of failure at the ISP level. If it can get time from SC in preference to SN then, yes, that should be how time is modified and you wouldn't need to do it on the unit, itself certainly. As to why people set the time ahead. I've asked and as near as I can tell it is to increase the physiological pressure when getting ready in the morning. Looking at a later clock spurs them on to get ready quicker, etc. This is also for after they are awake, not really alarm related. Some of the same people set their watches ahead 5 minutes also. However, I don't claim to fully understand it, either.
(In reply to comment #16) > Maybe it's just the beta but I recall a couple of times in the past month where > SN has been unavailabile. :) The beta doesn't run on the production SN hardware, so that's a whole different world. Production SN has had outages in the past too, but those were database-related, they don't have anything to do with the reliability of the server and network infrastructure, and thus the availability of NTP. > Also, much more importantly, I've had even more > times in the past month where my internet was out (comcast issues). Unreliable > includes all aspects of the communication link, unfortunately, and it has a > single point of failure at the ISP level. The player has a local clock which should be of enough accuracy to carry you through outages. NTP's job is to provide an initial time reference and then keep the clock from drifting too far in the long run. Assuming the local hardware clock isn't horrible defective, it sustains network outages just fine.
Status update and open questions I'm hung up on: We have public NTP servers on SN. I've found a BSD-licensed good implementation of an NTP server that could be used as a client on SP hardware devices (it's very small, but correct like the real NTP daemon, as opposed to msntp which only allows one host and is rather hackish and limited), and we could also bundle this with SBS on an alternate port number (such as UDP 3483, for example) to accomplish time sync when using SBS instead of SN, and switch NTP sources when we switch servers (SN vs any number of SBSs). However, without a valid timezone this still doesn't work. We can do an initial guess of the timezone via SN + GeoIP over HTTP in the case that SN is available (even in any case where they don't register there or use it, as it would be a simple service with no credentials of any kind). But the initial guess will sometimes be wrong, and/or the player may later move timezones and we can't be re-guessing constantly on every server connection. In other words, we can default the timezone initially, but the user needs to be able to override/change that at any time through a setting. It has already been said that no new settings for users can be added, period, and I haven't heard any differently since. Thus, this plan is stuck at the moment.
(In reply to comment #18) > I've found a BSD-licensed good > implementation of an NTP server [...] and we > could also bundle this with SBS on an alternate port number (such as UDP 3483, > for example) to accomplish time sync when using SBS instead of SN, and switch > NTP sources when we switch servers (SN vs any number of SBSs). > Err scratch that, was forgetting about Windows, so we have to do a dumb implementation in Perl inside SBS. Still not a big issue, and still leaves the TZ issue.
Status Update: I don't have any way to estimate time on this, because I've never worked on things like this before really. I've put aside everything else this week to figure it out. I'd say a working settings applet for setting the timezone is about 75% complete now, which is the harder part of this bug for me. I hope to have that basically complete today sometime, although it will need review which will undoubtedly result in changes. After that I need to add a UTC epoch time output field to SC/SN and make SP use that for time updates from the current server.
Status update: I have a working SetupTZ settings applet for squeezeplay_squeezeos and patches to Squeezebox{Jive/Fab4/Baby}Applet.lua to use a new date_utc field (if available) in the date response chunk awaiting a little more review on campfire, but I think they're good. Commit for the server-side (SN and SC) date_utc support incoming shortly. Server-side http timezone guess was already added by Andy a while back. Still need to implement the timezone guess support on SP.
== Auto-comment from SVN commit #28619 to the slim repo by blblack == == https://svn.slimdevices.com/slim?view=revision&revision=28619 == bug 12253: add date_utc field to SN/SC date command
Created attachment 5904 [details] Proposed Squeezeplay patch
Created attachment 5906 [details] New proposed patch Some whitespace fixups, and fixed some nits that Richard and Ben pointed out in campfire.
== Auto-comment from SVN commit #7725 to the jive repo by blblack == == https://svn.slimdevices.com/jive?view=revision&revision=7725 == bug 12253: add settings applet for timezone, UTC time sync from SC/SN, and SN-based timezone guesstimation when set to Factory
This is resolved I think, needs QA
== Auto-comment from SVN commit #7727 to the jive repo by blblack == == https://svn.slimdevices.com/jive?view=revision&revision=7727 == bug 12253: oops, this should have been in commit 7725 but wasn't
Created attachment 5932 [details] Proposed change to earlier committed work... The logic added to support SC/SN which are not serving the date_utc field is both uneccessary and potentially problematic, as it will set the time incorrectly if the TZ is set (and TZ is likely to be set, since it is guessed automatically from SN regardless). All 7.4+ SCs and all SN instances will have date_utc anyways, and if they hit an older SC they'll be downgraded on firmware anyways. Attached is a patch to fix/simplify this, making SP not synch the time at all if date_utc is not being served.
== Auto-comment from SVN commit #7749 to the jive repo by blblack == == https://svn.slimdevices.com/jive?view=revision&revision=7749 == bug 12253: remove support for time syncing to non-UTC date field from older SC code
== Auto-comment from SVN commit #7753 to the jive repo by blblack == == https://svn.slimdevices.com/jive?view=revision&revision=7753 == bug 12253: obviously-correct fixups to controller-specific time-related code - hwclock is always UTC now
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.