Solved Time and date are incorrect and will not sync
#1
I'm having the most frustrating issue. I just took my router out and replaced it with a router/firewall combo unit. Ever since then the time shows 1:00AM 1970. I tried putting the NTP servers into OpenELEC and the time and date will fix themselves, but only until the next reboot. Then it wipes and goes back to 1:00AM 1970. And that trick doesn't work all the time, sometimes it has the NTP server information but it won't refresh the date and time.

I don't understand what's gone wrong, I have 3 other Pi's all with the same issue. I've even opened my firewall with an Any rule for the Pi's, but still no affect. So two questions:

1) How/where does Kodi pull he time from?

2) Any ideas on how to fix it?


Kodi 15.2
Raspberry Pi 2 Model B
Reply
#2
Pi's get time from network, there is no realtime clock in a pi.

It looks like network is not up when Kodi starts.

How are the pi's connected to your router, ethernet or wifi ?

You could try giving one of the pi's a fixed IP address and see if that improves the situation.
Reply
#3
It's not Kodi pulling time data from an ntp server, it's the underlying OS that does (you know, no RTC on a RPi, no battery also...).

What ever that 'router/firewall' combo might be, one rule should suffice:

- allow any client on your local network to contact ntp sources: local network -> allow outgoing traffic using UDP port 123

If your 'combo' doesn't utilize a proxy, that is.

Maybe your 'combo' can act as an ntp-server itself - then you could configure your OE-PIs to use it as a local time source (not pool.xyz.ntp.org, but 192.168.x.y).

And maybe you just forgot to reconfigure your PIs to reflect your new 'combo's' IP address to use for DNS queries...

And so on, anyway, it'll surely be one small config error.
Bye,
Fry
Kodi v17.6 with shared MariaDB v10.3 | HTS Tvheadend 4.2.6 on RPi2 | running on:
Windows 10x64 | Nvidia Shield | FireTV4k | FireTVStick4 | Android 5 | RPi3 with OSMC
Reply
#4
(2016-01-25, 18:35)MikeB2013 Wrote: Pi's get time from network, there is no realtime clock in a pi.

It looks like network is not up when Kodi starts.

How are the pi's connected to your router, ethernet or wifi ?

You could try giving one of the pi's a fixed IP address and see if that improves the situation.

Pi's are connected ethernet; they run through a small switch at their location, to the core switch, to the firewall appliance.

The Pi's don't have static addresses, but they do have DHCP reservations on the firewall appliance

There's an option to not start Kodi until network connection is established, should I turn that on?


(2016-01-25, 18:39)Fry7 Wrote: It's not Kodi pulling time data from an ntp server, it's the underlying OS that does (you know, no RTC on a RPi, no battery also...).

What ever that 'router/firewall' combo might be, one rule should suffice:

- allow any client on your local network to contact ntp sources: local network -> allow outgoing traffic using UDP port 123

If your 'combo' doesn't utilize a proxy, that is.

Maybe your 'combo' can act as an ntp-server itself - then you could configure your OE-PIs to use it as a local time source (not pool.xyz.ntp.org, but 192.168.x.y).

And maybe you just forgot to reconfigure your PIs to reflect your new 'combo's' IP address to use for DNS queries...

And so on, anyway, it'll surely be one small config error.

Yeah that's the odd part, I'm watching the traffic on the firewall appliance and I'm not seeing any NTP requests from the Pi's. However I had not thought of telling my Pi's to look at a local time source instead of pool.ntp, will definitely test that.
Reply
#5
(2016-01-26, 12:30)nim6us Wrote: There's an option to not start Kodi until network connection is established, should I turn that on?

It's not a Kodi issue, it's an OS issue, so delaying the start of Kodi until you have a network connection won't achieve anything, other than delaying Kodi.

It's almost certainly a misconfiguration in your network, either DHCP (wrong/inaccessible timeservers), DNS or firewall. Easy test would be to temporarily remove the firewall. You should see OpenELEC grabbing the correct time as soon as it connects via connmand:
Code:
-- Logs begin at Tue 2016-01-26 10:16:57 GMT, end at Tue 2016-01-26 10:34:01 GMT. --
Jan 01 01:00:12 rpi22 connmand[354]: eth0 {add} address 192.168.0.18/24 label eth0 family 2
Jan 01 01:00:12 rpi22 connmand[354]: ntp: time slew +1453803405.277557 s
Jan 26 10:16:57 rpi22 systemd[1]: Time has been changed
Jan 26 10:16:57 rpi22 connmand[354]: eth0 {add} route 192.168.0.0 gw 0.0.0.0 scope 253 <LINK>
Jan 26 10:16:57 rpi22 connmand[354]: eth0 {add} route 192.168.0.1 gw 0.0.0.0 scope 253 <LINK>
Jan 26 10:16:57 rpi22 connmand[354]: eth0 {add} route 0.0.0.0 gw 192.168.0.1 scope 0 <UNIVERSE>
Jan 26 10:16:57 rpi22 systemd[1]: Started Kodi user autostart script.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
Reply
#6
(2016-01-26, 12:51)Milhouse Wrote:
(2016-01-26, 12:30)nim6us Wrote: There's an option to not start Kodi until network connection is established, should I turn that on?

