Losing time. OSMC Rpi2 latest updates etc

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.



I would need to see a log to have a look

To get a better understanding of the problem you are experiencing we need more information from you. Please see How to submit a useful support request - General - OSMC for advice on how to help us.

Do you remember when this first occurred? Or has it always occurred?


HI Sam.

Thanks for taking the time to comment.

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
+      2 u    4   64   17   21.003    0.717   8.125
*vps8641.xlshost    2 u    4   64   37   23.604    4.881   1.942
-       3 u   39   64   17   44.392    8.665   9.904
+safi.initipi.sk      2 u   44   64   37  104.931   -9.925  20.473

Hi thank you for the post. There is no problem with port 123. I have lot of servers running on the same network all use ntp for time sync!

osmc@osmc:~$ ntpq -c peers
     remote           refid      st t when poll reach   delay   offset  jitter
+static.132.14.7    2 u  151 1024  377   46.439    1.184   1.901
-   2 u  133 1024  377   58.357    4.952   2.623
*  .MRS.            1 u  550 1024  377   54.447   -1.129  36.440
+host1.thefox.co   3 u  104 1024  377   36.507    3.120   2.452


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.