Time wrong with OSMC @ RPI2

Had RPI and raspbmc for a long time and everything was running smooth. Now I have switched to RPI2 and OSMC and seems for some reason that time (and date) are wrong.

I have a timezone country set under System - Appearance - International but for some reason it shows date as two days before and time is 25 minutes ahead. ntpd is running but if I stop the ntpd and try running “ntpdate 0.europe.pool.ntp.org” I receive " ntpdate[664]: no server suitable for synchronization found". Also rebooted several times but no go. My internet connection (wifi) is working fine and I can ping the server 0.europe… I have also added it to ntp.conf

Any ideas on how to fix this? Or how to debug?

Pinging a server doesn’t mean it’s responding to ntp requests…

The date/time will be two days behind because fake-hwclock saves the time when you shutdown and resets it when you start up - so if it is turned off for two days and unable to synchronise the time via the internet it will be two days behind.

Can you paste the output of the following command ?

sudo journalctl -u ntp

Just a hunch, but can you also try disabling ipv6 name resolution for ntpd by editing /etc/default/ntp and changing the line to: (just adding -4)

NTPD_OPTS='-4 -g'

Then reboot. See if it makes a difference and also paste the above journal output with the change.

Before the change

– Logs begin at Thu 2015-05-07 19:48:17 CEST, end at Thu 2015-05-07 19:54:37 CE
May 07 19:48:20 osmc ntpd[303]: proto: precision = 0.781 usec
May 07 19:48:20 osmc ntp[262]: Starting NTP server: ntpd.
May 07 19:48:20 osmc ntpd[303]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
May 07 19:48:20 osmc ntpd[303]: Listen and drop on 1 v6wildcard :: UDP 123
May 07 19:48:20 osmc ntpd[303]: Listen normally on 2 lo 127.0.0.1 UDP 123
May 07 19:48:20 osmc ntpd[303]: Listen normally on 3 lo ::1 UDP 123
May 07 19:48:20 osmc ntpd[303]: peers refreshed
May 07 19:48:20 osmc ntpd[303]: Listening on routing socket on fd #20 for interf
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 0.europe.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 1.europe.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 2.europe.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 0.debian.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 1.debian.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 2.debian.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 3.debian.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[309]: signal_no_reset: signal 17 had flags 4000000
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 0.europe.pool.ntp.or
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 1.europe.pool.ntp.or
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 2.europe.pool.ntp.or
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 0.debian.pool.ntp.or
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 1.debian.pool.ntp.or
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 2.debian.pool.ntp.or
lines 1-23…skipping…
– Logs begin at Thu 2015-05-07 19:48:17 CEST, end at Thu 2015-05-07 19:54:37 CEST. –
May 07 19:48:20 osmc ntpd[303]: proto: precision = 0.781 usec
May 07 19:48:20 osmc ntp[262]: Starting NTP server: ntpd.
May 07 19:48:20 osmc ntpd[303]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
May 07 19:48:20 osmc ntpd[303]: Listen and drop on 1 v6wildcard :: UDP 123
May 07 19:48:20 osmc ntpd[303]: Listen normally on 2 lo 127.0.0.1 UDP 123
May 07 19:48:20 osmc ntpd[303]: Listen normally on 3 lo ::1 UDP 123
May 07 19:48:20 osmc ntpd[303]: peers refreshed
May 07 19:48:20 osmc ntpd[303]: Listening on routing socket on fd #20 for interface updates
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 0.europe.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 1.europe.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 2.europe.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 0.debian.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 1.debian.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 2.debian.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[303]: Deferring DNS for 3.debian.pool.ntp.org 1
May 07 19:48:20 osmc ntpd[309]: signal_no_reset: signal 17 had flags 4000000
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 0.europe.pool.ntp.org
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 1.europe.pool.ntp.org
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 2.europe.pool.ntp.org
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 0.debian.pool.ntp.org
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 1.debian.pool.ntp.org
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 2.debian.pool.ntp.org
May 07 19:48:22 osmc ntpd_intres[309]: host name not found: 3.debian.pool.ntp.org
May 07 19:48:28 osmc ntpd[303]: Listen normally on 4 wlan0 192.168.1.254 UDP 123
May 07 19:48:28 osmc ntpd[303]: Listen normally on 5 wlan0 fe80::6670:2ff:fe1a:2a99 UDP 123
May 07 19:48:28 osmc ntpd[303]: peers refreshed
May 07 19:48:30 osmc ntpd_intres[309]: DNS 0.europe.pool.ntp.org -> 188.138.9.208
May 07 19:48:30 osmc ntpd_intres[309]: DNS 1.europe.pool.ntp.org -> 87.97.157.120
May 07 19:48:30 osmc ntpd_intres[309]: DNS 2.europe.pool.ntp.org -> 86.57.251.8
May 07 19:48:31 osmc ntpd_intres[309]: DNS 0.debian.pool.ntp.org -> 147.91.70.1
May 07 19:48:32 osmc ntpd_intres[309]: DNS 1.debian.pool.ntp.org -> 79.175.127.142
May 07 19:48:32 osmc ntpd_intres[309]: DNS 2.debian.pool.ntp.org -> 193.243.171.130
May 07 19:48:32 osmc ntpd_intres[309]: DNS 3.debian.pool.ntp.org -> 87.237.200.242