It's not a Kodi issue, it's an OS issue, so delaying the start of Kodi until you have a network connection won't achieve anything, other than delaying Kodi.

It's almost certainly a misconfiguration in your network, either DHCP (wrong/inaccessible timeservers), DNS or firewall. Easy test would be to temporarily remove the firewall. You should see OpenELEC grabbing the correct time as soon as it connects via connmand:
Code:
-- Logs begin at Tue 2016-01-26 10:16:57 GMT, end at Tue 2016-01-26 10:34:01 GMT. --
Jan 01 01:00:12 rpi22 connmand[354]: eth0 {add} address 192.168.0.18/24 label eth0 family 2
Jan 01 01:00:12 rpi22 connmand[354]: ntp: time slew +1453803405.277557 s
Jan 26 10:16:57 rpi22 systemd[1]: Time has been changed
Jan 26 10:16:57 rpi22 connmand[354]: eth0 {add} route 192.168.0.0 gw 0.0.0.0 scope 253 <LINK>
Jan 26 10:16:57 rpi22 connmand[354]: eth0 {add} route 192.168.0.1 gw 0.0.0.0 scope 253 <LINK>
Jan 26 10:16:57 rpi22 connmand[354]: eth0 {add} route 0.0.0.0 gw 192.168.0.1 scope 0 <UNIVERSE>
Jan 26 10:16:57 rpi22 systemd[1]: Started Kodi user autostart script.

Thanks for the suggestion, but I'm not sure that's the issue. If I ssh onto the Pi and force an NTP update I can see on my firewall traffic monitor that the Pi goes out and grabs the correct time. However when I reboot the Pi the time is reset back to 1:00AM 1970; I can see on the traffic monitor, it checks for DNS, then it does some port 80 back and forth, but it never even attempts a NTP request. Again I can ssh in and force it to update NTP, but as soon as I have to reboot it's gone again.

I found the below suggestion:

Code:
(Default) FallbackTimeservers are read from:

OpenELEC:/etc/connman/main.conf

FallbackTimeservers = 0.pool.ntp.org,1.pool.ntp.org,2.pool.ntp.org,3.pool.ntp.org

but there have been several posts regarding this not always working, certainly since 5.0.8. The following workaround seems to fix it:
Add Timeservers manually in
System | OpenELEC | Network | NTP servers (for example):

Timeserver #1    0.pool.ntp.org
Timeserver #2    1.pool.ntp.org
Timeserver #3    2.pool.ntp.org

which is then written in:

OpenELEC:/storage/.cache/connman/settings


Timeservers=0.pool.ntp.org;1.pool.ntp.org;2.pool.ntp.org;

I have 4 Pi's; three of them Model B+, and one of them is Model B+ v2. Oddly the fix described above seems to have worked with the three Model B+'s. However on the Pi v2 that fix had no effect.

Any of this information connect the dots on a solution?
Reply
#7
(2016-01-26, 12:51)Milhouse Wrote: It's not a Kodi issue, it's an OS issue, so delaying the start of Kodi until you have a network connection won't achieve anything, other than delaying Kodi.

I misspoke; the option to delay startup until network connection was established is related to OpenELEC not KODI. Either way I tested it and it didn't resolve the issue either. At this point I'm tempted to just write a CRON job forcing the NTP update, however I'd really like to understand what the problem is. If anyone has any other troubleshooting ideas, I'm all ears.
Reply
#8
Okay well I don't have the time to dump into this at the moment. The fix I employed was to tell my firewall appliance to be an NTP server, then I told all the Pi's too look at it for NTP. This seems to have resolved the issue across the board on all Pi's. Thanks to everyone who put their time into this.
Reply
#9
I have a similar problem on my new Pi3 conncted via WiFi. How do I delay Kodi to start to ensure the WiFi is up?
Reply
#10
(2016-04-06, 19:56)scalci Wrote: I have a similar problem on my new Pi3 conncted via WiFi. How do I delay Kodi to start to ensure the WiFi is up?

Depends on the distribution you are using.
Reply
#11
I have the same problem. I have a fresh install of libreELEC 8.0.2 on a raspberry pi 3 connected via wifi and I have set the pool.ntp.org server but still ...
Reply
#12
LibreELEC has a 'Wait for Network" option in the Settings Add-on which you can enable.
Set it to 30 secs for a RPi.
Reply

Logout Mark Read Team Forum Stats Members Help
Time and date are incorrect and will not sync0