Vix 5.1.006. Time wrong

[SpaceRat]

Try it, you are free to increase the count for the loop.
I tested with bad URL, but not with resolution not working at all so you might be right.
As the sync is backgrounded, higher values at least shouldn't slow down boot.

Gesendet von meinem SM-N910F mit Tapatalk

[adm]

OK, but if name resolution is failing because the network isn't up isn't there a possibility that the loop over 5 attempts will actually get run very quickly (since ping won't be running with its 4s timeout)?

Out of interest. What happens if the box isn't networked at all and is just being used as a stand alone broadcast receiver/PVR?

[birdman]

As the sync is backgrounded, higher values at least shouldn't slow down boot.

You don't seem to be following the actual bug issue.
The time sync at boot must not be done in the background!

[birdman]

Out of interest. What happens if the box isn't networked at all and is just being used as a stand alone broadcast receiver/PVR?

Then you would be using the time from the transponders (in enigma2) and, since there is no network interface to bring up then there will be no ntpdate-sync run at boot time.

[Joe_90]

You don't seem to be following the actual bug issue.
The time sync at boot must not be done in the background!

I tried your change to ntpdate-sync to foreground the ntpdate check, but it didn't seem to make any difference (but maybe I did it wrong). I decided to join this thread as SpaceRat has responded to my PM. I found that if I changed from NTP sync to Transponder sync and rebooted (after complete power down to clear all capacitors etc.) then the box came up initially with the fake-hwclock.data time, but then corrected to the transponder time. When I changed back to NTP sync and rebooted after complete power down, then the box was stuck on fake-hwclock.data time.

[birdman]

When I changed back to NTP sync and rebooted after complete power down, then the box was stuck on fake-hwclock.data time.

So your box either syncs twice or never? I can't, at the moment, see how that can happen. But if it is then there must be a way...

[birdman]

You don't seem to be following the actual bug issue.
The time sync at boot must not be done in the background!

I now have an ntpdate-sync script which runs ntpdate in the background when called from enigma2, but in the foreground if called when an interface is brought up (i.e. METHOD is set).
The former is needed to ensure that the time is set before services start (the whole point of the original change) and the latter is needed as enigma2 runs it using Console.ePopen(), and the Vix spinner pops up if that doesn't complete in <5s(?), which it usually won't.

This is it:
ntpdate-sync.zip

[Joe_90]

I'm stumped. I've changed so many different things my mind is going................
Definitely the double sync which is stepping the time into the future is an issue, but I don't know what is causing that as enigma2.sh has the call to ntpdate commented out, so it should be just ntpdate-sync which is being run and it has supposedly a check to ensure that ntpdate is not run twice.
Also, the fact that fake-hwclock.data does not get updated once it has a value into the future is another issue.

[Joe_90]

I now have an ntpdate-sync script which runs ntpdate in the background when called from enigma2, but in the foreground if called when an interface is brought up (i.e. METHOD is set).
The former is needed to ensure that the time is set before services start (the whole point of the original change) and the latter is needed as enigma2 runs it using Console.ePopen(), and the Vix spinner pops up if that doesn't complete in <5s(?), which it usually won't.

This is it:
ntpdate-sync.zip

Thanks @birdman - I'll give it a shot on my machine. Off to bed now

[birdman]

Iso it should be just ntpdate-sync which is being run and it has supposedly a check to ensure that ntpdate is not run twice.

No. It has a check to ensure it isn't being run twice at the same time, but that is only done if the /usr/bin/lockfile-create exists, which it doesn't by default on OpenVix.

Also, the fact that fake-hwclock.data does not get updated once it has a value into the future is another issue.

That's a deliberate design feature, although I forget why.
It's configurable by uncomment the line in /etc/default/fake-hwclock.

The real issue here is how it ever gets a future time set.

[abu baniaz]

The real issue here is how it ever gets a future time set.

Wasn't that answered before? Two operations.

[Ashley69]

I presume this issue is still ongoing.
I changed my time sync to ntp because of the incorrect time being shown when on transponder sync and this seemed to fix the issue.
However when my box woke from deep standby this morning it had the incorrec time. (ntp sync)
A reboot has now brought in the correct time.
I presume if I had waited (sync set to very 30 mins)30 mins it would have corrected the time.
The box is a Mutant HD51
Image 5.1.011

[Joe_90]

@birdman - I've posted twice on the other bug thread about how ntpdate is being started twice at the same time, then updates the clock with the offset twice, thus moving the time into the future. I think your presumption that ntpdate uses an absolute time is not correct. My understanding is that ntpdate (like ntpd) retrieves a timestamp from a remote server after initially taking a local timestamp, then calculates the round trip delay etc., works out a difference and either applies that to the system clock by a set or a slew. I'm assuming that in the case of the double start of ntpdate one is picking up the result of the other and applying it twice. Don't forget that my timeserver is on the LAN and the round-trip delay is only a millisecond or so.

[birdman]

I think your presumption that ntpdate uses an absolute time is not correct.

I think it sets one. Easy enough to check that, though.

I'm assuming that in the case of the double start of ntpdate one is picking up the result of the other and applying it twice.

It was the future fake_hwclock that was the issue, but I'd forgotten that you had a double advance.

Perhaps ntp should be taking its own lock when it working....given that there is nothing else to stop it being run twice on any system. It shoudln't be relying on any external mutex mechanism.

[Joe_90]

I now have an ntpdate-sync script which runs ntpdate in the background when called from enigma2, but in the foreground if called when an interface is brought up (i.e. METHOD is set).
The former is needed to ensure that the time is set before services start (the whole point of the original change) and the latter is needed as enigma2 runs it using Console.ePopen(), and the Vix spinner pops up if that doesn't complete in <5s(?), which it usually won't.

This is it:
ntpdate-sync.zip

@birdman - I installed your script change and shut the box down and pulled the power overnight. This morning I started up but ntpdate-sync is not updating my system time at all now. It appears to be running but it's not changing the system clock time which started from the fake-hwclock.data of 07.30 set last night.