Time wrong with OSMC @ RPI2

Help and Support
61

See the change Sam linked to which I made a couple of days ago which does exactly that - on the basis that there is no harm in trying to send the time query after the 60 second time out just in case online detection is the issue not the entire internet connection being down.

I feel it needs to be pointed out though that what you are seeing is not a bug in OSMC - the root cause of the problem is still an issue with your network/internet connectivity.

Any operating system that checks for online status does so by querying specific servers, for example windows tries to query http://www.msftncsi.com/ncsi.txt to see whether it has online connectivity. Apple have their own servers that perform a similar function for OS X and iOS. Sometimes there are multiple checks that have to be passed including dns lookups.

For OSMC we use ipv4.online.osmc.io which is one of the OSMC servers, and it doesn’t just expect any response http response, it has to be a specific response. (So that it is not fooled by captive portals etc)

If your network/internet connectivity does not allow the device to connect reliably to that server in a reasonable amount of time then the connectivity state in connman will be incorrect - not much that we can do about that.

In the case of the http-time script its ok to just try anyway but other services that rely on network-online.target will still take a lot longer to load than they should if the internet connection can’t be detected properly.

62 
osmc@osmc:~$ date
Mon Nov 23 19:53:16 ICT 2015
osmc@osmc:~$ curl http://ipv4.online.osmc.io/
<html>
<head><title>403 Forbidden</title></head>
<body bgcolor="white">
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx/1.2.1</center>
</body>
</html>
osmc@osmc:~$ date
Mon Nov 23 19:53:29 ICT 2015
osmc@osmc:~$ connmanctl state
  State = ready
  OfflineMode = False
  SessionMode = False
63

Not you….

64

The correct URL is http://ipv4.online.osmc.io/online/status.html. If you run something like wget --server-response -O /dev/null http://ipv4.online.osmc.io/online/status.html you will see ‘X-OSMC-Status’ which is how we determine (on OSMC) that the device has reached the right server.

65 
osmc@OSMCBR:~$ time  wget --server-response -O /dev/null http://ipv4.online.osmc.io/online/status.html 
--2015-11-23 20:35:00--  http://ipv4.online.osmc.io/online/status.html
Resolving ipv4.online.osmc.io (ipv4.online.osmc.io)... 178.62.84.106
Connecting to ipv4.online.osmc.io (ipv4.online.osmc.io)|178.62.84.106|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Server: nginx/1.2.1
  Date: Mon, 23 Nov 2015 13:35:02 GMT
  Content-Type: text/html
  Content-Length: 1
  Last-Modified: Fri, 06 Mar 2015 13:32:43 GMT
  Connection: keep-alive
  X-OSMC-Status: online
  Accept-Ranges: bytes
Length: 1 [text/html]
Saving to: ‘/dev/null’

/dev/null           100%[=====================>]       1  --.-KB/s   in 0s     

2015-11-23 20:35:01 (11.9 KB/s) - ‘/dev/null’ saved [1/1]


real	0m1.237s
user	0m0.030s
sys	0m0.040s

This on a Pi running Raspbian:

pi@rasp ~/webcam $ connmanctl state
  State = ready
  OfflineMode = False
  SessionMode = False

Why wait 60 seconds? If it returns “ready” or “online”, go for it.

You’re too defensive. I never said or implied that there was a bug in OSMC. I had a problem. I wanted to solve it. I wanted to learn a few things. I think that your original supposition that my time problem was as a result of poorly configured DNS servers was correct.

But, even after the time problem was solved I still have the timeout on the http-time script. I thought that was worth looking in to.

66

Because as I’ve explained earlier, ‘ready’ state means the local network is up but the internet connection is not. ‘online’ means that both local network and internet connection are up. If we want to send a query to a website we should wait until the internet connection is up, not just until the local network is up.

If we try to send the queries before the internet connection is up they will all fail instantly and the whole service will abort, failing to set the time. This is particularly important for wifi where it can take a random amount of time for the wifi adaptor to connect - sometimes as long as 30 seconds.

The http-time script is not rocket science though, its just a wget command asking for an http page from one of three big well known websites. Each request is set to have a 4 second timeout so that it doesn’t take too long to move onto the 2nd and 3rd servers if the first can’t be reached. (The sooner during boot that the time is set the better, and this service runs asynchronously, not holding up the boot process)

If it times out after 4 seconds then it’s a network connectivity issue and it isn’t really worth spending hours of time trying to troubleshoot what is basically a problem with your internet connection. There is certainly no bug to be fixed here as far as I can see.

Remember that when you run the command manually the dns lookup from the previous (boot time) query for the domain name is probably still cached. It’s trying to query it during bootup where the issue is sporadically occurring, which fits in with the slow/unresponsive dns server issues you were having before.

67

From the connman documentation:

For all practical purposes 'ready' and 'online' are usually equivalent for the intended connectivity experience.

In my case the wget never times out. What happens is that “connmanctl state” always returns “ready” even when there is a solid Internet connection.

As you can see above, if I run

time  wget --server-response -O /dev/null http://ipv4.online.osmc.io/online/status.html 
--2015-11-23 20:35:00--  http://ipv4.online.osmc.io/online/status.html

it returns

X-OSMC-Status: online

I’m trying to understand why connmanctl returns ready when it should return online.

68

Sorry but we’re really just going around in circles here wasting each others time.

I believe that you have quoted this to me before, however that does not make it any more true than last time. The connman documentation is wrong on this point. I know for a fact what connman’s online and ready state means, trust me. Both from empirical testing and also studying the source code.

Quoting from the connman documentation won’t be changing my mind when I know the documentation is in error. Ready and Online are not the same. We have been working with connman for over a year now and have delved deeply into its source code and patched various aspects of it as can be seen here:

We have also reported and fixed a number of bugs, including another case where the documentation is wrong - it documents an API call ClearProperty() that we were trying to use, it turns out that the function call was never implemented! :wink:

https://01.org/jira/browse/CM-678

Take all connman documentation with a grain of salt…

If you had a solid internet connection with no problems at all it would work, would it not ? It seems to work for everyone else ?

And as I’ve already explained, if you have slow dns the first attempt to go to a URL during boot up may time out but it then gets cached and will work a subsequent time. connman does not keep trying over and over if the dns lookup fails, so your problem is almost certainly slow/unreliable dns lookup, which has already proven to be the case with your internet provider in the past.

Sorry but I just don’t have any more time to spend on going back and forth with you on this issue when it is clearly an internet connection problem and not a bug.

We’re now up to post number 68 on the same “issue” going around in circles so I’m now closing the thread.

70

just wanna give you this recommendation if your connection is the issue a simple RTC addon for RPI

had similar issues with the clock resetting