After the change:

– Logs begin at Thu 2015-05-07 20:01:39 CEST, end at Thu 2015-05-07 20:03:47 CEST. –
May 07 20:01:42 osmc ntpd[292]: ntpd 4.2.6p5@1.2349-o Fri Apr 10 19:31:04 UTC 2015 (1)
May 07 20:01:42 osmc ntpd[310]: proto: precision = 1.198 usec
May 07 20:01:42 osmc ntp[261]: Starting NTP server: ntpd.
May 07 20:01:42 osmc ntpd[310]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
May 07 20:01:42 osmc ntpd[310]: Listen normally on 1 lo 127.0.0.1 UDP 123
May 07 20:01:42 osmc ntpd[310]: peers refreshed
May 07 20:01:42 osmc ntpd[310]: Listening on routing socket on fd #18 for interface updates
May 07 20:01:42 osmc ntpd[310]: restrict: error in address ‘::’ on line 41. Ignoring…
May 07 20:01:42 osmc ntpd[310]: restrict: error in address ‘::1’ on line 45. Ignoring…
May 07 20:01:42 osmc ntpd[310]: Deferring DNS for 0.europe.pool.ntp.org 1
May 07 20:01:42 osmc ntpd[310]: Deferring DNS for 1.europe.pool.ntp.org 1
May 07 20:01:42 osmc ntpd[310]: Deferring DNS for 2.europe.pool.ntp.org 1
May 07 20:01:42 osmc ntpd[310]: Deferring DNS for 0.debian.pool.ntp.org 1
May 07 20:01:42 osmc ntpd[310]: Deferring DNS for 1.debian.pool.ntp.org 1
May 07 20:01:42 osmc ntpd[310]: Deferring DNS for 2.debian.pool.ntp.org 1
May 07 20:01:42 osmc ntpd[310]: Deferring DNS for 3.debian.pool.ntp.org 1
May 07 20:01:42 osmc ntpd[315]: signal_no_reset: signal 17 had flags 4000000
May 07 20:01:44 osmc ntpd_intres[315]: host name not found EAI_NODATA: 0.europe.pool.ntp.org
May 07 20:01:44 osmc ntpd_intres[315]: host name not found EAI_NODATA: 1.europe.pool.ntp.org
May 07 20:01:44 osmc ntpd_intres[315]: host name not found EAI_NODATA: 2.europe.pool.ntp.org
May 07 20:01:44 osmc ntpd_intres[315]: host name not found EAI_NODATA: 0.debian.pool.ntp.org
May 07 20:01:44 osmc ntpd_intres[315]: host name not found EAI_NODATA: 1.debian.pool.ntp.org
May 07 20:01:44 osmc ntpd_intres[315]: host name not found EAI_NODATA: 2.debian.pool.ntp.org
May 07 20:01:44 osmc ntpd_intres[315]: host name not found EAI_NODATA: 3.debian.pool.ntp.org
May 07 20:01:49 osmc ntpd[310]: Listen normally on 2 wlan0 192.168.1.254 UDP 123
May 07 20:01:49 osmc ntpd[310]: peers refreshed
May 07 20:01:51 osmc ntpd_intres[315]: DNS 0.europe.pool.ntp.org -> 91.240.0.5
May 07 20:01:51 osmc ntpd_intres[315]: DNS 1.europe.pool.ntp.org -> 148.251.90.84
May 07 20:01:51 osmc ntpd_intres[315]: DNS 2.europe.pool.ntp.org -> 178.79.162.34
May 07 20:01:51 osmc ntpd_intres[315]: DNS 0.debian.pool.ntp.org -> 193.243.171.130
May 07 20:01:51 osmc ntpd_intres[315]: DNS 1.debian.pool.ntp.org -> 92.60.224.24
May 07 20:01:51 osmc ntpd_intres[315]: DNS 2.debian.pool.ntp.org -> 87.237.200.242
May 07 20:01:52 osmc ntpd_intres[315]: DNS 3.debian.pool.ntp.org -> 195.178.58.245
May 07 20:03:24 osmc ntpd[310]: ntpd exiting on signal 15
May 07 20:03:24 osmc ntp[526]: Stopping NTP server: ntpd.
May 07 20:03:47 osmc ntpd[553]: ntpd 4.2.6p5@1.2349-o Fri Apr 10 19:31:04 UTC 2015 (1)
May 07 20:03:47 osmc ntp[547]: Starting NTP server: ntpd.
May 07 20:03:47 osmc ntpd[554]: proto: precision = 1.198 usec
May 07 20:03:47 osmc ntpd[554]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
May 07 20:03:47 osmc ntpd[554]: Listen normally on 1 lo 127.0.0.1 UDP 123
May 07 20:03:47 osmc ntpd[554]: Listen normally on 2 wlan0 192.168.1.254 UDP 123
May 07 20:03:47 osmc ntpd[554]: peers refreshed
May 07 20:03:47 osmc ntpd[554]: Listening on routing socket on fd #19 for interface updates
May 07 20:03:47 osmc ntpd[554]: restrict: error in address ‘::’ on line 41. Ignoring…
May 07 20:03:47 osmc ntpd[554]: restrict: error in address ‘::1’ on line 45. Ignoring…

