[MB Premium Twin HD] Problem with system time settign at boot-up

[birdman]

Problem with system time setting at boot-up

I've just been playing back a recording from an hour ago and was surprised to find the first few minutes were missing.

I eventually noticed that the time on the box was 9 minutes slow (so the recording had started 9 minutes late).

I have the box configured to get the time form the transponder, but it turns out that at boot time (according to /var/log/messages) it runs ntpdate to set the time via NTP:

May 15 18:06:38 mbtwin daemon.notice ntpdate[402]: step time server 78.109.188.115 offset 1431709536.911342 sec

The unfortunate thing about that is that currently that time server is running 9 minutes slow!

root@mbtwin:/var/volatile/log# ntpdate -q 78.109.188.115
server 78.109.188.115, stratum 2, offset -542.344368, delay 0.05296
15 May 20:14:36 ntpdate[7487]: step time server 78.109.188.115 [COLOR=#ff0000]offset -542.344368[/COLOR] sec

So,

• where is this server setting configured - it would make more(?) sense to query multiple servers (such as using pool.ntp.org instead)
• why did the "from Transponder" setting have no effect once the system was running? It had been up for nearly 2 hours and was still 9 minutes slow until I fixed it by hand just now (which I had to do from the command line as the Enigmna2 GUI doesn't give you any option to set the time "now").

 

[birdman]

Hmmm...so I went looking to find that Components/NetworkTime.py and mytest.py both call /usr/bin/ntpdate-sync, which uses /etc/default/ntpdate as a config file - which is configured to use pool.ntp.org.

So I can only assume that at the time my system booted 78.109.188.115 was on the list for that.

However, the question as to why the transponder time (which is what is configured to be used) wasn't used still remains.

[And I also notice that /etc/default/ntpdate is set to update the hardware clock on my system - even though it has no hardware clock ( a minor point though).]

 

[adm]

FYI

My last boot
mbtwin daemon.notice ntpdate[389]: step time server 176.58.109.199 offset 1431628094.591836 sec

A traceroute gives time.videxio.net

I assume that the offset value is the number of seconds that box thinks it is away from Reference Timestamp: Jan 1, 1970 00:00:00.000000000 UTC at switch-on

 

[birdman]

Further looking.

enigma2/lib/dvb/dvbtime.cpp

Seems to indicate that the Transponder time will only be used if it is within 120s of the current "enigma time".
This is despite the fact that the box is configured to use Transponder time.
So it has managed to get an incorrect NTP time (which it was not configured to use) and this has screwed up the time setting when it could have got a correct one from the Transponder (which it is configured to use)!!

 

[adm]

What happens if a connection to the net is not available at boot time or never available? An inaccurate clock/time would never ever be updated?

 

[birdman]

What happens if a connection to the net is not available at boot time or never available? An inaccurate clock/time would never ever be updated?

I don't think so (but haven't looked too deeply at that). If there is no time set then I think it will set the Transponder time. The problem is that if there is already a system time set it won't use the transponder one if they differ by >120s, even though the box is configured to use it.

 

[thejoker]

So what is the fix. My box is an hour and half slow and all obvious methods have been tried.

 

[bbbuk]

Not sure if this is an image problem (or at least not a recent image problem)!

My solo2 has been on standby all night and is currently displaying accurate time and even after turning on it still displays accurate time.

This is using usb flash of hades 18 with no restore of settings.

Could it be a driver issue?

 

[DaMacFunkin]

Could be a driver problem I had a Technomate nano OE that could never get the correct time from transponders and I had to set it to update time from the Internet periodically, I've never had the problem with vu+ boxes.