OSMC on Pi 2 incorrect time, http-time, fix the timeout value

I have ntp blocked by my router or isp. It can’t be enabled at the router.
I rely on /usr/bin/http-time in OSMC to set the time.
On my Raspberry Pi 2 running OSMC, I have been able to get things to work by changing the timeout=4 in http-time, to timeout=10.

Every time you guys put out a new version I have to make this edit to get it to work. Could you permanently change the timeout in the script?

I think the root cause is that my router doesn’t provide a DNS cache. So this adds some delay.

In /usr/bin/http-time, I have to change this line –
DATE_STRING=$(LANG=C wget --server-response --timeout=4 --max-redirect 0 --spider “$server” 2>&1 | egrep -o ‘^ Date:.’ | sed ‘s/^ *Date: *//g’)

to this line –
DATE_STRING=$(LANG=C wget --server-response --timeout=10 --max-redirect 0 --spider “$server” 2>&1 | egrep -o ‘^ Date:.’ | sed ‘s/^ *Date: *//g’)



More likely to be the ISP, than the router; most soho routers would just automatically allow ntp. The real solution is to contact your ISP and ask them to unblock ntp or if it is the router, I would consider replacing it.

It will be up to sam_nazarko as whether to make this change, but it would be better if you had a more permanent local fix. This would be my suggestion:

sudo cp /usr/bin/http-time /usr/bin/http-time-local

make the required change to /usr/bin/http-time-local

sudo cp /lib/systemd/system/http-time.service /etc/systemd/system/http-time.service

make the following update to the copy

change line:




issues the following commands:

sudo systemctl daemon-reload
sudo systemctl enable http-time

Now on startup the edited version will run, even after updates. I would check from time to time there have be no changes to /usr/bin/http-time, you can use diff for this. So if you were diff the files now, you can see just the timeout change that has been made:

diff /usr/bin/http-time /usr/bin/http-time-local
< 	DATE_STRING=$(LANG=C wget --server-response --timeout=4 --max-redirect 0 --spider "$server" 2>&1 | egrep -o '^ *Date:.*' | sed 's/^ *Date: *//g')
> 	DATE_STRING=$(LANG=C wget --server-response --timeout=10 --max-redirect 0 --spider "$server" 2>&1 | egrep -o '^ *Date:.*' | sed 's/^ *Date: *//g')

Thanks Tom.

1 Like

A 10 second timeout seems excessive and indicates some sort of DNS or network problem. You’re better off to try to figure out what that is, as 4 seconds is already a long timeout for a query that should complete in a small fraction of a second.

Do you use DHCP or Static configuration ? The first part of the script waits until connman reports the network is up - in the case of DHCP that means that it has received a lease confirmation from the DHCP server.

At that point your network connection should be up and running and there shouldn’t be any delays. Do you still get a timeout if you manually run the following command ?

time wget --server-response --timeout=4 --max-redirect 0 --spider "www.google.com" 2>&1 | egrep -o '^ *Date:.*' | sed 's/^ *Date: *//g'

If it does succeed what does time report for ‘real’ ?

Thinking it might be network related.
I tried the following commands on a much faster Debian 10 system on the same LAN.
I only use static addressing on all my systems, including OSMC on the Pi 2.

$ time wget --server-response --timeout=10 --max-redirect 0 --spider “www.google.com” 2>&1 | egrep -o ‘^ Date:.’ | sed ‘s/^ *Date: *//g’
Sun, 05 Apr 2020 20:02:18 GMT

real 0m5.131s
user 0m0.014s
sys 0m0.001s

$ time wget --server-response --timeout=4 --max-redirect 0 --spider “www.google.com” 2>&1 | egrep -o ‘^ Date:.’ | sed ‘s/^ *Date: *//g’

real 0m4.009s
user 0m0.014s
sys 0m0.002s

cat resolv.conf
domain domain
search domain

BTW, even the 10 second timeout wont work if I check for updates automatically on the Pi 2. Somehow checking for updates will result in reaching the http-time 10 second timeout.


Problem is not DNS related ----
$ time host google.com
google.com has address

real 0m0.184s
user 0m0.013s
sys 0m0.008s


Whats the output of:

ping -c 5 www.google.com

Thanks Tom.

ping -c 5 google.com
PING google.com ( 56(84) bytes of data.
64 bytes from dfw06s49-in-f14.1e100.net ( icmp_seq=1 ttl=55 time=16.3 ms
64 bytes from ( icmp_seq=2 ttl=55 time=15.8 ms
64 bytes from ( icmp_seq=3 ttl=55 time=15.6 ms
64 bytes from ( icmp_seq=4 ttl=55 time=15.6 ms
64 bytes from dfw06s49-in-f14.1e100.net ( icmp_seq=5 ttl=55 time=15.3 ms

google.com ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 10ms
rtt min/avg/max/mdev = 15.341/15.722/16.288/0.337 ms

Blanked out some info because “Sorry New Users can only put 5 links in a post.”

Just to be clear. Are you running your tests from the other Debian box or from the OSMC Pi?

other debian box, which also has the same 5+ second speed on the wget.

Ok. I’d suggest that you return to using the OSMC Pi for further tests.


Looks ok, this shouldn’t make any difference but google.com & www.google.com are different IPs ( &; could be a routing issue with your isp, so could you please try pinging the following hostnames from your pi:


And post the results here.

Thanks Tom.

Can’t copy text directly from the remote desktop viewer.
On the OSMC running on the Pi2, ran this command
for each of the 3 web addresses.

osmc@Kodi:~$ ping -c 5 www.google.com
min/avg/max = 14.740/14.992/15.175 ms

16.6/42.8/146.3 ms

17.4/27.1/65.4 ms

tested wget to www.google.com is real >5 secs, but when I use the IP returned in another wget, it is real .051 secs. I found this link, it looks very close to what I’m seeing. ipv6 related stuff.


May speed up my youtube plugin which is painfully slow to see videos.

I’m unclear what you’re saying. Amongst other things, the link describes how you can specify the -4 flag to use IPv4 and the -6 flag to use IPv6. Last time I looked, IPv6 was disabled on OSMC, so wget -6 should give you a “network unreachable” error.

Could you also be more specific about what you mean by “but when I use the IP returned in another wget”. Which IP are you talking about?

As @Tom_Doyle mentioned above, it might be a problem with your ISP, but before you try anything else, I’d recommend that you reboot your router.


Is this on pi or the debian box?

Are using a static ip or dhcp on the pi?

Thanks Tom.

I just now edited on the Pi /etc/resolv.conf
options timeout:1

When I run the time wget www.google.com, I get real time delay of 1.169 seconds.

So much better!
So somehow something before the IPv4 nameserver is checked, something else times out for 1 seconds.
BTW, this is also true on my Debian 10 system, in addition to the OSMC Pi.
My LAN is 100Mbps ethernet, and I have a DSL router/modem supporting only IPv4.


You need to be clearer about what you’re doing because running the command wget www.google.com is not the same as running wget --server-response --timeout=4 --max-redirect 0 --spider “www.google.com”.

Please also answer Tom’s questions and indicate whether you’ve rebooted your router.

Have you already abandoned the IPv6 theory?

So I conclude that as in the OSMC script /usr/bin/http-time, line 24 of the file,
wget --server-response --timeout=4 --max-redirect 0 -spider “$server” …

will first try an IPv6 address. That will timeout.
then tries the IPv4 address. That works.

I have now changed the wget command, to include “-4”
Now everything works in less than 0.2 seconds every time.

So please change the script to add the option ‘-4’ to the wget command in the http-time script.


Back in post #4, you wrote that the response time was 5.131 reconds. By your logic, the IPV6 timeout would have been just under 5 seconds.

What’s the time to run:

wget -6 --server-response --timeout=10 --max-redirect 0 --spider “www.google.com” ?

… Network is unreachable
less than 1 second to respond.