And still the same.

Thanks, that rules one possibility out, you can change that option back now.

Do you have anything unusual about your router or ISP that could be blocking traffic on port 123 ?

BTW ntpdate is not installed in OSMC by default, did you install that ?

No, there was nothing unusual. Yes, I installed it. Anyway, openvpn also didnt want to start for some reason and I had enough so I installed another distro and everything is fine now. Time is fine so it was config related for sure. Sorry I couldnt debug more. I need my pi up and running and dont have that much time for debuging. I might revert when its stable enough.

Thanks anyway.

Unfortunately none of the OSMC devs can reproduce this issue first hand and we don’t have any idea what the cause is either, so until someone experiencing the issue is able to do some further testing and debugging we won’t be able to fix it.

My hunch is that the different ntp clients are using different source ports and that the source port is being filtered by a NAT router/firewall, but without being able to confirm it this is only speculation.

I’m having a similar problem with the same device. It just started a month or so ago. The time will stay set for a while (many days) and then be off by some random number of minutes, usually greater than an hour.

No firewall on my router and no ports blocked. All the other devices on my LAN (including a VERO) use NTP to set the time and none of them are ever off. Time zone on the Pi is set correctly.

Rebooting always corrects the time.

Is there some way to fix the time from the command line without rebooting?

smc@OSMCBR:~$ sudo journalctl -u ntp
-- Logs begin at Wed 2015-10-28 14:04:02 ICT, end at Wed 2015-10-28 15:32:29 ICT
Oct 28 14:05:09 OSMCBR ntpd[448]: ntpd 4.2.6p5@1.2349-o Mon Apr 13 10:28:34 UTC 
Oct 28 14:05:09 OSMCBR ntp[441]: Starting NTP server: ntpd.
Oct 28 14:05:09 OSMCBR ntpd[449]: proto: precision = 1.000 usec
Oct 28 14:05:09 OSMCBR ntpd[449]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 12
Oct 28 14:05:09 OSMCBR ntpd[449]: Listen and drop on 1 v6wildcard :: UDP 123
Oct 28 14:05:09 OSMCBR ntpd[449]: Listen normally on 2 lo 127.0.0.1 UDP 123
Oct 28 14:05:09 OSMCBR ntpd[449]: Listen normally on 3 eth0 192.168.0.151 UDP 12
Oct 28 14:05:09 OSMCBR ntpd[449]: Listen normally on 4 lo ::1 UDP 123
Oct 28 14:05:09 OSMCBR ntpd[449]: peers refreshed
Oct 28 14:05:09 OSMCBR ntpd[449]: Listening on routing socket on fd #21 for inte

