Clock starts at midnight upon boot?

[jprostko]

Hello,

I know this isn't quite a pressing issues like others mentioned on this forum, but every time I start up my Boxee Box, the time starts at midnight and is never corrected to the proper time. I assume the BB uses NTP for time synchronization, but the time basically just starts at midnight and increments from there. I am connected wirelessly to my router, and can stream content from outside sources just fine.

I was wondering if anybody else is seeing this issue, or if I should go looking at my router to see if it's blocking some traffic from the BB.

I suppose I could just always boot up my BB at midnight and try not to shut it off, but I don't think that's the most reliable option to have accurate time.

For reference, I'm running v1.0.1.16125 of the Boxee software.

Thanks for any insight, and if this has already been brought up, I apologize. I didn't notice any mention of it in my searches though.

[jprostko]

As a follow-up, I telnetted into the box, and was able to set the time with the "date" command. I then also used "hwclock" in /sbin to set it to the hardware clock. Everything looks happy there until a reboot happens, and the time goes back to Jan 1, 2000 at midnight. So yeah, the RTC and system time must get reset on boot.

I also played with "ntpdate" a bit, and it's likely my problem. I checked and my ISP is blocking port 123. In other words, "ntpdate" fails to find a synchronization server in this case, so the time never gets corrected.

I could dig further, but correcting the time manually after every reboot or shutdown via "date" serves for now. I don't think it's likely any config files I edit would survive a reboot, but basically changing instances of "ntpdate" to "ntpdate -u" would do the trick, it seems, as I grepped around.

I may file a bug report, or even just an enhancement ticket to change NTP settings. I want to play around with it a bit more tomorrow though, just to be sure.

[esch]

At each restart Boxee takes the time from the web.
the most probable reason for not getting the auto update of the clock is that this call is blocked for some reason by your router or firewall

[jprostko]

Yeah, that's why I mentioned my ISP was blocking the port. I called them today, and the guy told me they weren't blocking the port though. I find that hard to believe, since they are known to block a fair share of service ports to keep servers off their system. I also tested straight on the cable modem with the same result, so I know they were to blame.

Anyways, the time synchronization started working probably two hours ago. I am thinking that the ISP went ahead and opened the port in the meantime due to my call.

In any case, I had already opened ticket #7010 ( http://jira.boxee.tv/browse/BOXEE-7010 ) due to this, and I think solely relying on an internet connection to get time for the device isn't exactly a robust solution.

I just tried starting the Boxee with no net connection, and it does see the time as 12:00 AM. I brought the net connection back, and it did attain the correct time, so that is good. That said, I think if the normal NTP synchronization fails, trying "ntpdate -u" should be tried immediately after.

Something like...

Step 1: try "ntpdate pool.ntp.org"
Step 2: if "date +%Y" is 2000, try "ntpdate -u pool.ntp.org"

That way, with step 2, you'll at least get any people who may have set up their router's firewall wrong, or have ISPs like mine.

I still think the RTC should be updated if a valid date/time is attained though, as that could then be read from to get a date/time if the internet were out in the future. I almost think that may not be possible though due to the nature of the device. I'm sure you devs know better.

In any case, thank you, esch, for writing back. It is appreciated!

[DariuszDZW]

I have the same problem here, and my ISP is not that "friendly" that yours to change the 123 port I need a bug correction from Boxee....

[neveroffline]

Yeah, that's why I mentioned my ISP was blocking the port. I called them today, and the guy told me they weren't blocking the port though. I find that hard to believe, since they are known to block a fair share of service ports to keep servers off their system. I also tested straight on the cable modem with the same result, so I know they were to blame.

Anyways, the time synchronization started working probably two hours ago. I am thinking that the ISP went ahead and opened the port in the meantime due to my call.

In any case, I had already opened ticket #7010 ( http://jira.boxee.tv/browse/BOXEE-7010 ) due to this, and I think solely relying on an internet connection to get time for the device isn't exactly a robust solution.

I just tried starting the Boxee with no net connection, and it does see the time as 12:00 AM. I brought the net connection back, and it did attain the correct time, so that is good. That said, I think if the normal NTP synchronization fails, trying "ntpdate -u" should be tried immediately after.

Something like...

Step 1: try "ntpdate pool.ntp.org"
Step 2: if "date +%Y" is 2000, try "ntpdate -u pool.ntp.org"

That way, with step 2, you'll at least get any people who may have set up their router's firewall wrong, or have ISPs like mine.

I still think the RTC should be updated if a valid date/time is attained though, as that could then be read from to get a date/time if the internet were out in the future. I almost think that may not be possible though due to the nature of the device. I'm sure you devs know better.

In any case, thank you, esch, for writing back. It is appreciated!

I think the BB should hit their own server for time, and if that fails, hit another location and update on a valid SNTP packet. If there is no network connection, it cannot possibly get valid time. Plain and simple. With the Net connection, the time is easily set.

[Automan]

My one set the time okay but it would seem the software writers forgot the rest of planet Earth who display the date in a different format e.g. dd/mm/yyyy.

The unit only displays the date in US format but does know about centigrade.

Automan.