Sync time from NTP

[littlejim]

I used to be able to tell OpenViX I wanted to use my local NTP server (it's in my router, I specify it by its IP address) rather than by using transponder time, and it would work perfectly.
But now I've noticed that if I do this, the time doesn't necessarily get set correctly for quite some time after booting. I haven't waited to see how long it takes, but I know a few (5 or 10) minutes doesn't seem to do it.

It took me a while to figure out what was happening, since just rebooting without going into deep standby and removing power often seems to result in OpenViX starting up with the clock approximately correct anyway, like it just remembers in RAM or in a hardware clock chip or something. Normally I don't often use deep standby and disconnect the power, which it what it seems to take to make it almost always really obvious that the clock is wrong when it starts up again.

Of course, I can use Transponder time, which I am now doing, and that works well correctly setting the time correctly within a few seconds after booting, but in the past the NTP option did seem to work well for me.

Do you think this could be a bug introduced recently?

I guess there are other possible explanations, such as a worn out battery in a backed hardware clock in the box.
But I'd kind of assumed they did bother with battery backed clocks in enigma2 boxes, since the software always has a way to get the time anyway.

Sorry this is kind of vague, and obviously it's very low priority, almost a non bug.

[birdman]

Can you post your /var/log/messages file?
It will contain reports of when ntpdate runs (and what it does).

[adm]

I used to be able to tell OpenViX I wanted to use my local NTP server (it's in my router, I specify it by its IP address) rather than by using transponder time, and it would work perfectly.
But now I've noticed that if I do this, the time doesn't necessarily get set correctly for quite some time after booting. I haven't waited to see how long it takes, but I know a few (5 or 10) minutes doesn't seem to do it.

It took me a while to figure out what was happening, since just rebooting without going into deep standby and removing power often seems to result in OpenViX starting up with the clock approximately correct anyway, like it just remembers in RAM or in a hardware clock chip or something. Normally I don't often use deep standby and disconnect the power, which it what it seems to take to make it almost always really obvious that the clock is wrong when it starts up again.

Of course, I can use Transponder time, which I am now doing, and that works well correctly setting the time correctly within a few seconds after booting, but in the past the NTP option did seem to work well for me.

Do you think this could be a bug introduced recently?

I guess there are other possible explanations, such as a worn out battery in a backed hardware clock in the box.
But I'd kind of assumed they did bother with battery backed clocks in enigma2 boxes, since the software always has a way to get the time anyway.

Sorry this is kind of vague, and obviously it's very low priority, almost a non bug.

There is no battery in your box.

Probably the problem being discussed in another thread

https://www.world-of-satellite.com/s...up-EPG-problem

Read first
https://www.world-of-satellite.com/s...oblem/page2#26

The problem appears to be that the NTP routine is being run twice at boot-up and when woken from deep-standby is using the time that the box went into deep standby as the reference time to correct (but twice rather than just the first time). Possibly not everyone sees the problem because it may relate to how fast you box boots and establishes connection with your home network. I see the problem on my box connected via wi-fi but not on my other box with a wired ethernet connection.

What I've seen on boot-up is the first (correct) time correction, then the second (erroneous) time correction and then the third (correct) transponder time correction all in the space of around a second. When this problem occurs the grid epg will be missing data for the current programs and for a period in the future.

If you didn't set transponder time and just configured NTP time then the erroneous time may not be corrected until up to a hour later as NTP runs every 30 minutes past each hour.

As birdman has requested, the /var/log/messages file will confirm what is happening on your box. (The file may only be relevant after the boot-up from deep standby and the box had been in deep standby for a hour or more)

[littlejim]

Here is /var/log/messages for starting up in NTP time mode after being in deep standby for, if I remember right, about 25 minutes.
messages (1).txt

And here, just in case it's of interest, is one from a couple of minutes later after I changed settings to use transponder time.
messages (2).txt

[Joe_90]

The first messages file shows what @adm and I have been experiencing on a box connected by wifi. Your NTP server, which would appear to be your router, is also complaining about being hammered by date/time requests. Because of the double offset stepping, your system time ended up 22 minutes ahead of real time.

May 10 22:33:28 Zgemmah7 kern.info kernel: [   21.729219] platform dvb0.0: DVB: registering adapter 0 frontend 3 (vtuner)...
May 10 22:55:39 Zgemmah7 daemon.notice ntpdate[2026]: step time server 192.168.13.1 offset +1326.008669 sec
May 10 23:17:51 Zgemmah7 daemon.notice ntpdate[2185]: step time server 192.168.13.1 offset +1326.008686 sec
May 10 23:17:52 Zgemmah7 daemon.err ntpdate[2217]: 192.168.13.1 rate limit response from server.

Your second messages file shows a similar, but opposite step backwards from a fake future time, to real time to time in the past.

All these issues are related to ntpdate running twice in very quick succession. So, the answer needs to be found as to what is causing the situation. I have found that removing the backgrounding in ntpdate-sync resolves the problem as it forces the script to wait.

[Huevos]

Thanks @Huevos, but beyond my limited skill level.

That's a bit of a get-out, LOL.

Please check "/usr/bin/ntpdate-syncsilent" is present on your file system.

[Joe_90]

That's a bit of a get-out, LOL.

Please check "/usr/bin/ntpdate-syncsilent" is present on your file system.

I think you meant to answer in the other thread? ntpdate-sync is present on my system. I've been editing it and it works fine if I remove the backgrounding. "silent" is a parameter to the script, used when it is called from the *:30 cron job.

[littlejim]

/usr/bin/ntpdate-sync is also present on my system.
Anyone know if this file part of OpenViX (which can be fixed) or is it provided by Zgemma?
Also does the box always call ntpdate using this script?

[Joe_90]

/usr/bin/ntpdate-sync is also present on my system.
Anyone know if this file part of OpenViX (which can be fixed) or is it provided by Zgemma?

It's part of OpenVix.

Also does the box always call ntpdate using this script?

I don't know. The developers are checking. There will be a solution!