You won’t be having the same problem that was described in this thread, because this issue was resolved many months ago, (you’re replying to a 5 month old thread) and did in fact turn out to be that some users firewalls/routers or ISP’s were blocking ntp connections with a source port of 123.

Anyway, it sounds like you have one or more “bad” ntp servers that are messing up your time. When the time goes wrong, run the following command:

ntpq -c opeers

This will list which ntp servers are currently being used, which is the preferred, what time differences there may be between them, etc. Here is an example when I ran it on my system:

osmc@rpi2:~$ ntpq -c opeers
     remote           local      st t when poll reach   delay   offset    disp
==============================================================================
*skarabrae.draxi 10.0.87.251      2 u    -  128  377   34.152    0.373   5.699
+slunce.swelter. 10.0.87.251      3 u   36  128  377   32.687    0.729   6.843
+intek-m.tv      10.0.87.251      2 u   83  128  377   71.064    0.110   8.679
-alvo.fungus.at  10.0.87.251      3 u   26  128  377   25.983  -17.607   6.878

EDIT: Use

ntpq -c peers

instead - this will give the actual IP addresses of the peers.

What we can see here is that one of the ntp servers is giving bad time that is 17 seconds out, but the other three are within a fraction of a second of each other. The minus sign means before alvo.fungus.at means that the server is being ignored because it is too far out of sync with the other servers, however if you can only reach one or two servers then ntpd has no way of knowing which servers are correct - only by correlation between three or more servers can it get any idea which have the correct time if some are incorrect.

Another command you can check the output of is:

ntptime

Here is what mine currently says:

osmc@rpi2:~$ ntptime
ntp_gettime() returns code 0 (OK)
  time d9db2b3d.853d5314  Wed, Oct 28 2015 11:08:45.520, (.520467111),
  maximum error 307484 us, estimated error 976 us, TAI offset 0
ntp_adjtime() returns code 0 (OK)
  modes 0x0 (),
  offset 138.575 us, frequency -3.763 ppm, interval 1 s,
  maximum error 307484 us, estimated error 976 us,
  status 0x2001 (PLL,NANO),
  time constant 7, precision 0.001 us, tolerance 500 ppm,

If you can paste the output of those two commands when the time is out that may provide some clues.

There is no command to “fix” the time as such - ntpd is running constantly in the background making small adjustments so the time is only going to be wrong if it is getting bad time information from one of the ntp servers.

Silly me. I guess I thought the issue remained unresolved because the last post in the read, the one just before mine, says:

And, since I’m “experiencing the issue” and was willing to do “further testing and debugging”, I thought I’d post here instead of starting a new thread.

Sorry for the mistake.

There’s no need to get in a huff. I was merely pointing out that you have replied to a very old thread that pre-dates even the first stable release of OSMC - a lot has changed since then.

