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

Help and Support
21

never mind, still had the options timeout:1 in /etc/resolv.conf

22

Hi,

As advised in my first post, any permanent change would probably need to be made locally; as its unlikely Sam will want to make a change for what a appears to a corner case and a local network issue.

Also I doubt forcing wget to use ipv4 is the fix, as you admit yourself:

So that shouldn’t be taking the run time of the script to beyond the 4 second timeout.

What was in it before your edit?

If you just have the following entries:

nameserver 8.8.8.8
namerserver 1.1.1.1

no additonal options (timeout, domain domain or search domain) does the script still timeout?

Also are you using a static or dhcp ip?

Thanks Tom.

23

Well, as far as I see it, I have a fix (wget -4 option) that has worked to reduce the run time of my /usr/bin/http-time-local to less than 0.2 seconds. It has worked on about 20 reboots so far. Of course I leave the pi off for 2 minutes, to see that the time is advanced 2 minutes immediately on the reboot.

I see that wget has a “feature” where if ipv6 is not connected, and ipv4 is connected, it will first do a 5 second timeout on the ipv6 name resolution if the timeout option specified in the command line is longer than that. However, if ipv6 is specified, and ipv6 is not connected, it will immediately return “network is unreachable”.

As a bonus with the ‘-4’, I am now able to enable daily My OSMC update checking, without causing the http-time to timeout with the original wget 4 second timeout, as was happening before adding the wget -4 option.

I do not see this as a corner case, as my ISP is AT&T which does have a few customers. I do thank you for your collaboration on the problem!

Please don’t overwrite /usr/bin/http-time-local in the updates. Mine will be a copy of http-time with the wget -4 option added.

There are a lot of problems that cascade from the OSMC clock not being correct. I only use the Youtube Plugin, which will fail SSL certificate verification if the clock is too far behind the actual time.
A lot of people complain on the forums about the Youtube Plugin not working, even when they have their own Youtube API keys. I bet this whole thing has caused a lot of people to give up on Kodi.

Please consider adding the -4, or at least put it in the menus somewhere.

Please excuse the rant! I really do appreciate the collaboration!

Thanks!

24

Hi,

Ok I can stand corrected, seems to have resolved your issue. But making that change will break the script for users on IPv6, and its not really something that can easily be added to a menu as its separate from kodi. All I can suggest is you follow the steps I posted in my first post in this topic.

Thanks Tom.

25

That’s interesting. Do you have a reference for that? The man page has nothing about a 5-second timeout.

26

Despite your assertion, you are a corner case. Here’s why:

  • You had the same problem on your other Debian box. So it’s not an OSMC issue.
  • Your NTP is “blocked by [your] router or isp”. So, by extension, it’s also affecting your Debian box. You have not resolved this problem.
  • When you added options timeout:1 to /etc/resolv.conf, you saw that the time fell from 5.131 seconds to 1.169 seconds A quick look at the man page for /etc/resolv.conf shows that the default timeout is 5 seconds, so you reduced it to 1 second. From this we can infer that he successful DNS step took around 0.15 of a second and that this is probably a DNS issue.
  • The man page says that timeout “sets the amount of time the resolver will wait for a response from a remote name server before retrying the query via a different name server.” The man page also states: “If there are multiple servers, the resolver library queries them in the order listed” So it is failing on 8.8.8.8 and succeeding on 1.1.1.1.
  • Your ISP is AT&T, who are known to monkey around with users’ traffic.

Everything points to AT&T messing with your Google DNS traffic. Try a different DNS resolver.

3 Likes