The date and time on my Vero is way off. It thinks it’s January 3, 1970 and the time is about 4 hours and 33 minute behind. I’ve searched and found this has happened with Kodi to others and the only answer I found on how to fix it was to do a complete reinstall. Is there an easier way to fix this issue?
1 Like
Hi
You will not need a fresh install. Are you connected to the Internet?
Sam
In truckmann’s situation, if internet were available, would creating the following apply?
Creating ntpdate file in /etc/cron.daily/ with time server inclusion, then making it executable?
This is what I have created, instead of waiting for restart, to update system time.
Guys,
We already have an ntp client in OSMC that runs on startup, so as long as there is a network connection available it should update the time. No need to go installing your own ntp client. Date and time is updating on boot just fine on my Vero.
It is connected to the internet via a wired connection and I can download addons and stream from YouTube.
I’ve had the same on my system, but it’s intermittent. Sometimes the network doesn’t come up properly, or maybe too slowly? and then the ntp server doesn’t connect, and some scripts don’t work, eg osmc settings reports “script failed”. I can ssh in though so the local network connection is OK, may be a gateway or routing configuration issue?
Usually a reboot fixes it, but not sure how to tell what’s wrong in the network configuration.
I found if I kill the ntp daemon and use ntpdate to set the clock it works, which suggests routing/nameservers are working?
It has not been internment for me. I have rebooted several times and it hasn’t updated at all. I haven’t tried to update it manually yet.
Hi guys
Are you both on the latest version of OSMC (you can go to My OSMC -> Updates -> Manual Controls and initiate an update from there)
Sam
I updated it right after receiving it and double checked for an update yesterday so unless there was another update since then I should be on the latest build.
I’m on a pi2 with rc2 osmc.
Just upgraded to an official rpi power supply as was getting occasional rainbow square (only briefly, once or twice an evening) and the clock setting problem seems to have gone away, so may be related to startup power demands, hard drive spinning up while WiFi adapter trying to connect etc. WiFi is the WiPi dongle from Farnell. Only got the new psu yesterday so too early to be sure it’s fixed, but hopeful.
Is there no answer to this? Mine is still not picking up the correct date/time and just counting up from 1970.
Does sudo systemctl restart ntp change the time?
S
We can’t reproduce this problem first hand and don’t know what the cause might be at the moment, (or even that it is a fault in OSMC and not a network connectivity issue) without someone who is experiencing this problem helping us to debug the problem.
There have been a couple of attempts to do so in other recent threads but in each case the user in question gave up and decided it was too much trouble and went back to raspbmc or some other distribution.
Unfortunately while I appreciate it’s their right to do so, it doesn’t help us get the problem solved either. If you’re serious about helping to troubleshoot this problem by running some tests and providing logs then let us know.
A quick first test to try manually updating the time:
sudo systemctl stop ntp
sudo ntpd -qg
You should see something like this:
osmc@rpi2:~$ sudo ntpd -qg
ntpd: time set +1431192928.052206s
Another test, restart the ntpd service first, either by rebooting or:
sudo systemctl start ntp
Wait about a minute then run:
ntpq -p
You should see something similar to the following:
osmc@rpi2:~$ ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*161.53.131.231 81.17.128.133 2 u 22 64 7 59.357 4.680 1.613
-la.spb.ru 192.168.0.22 5 u 28 64 7 70.314 19.488 0.928
+service1-eth3.d 121.131.112.137 2 u 26 64 7 53.675 3.541 1.737
+stz-bg.com 129.69.1.153 2 u 22 64 7 67.219 3.476 1.291
1 Like
I’ll do whatever I can to help figure this out. I’m far from a being a programmer but I can manage to run whatever commands I’m given. I’ll test out what you have given me as soon as I have a chance to and report back.
No luck with the first commands. Nothing is returned when I used those and the session seemed to freeze or something. 
Here is what was returned with the second command.
Thanks, that’s helpful.
It’s showing that ntpd is able to look up the IP address of some time servers but is not able to get a response from any of them. (Stuck in INIT state)
Could you now try the following. We need to install a program called ntpdate which you can do like this:
sudo apt-get update && sudo apt-get install ntpdate
Then make sure ntpd isn’t running:
sudo systemctl stop ntp
Then we’ll try manually setting the time with ntpdate in two different ways. First, try:
sudo ntpdate 0.debian.pool.ntp.org
It might take a few seconds so give it a chance. If that fails post the error message here then also try:
sudo ntpdate -u 0.debian.pool.ntp.org
The results of those two tests should give us a better idea of what’s happening.
1 Like
First attempt. 
Second command success!
Thanks for that!
We finally know what is causing this issue at least in your case, but I suspect its the same for most other people with the same problem.
Basically something between your Pi and the time servers on the internet is dropping packets with a source port of 123. Most likely this is your broadband router/firewall.
Running ntpdate with the -u option tells it to use a “high port” (Ports >1023) for the source port, and that apparently goes through ok.
The problem is although we now know the cause the solution isn’t immediately obvious because ntpd (the normal background ntp client we use) does not give the option to use a source port other than 123, which means possibly having to switch to a different ntp client altogether.
In any case we will investigate and see if we can get this fixed.
What type of internet connection do you have (cable/dsl etc) and what sort of router/firewall setup do you have ? I assume you use some sort of NAT router so that the Pi is on a private IP address ?