The thread ended without resolution because decabro decided it was easier to pack his bags and switch to another distribution rather than helping to test to figure out the issue. (Fair enough, since this was a pre-release version of OSMC, not everyone wants to test pre-release software)

The same problem was discussed in several other threads and was finally resolved, but this thread was not updated.

I pointed out that I don’t think you have the same issue because there is a very strong tendency for people to see a problem that looks superficially similar and jump into the thread with “me too” when really the problem is something completely different.

This happens frequently on this forum and causes many threads to become a confused jumbled mess because you have multiple people talking about what are in fact different issues, which can hinder the original poster getting a resolution to their problem.

In this case this thread was dead 5 months ago again so not a big deal, but we still try to keep different problems separated in different threads so different issues don’t get conflated.

I’ve provided some commands you can try running when you next see the issue so please try those and post the results if you are interested in solving this issue.

We might as well continue in this thread as it is dead anyway. (I didn’t ask you to start a new thread, just pointed out that I don’t think your problem is related)

1 Like

Since then, dcabro was even more frustrated with different distribution and has in fact, returned to now stable release of OSMC where he hasn’t seen this problem on the same hardware ever since. I have also changed the ISP so not sure if it was something related to the OSMC itself or ISP doing something they should not…

Nice to have you back. :smile:

It could be either the change of ISP or the changes we made. We added a system service called http-time which during boot tries to set the time from an http query to google, microsoft or apple. This gets the time “near enough” (within a second or two) so that if ntp is unable to connect (due to the issue you were seeing with port 123 being blocked) you at least have the time pretty close even if it is not perfect.

If ntp is able to connect, it further fine tunes the time down to a fraction of a section and continues to adjust the time to keep it in sync.

Correct time:

Bleach:~ mnewman$ date
Fri Oct 30 12:42:41 ICT 2015

Raspberry Pi time and output of ntpq -c peers and ntptime

osmc@OSMCBR:~$ date
Fri Oct 30 11:33:04 ICT 2015
osmc@OSMCBR:~$ ntpq -c peers
ntpq: read: Connection refused
osmc@OSMCBR:~$ ntptime
ntp_gettime() returns code 5 (ERROR)
  time d9dd71a3.e0466268  Fri, Oct 30 2015 11:33:39.876, (.876074579),
  maximum error 16000000 us, estimated error 62445 us, TAI offset 0
ntp_adjtime() returns code 5 (ERROR)
  modes 0x0 (),
  offset -12.701 us, frequency -12.498 ppm, interval 1 s,
  maximum error 16000000 us, estimated error 62445 us,
  status 0x6041 (PLL,UNSYNC,NANO,MODE),
  time constant 10, precision 0.001 us, tolerance 500 ppm,

Looks like the service stopped running for some reason:

osmc@OSMCBR:~$ ps -ef | grep ntpd
osmc     11185 11057  0 11:52 pts/1    00:00:00 grep ntpd

I guess this is why rebooting always sets the time correctly.

Restarting it gets the time right:

osmc@OSMCBR:~$ sudo service ntp restart
osmc@OSMCBR:~$ date
Fri Oct 30 13:08:29 ICT 2015

Thing is, why did it stop and what can I do to keep it running?

Edit: So, it can be fixed from the command line….

Am I wrong in thinking that a service like this ought to be automatically restarted if it crashes for some reason?

Or, should I set up a cron job to restart it every few hours?

When it crashes, try sudo systemctl status ntp. This may give you some insight in to what has happened.

Sam

It is possible to configure a systemd service to be automatically restarted if it crashes with an error, but it is much better to find the reason for the crash. ntp is a very well tested very reliable program that has been around for decades, it is not something that is likely to crash on its own and this would tend to suggest some other problem with the system, such as running low on memory.

Next time it happens please provide the output of the following two commands, without rebooting first:

sudo systemctl status ntp.service
sudo journalctl | paste-log

Edit: I don’t think ntp is a systemd service, it is still a legacy init script, so won’t have an automatic restart option.

osmc@OSMCBR:~$ date
Sun Nov  1 04:50:27 ICT 2015

