Bugzilla – Bug 15894
Timezone gets out of synch on server and radio causing alarm to go at wrong time
Last modified: 2010-04-12 13:01:27 UTC
I have a new Squeezebox Radio with the latest firmware update. When I bought it I set the timezone locally (i.e. on the radio) to EST initially and later MST. Initially, I also set up an alarm which worked fine at the proper time EST. I later had to do a factory reset on the radio. At that point, the alarm did not fire at the proper time. When I was in EST, it seemed (at the time) to go off randomly much later in the day. I would do tests by setting the alarm to go off a few minutes after the current time and nothing would happen. I've since discovered that the problem seems to be a lack of synchronisation in the timezone between the web-server and the radio. When I discovered this problem, the local radio was set to MST. When I went to my account at mysqueezebox.com, however, the timezone was set to PST. Once I set the timezone to MST online, the alarm went off at the right time. I also realised at this point that the alarm had been going off not randomly earlier when I was in the EST, but rather 3 hours late (i.e. the time difference between PST and EST).
I have also seen this behavior during my testing. I noticed it with the SB Radio and SB Boom.
Andy, is timezone a synced preference?
No, it's not a synced pref because SBS does not have a timezone pref. MySB has a timezone pref, and Radio has a local timezone that is set using GeoIP (and can be changed). But a factory reset will wipe that pref out and it will revert to GeoIP. The local timezone is not related to the timezone pref on the server. The alarm should only use the server timezone pref, but I am not sure what happens if it needs to use the fallback alarm.
So after the factory reset, the Radio pref is now reset to the GeoIP *timezone* pref, and it sets its clock from NTP I suppose, so the time should be correct for the pacific tz. Surely Dan would have noticed that, though, since he continues working with it? In any case, the non-default tz setting APPEARS to have persisted across a factory reset. So, that seems wrong one way or another. Not clear how it happened, though. The symptom of the alarm going off much later in the day would seem to indicate that the alarm was being set in EST but triggered in PST. The tz can't be different for both the 'UI' app and the 'player' apps on a SP device, can it? :) Andy, are we doing the 'UI-time-to-UTC' function using the device pref, but when the alarm is triggered, the server uses the MySB pref? Dan, was it playing the right song/radiostation when the alarm triggered?
*** This bug has been confirmed by popular vote. ***
Is this the fallback alarm or the 'regular' programmed alarm that finally goes off at the wrong time? Andy notes this is probably not his bug.
(In reply to comment #6) > Is this the fallback alarm or the 'regular' programmed alarm that finally goes > off at the wrong time? > > Andy notes this is probably not his bug. It's been a while with mine, and now I have issues with the fallback alarm going off consistently too soon. But if I remember aright, at the house I was in, it was the regular prgrammed alarm that was firing. In my house in the different timezone, the backup alarm goes off just faster than the programmed stations can load, probably about 8/10 times.
Developer's note: the previous comment gives further evidence that the fallback alarm should wait longer than it currently does to determine the stream has failed. Alan suggested this interval needed lengthening at a meeting last week...