Just wondering if any other users have experienced this issue. OSMC seems to lose time. I have to reboot to get the correct time again. Can’t seem to find a correlation with what I am watching or whether the TV is on/off.
No internet or power outages, Rpi2 is on all the time. How would I troubleshoot this issue. I watch live tv using pvr.MythTV plugin. Just wondered if watching live tv for long periods may cause time to ‘stop’ in some circumstances.
Just looking to see if anyone else has experience of this or similar issues.
It’s a recent phenomenon following refresh of all Rpi2;s to the latest OSMC about a couple of weeks ago. I have only noticed it a few times when looking at the MythTV planner and seeing programmes out of sync with the real time when watching them. Only when checking time on the system and seeing that it was hours out of date.
I will keep an eye on it and try and catch when it occurs. The post was really to see if anyone else had experienced similar issues and if there was a precipitating action.
Suggest to also first upgrade to latest OSMC (November release), while there are no changes to NTP it is still be better to be on latest release for troubleshooting
Your problem is almost certainly that UDP source port 123 is being blocked by your ISP or router, preventing ntpd from performing regular time synchronisation.
This seems to be a problem for a few users so some months ago we added a service called http-time which at boot time tries to set the time through an http query. This gets the time close (within a couple of seconds) but does not do any further “synchronisation” until the next boot. This solution is only really a workaround to make the best of a bad situation and is not ideal. (The alternative however is that the time is completely wrong)
If ntpd works as expected it takes over from http-time and continues to adjust the time on an ongoing basis to keep it correct - if ntpd is not able to contact any time servers the time will gradually drift out.
What does the output of the following command say ?
ntpq -c peers
You should get something a bit like this:
osmc@rpi2:~$ ntpq -c peers
remote refid st t when poll reach delay offset jitter
==============================================================================
+5.77.45.219 62.149.0.30 2 u 4 64 17 21.003 0.717 8.125
*vps8641.xlshost 193.67.79.202 2 u 4 64 37 23.604 4.881 1.942
-91.240.0.5 82.220.2.2 3 u 39 64 17 44.392 8.665 9.904
+safi.initipi.sk 147.231.2.6 2 u 44 64 37 104.931 -9.925 20.473
What ntp software are they running ? The issue is not with destination port 123, but with the fact that ntpd uses source port 123 as well. Some ISPs/routers (probably routers) block source port 123. Some other time software does not use source port 123 but uses a high (>1024) port number and does not experience the same issues.
Was the time correct at the time when you ran that command ?
If the time is drifting out then it can only be that ntpd is not doing its job…
Have a look at the troubleshooting on this page and see if it helps: 8. Troubleshooting
We don’t do any customisation of ntpd in OSMC by the way - it is the bog standard ntp package from Debian/Raspbian with default config files. So it’s very unlikely that there is anything OSMC specific causing this issue.