The time was OK yesterday late afternoon. This morning it is about three hours off.

osmc@OSMCBR:~$ sudo systemctl status ntp.service -l
● ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp)
   Active: active (exited) since Fri 2015-10-30 11:56:43 ICT; 1 day 16h ago
  Process: 11213 ExecStop=/etc/init.d/ntp stop (code=exited, status=0/SUCCESS)
  Process: 11224 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)

Oct 30 11:56:43 OSMCBR ntpd[11231]: ntpd 4.2.6p5@1.2349-o Mon Apr 13 10:28:34 UTC 2015 (1)
Oct 30 11:56:43 OSMCBR ntp[11224]: Starting NTP server: ntpd.
Oct 30 11:56:43 OSMCBR ntpd[11232]: proto: precision = 1.000 usec
Oct 30 11:56:43 OSMCBR ntpd[11232]: Listen and drop on 0 v4wildcard 0.0.0.0 UDP 123
Oct 30 11:56:43 OSMCBR ntpd[11232]: Listen and drop on 1 v6wildcard :: UDP 123
Oct 30 11:56:43 OSMCBR ntpd[11232]: Listen normally on 2 lo 127.0.0.1 UDP 123
Oct 30 11:56:43 OSMCBR ntpd[11232]: Listen normally on 3 eth0 192.168.0.151 UDP 123
Oct 30 11:56:43 OSMCBR ntpd[11232]: Listen normally on 4 lo ::1 UDP 123
Oct 30 11:56:43 OSMCBR ntpd[11232]: peers refreshed
Oct 30 11:56:43 OSMCBR ntpd[11232]: Listening on routing socket on fd #21 for interface updates

osmc@OSMCBR:~$ sudo journalctl | paste-log
http://paste.osmc.io/wuhigisifo

osmc@OSMCBR:~$ sudo service ntp restart
osmc@OSMCBR:~$ date
Sun Nov  1 04:54:55 ICT 2015
osmc@OSMCBR:~$ date
Sun Nov  1 07:18:12 ICT 2015

I can see one problem right away - your Pi’s internet connection does not seem to be working properly:

Oct 28 14:05:09 OSMCBR http-time[219]: No internet connection was available within 60 seconds, giving up.

http-time is the “backup” time setting service that we introduced a few months ago whose job is to try to set the time based on a standard http query to www.google.com, www.apple.com, www.microsoft.com in that order. (Using the first one that replies)

It waits up to 60 seconds for connman to report the internet connection is active, and the log says this has failed. connman queries http://ipv4.online.osmc.io/online/status.html which means for some reason you are not able to reach this address.

While it’s unusual for ntpd to crash I suspect it’s because it is having difficulty connecting to any ntp servers as well. I would start by checking your internet connection to make sure traffic to the above address is not being blocked.

You had some issues recently with your ISP. Could they be playing up again? If you follow Simon’s instructions above that should give you some insight as to whether that is indeed the case.

Cheers

Sam

I guess it could be an ISP problem, but there haven’t been any noticeable glitches in the past five or six days. The most recent problem I had with them was a routing problem which only involved servers in Malaysia and Singapore.

I installed Lynx on the Pi and didn’t have trouble reaching any URL including http://ipv4.online.osmc.io/online/status.html (which seems to just display a blank page). I could also get to Apple, Google and Microsoft.

osmc@OSMCBR:~$ ping 178.62.84.106
'PING 178.62.84.106 (178.62.84.106): 56 data bytes
64 bytes from 178.62.84.106: seq=0 ttl=52 time=549.208 ms
64 bytes from 178.62.84.106: seq=1 ttl=52 time=540.650 ms
64 bytes from 178.62.84.106: seq=2 ttl=52 time=599.377 ms

Does OSMC on Vero use the same time setting scheme? The time on the Vero and has never been off. Same for all the other devices on the LAN. I also have Raspbian running on an older Pi and it seems to have no trouble keeping the time.

It seems that if it were an ISP problem, I’d see time errors on more than one device.

Who’s Simon?