Vix 5.1.006. Time wrong

[birdman]

If (when) NTP sync failed, then the boot process fell back to transponder t-sync,

The boot process never queries any transponder. The enigma2 start-up does, if you have it configured to use transponder time rather than NTP.

Since the changes in December, there is always a plausible date/time stored and I think that is used if you have "sync by NTP" set and it fails. There is no fallback to transponder time in this case.

There was never fallback, and there isn't now. Although it is possible that it uses transponder time until it gets a time > 01 Jan 2004...(there are no comments in the code to explain any of its logic).
What has changed is that because fake-hwclock has set the time to something after 01 Jan 2004 the code thinks that it can start processing things that use the current time.

Using a stored clock time to be used during boot buys us nothing except getting rid of the 1/1/1970 log filenames.

That is not why it was put in place. The reason for it was to have a roughly-valid clock set for certificate validity checking.
However, since the only use for a certificate is related to network services it should always be possible to set the time accurately using NTP before the services start.

 

[abu baniaz]

However, since the only use for a certificate is related to network services it should always be possible to set the time accurately using NTP before the services start.

That would be the final fix.

Well done on the effort gone into analysing this issue.

 

[birdman]

That would be the final fix.

Except that the code is in OE not ViX enimga2 and SpaceRat probably disagrees.

 

[birdman]

... and I have another issue with fake-hwclock.

I have a PowerTimer set which puts the box in deep standby after 60 mins in standby.....

The issue there is really that enigma2 should be able to use relative timers as well as absolute ones.
A recurring PowerTimer needs to run 30mins from now even if the internal clock changes.
A RecordingTimer needs to start at the absolute time of the recording.

 

[Joe_90]

... Although it is possible that it uses transponder time until it gets a time > 01 Jan 2004...(there are no comments in the code to explain any of its logic).
What has changed is that because fake-hwclock has set the time to something after 01 Jan 2004 the code thinks that it can start processing things that use the current time.

That's exactly what I'm saying - the date is now plausible, whereas before the date was 1/1/70 and therefore implausible so there were "workarounds" in enigma code to get a date/time from the transponder even if "time by NTP" was set in the Time menu. I know the rough date is there for certificate validity checking, but what percentage of users have certificates needing to be checked?

The recurring PowerTimer code is triggering the system shutdown because it seems to be operating on the stored time rather than on the relative time and if there is a slight delay in the correct time being applied it doesn't seem to be aware of it.

 

[ccs]

I know it's 2 months away, but is now a good time to mention clocks going forward/back ?

 

[birdman]

I know it's 2 months away, but is now a good time to mention clocks going forward/back ?

Doesn't happen on a Linux system. The clock stays the same (always increments at 1s per second). - the display of its value changes.

(You can make MS Windows do the same - extremely useful on a dual-boot system).

 

[birdman]

That's exactly what I'm saying - the date is now plausible, whereas before the date was 1/1/70 and therefore implausible so there were "workarounds" in enigma code to get a date/time from the transponder even if "time by NTP" was set in the Time menu.

That functionality can (probably) be restored by getting the enigma2 code to check fort the [FONT=courier\ new]/tmp/timeset_done[/FONT] file (or whatever I called it) rather than testing for 01/01/2004, and by getting the first transponder time setting to create it if necessary.

 

[Joe_90]

I have the situation this morning where the box has not succeeded in getting a current time from NTP at all - even after 30 and 60 minutes have elapsed. I'll peruse the logs and see what I can see... In the meantime I think I'll set the FORCE parameter in fake-hwclock for the moment. This will cause enigma to revert to transponder time if NTP time ain't working.

 

[birdman]

I have the situation this morning where the box has not succeeded in getting a current time from NTP at all - even after 30 and 60 minutes have elapsed. I'll peruse the logs and see what I can see... In the meantime I think I'll set the FORCE parameter in fake-hwclock for the moment. This will cause enigma to revert to transponder time if NTP time ain't working.

Or just rename the fake-hwclock script...
And check that the /etc/default/ntpdate file has the correct setting - I ended up with it having an incorrect value yesterday - now fixed, but won't have reached any image yet....

 

[Joe_90]

Or just rename the fake-hwclock script...
And check that the /etc/default/ntpdate file has the correct setting - I ended up with it having an incorrect value yesterday - now fixed, but won't have reached any image yet....

Which script?

./bin/fake-hwclock
./etc/init.d/fake-hwclock
./etc/default/fake-hwclock

/etc/default/ntpdate contents are ok.

 

[birdman]

Which script?

The init.d one. That will stop it being run at start-up/shut-down, as it won't be found.

 

[birdman]

I now have an ntpdate-sync script that can be run from ifup (so no need for the extra init.d script) that will keep going in the background (waiting up to 60s between tries) until the time has been set.

I'm now trying to figure out how to get the dvbtime.cpp code to use transponder time if the config value is set to use NTP but NTP hasn't yet succeeded (ISP network connexion down...). There is then the issue of, in this case, of whether to mark the time sat "set" (so from now on it stops using the transponder time) or to leave it not marked....

 

[ccs]

Sorry to butt in again, if I'm using transponder time (I only ever have), and the transponder happens to be unavailable at boot up, does the time get picked up as soon as it becomes available again?

 

[birdman]

Sorry to butt in again, if I'm using transponder time (I only ever have), and the transponder happens to be unavailable at boot up, does the time get picked up as soon as it becomes available again?

Yes - it will continue to use the transponder if that is what you have configured. (The system boot will also have tried to use NTP to set a time...).

This whole area seems to be a minefield...

The low level code won't let you switch to using NTP if you don't have a reasonable time set - it will continue to use the transponder. This gets called very early (by mytest,py) to set your actual config setting. So if you don't actually have any transponders (an IPTV receiver?) and your network was slow/unavailable at boot time (so NTP hasn't yet set a time) then you won't actually get enigma2 to use NTP (even though it is what you have set!) as the call to set it only happens once and that failed.....
At least that is what would have happened before fake-hwclock came along, but since that sets a reasonable time then the switch to NTP will happen. BUT if NTP hasn't actually yet set the clock you don't want to start the timers (or EPG cacheing?)...
I suspect there are other broken scenarios.

 

[twol]

Well, if its any encouragement (?), although OpenPli is very fast normally for most things, when I flash an image, it takes about 15 seconds (after settings are restored and reboot) at least to settle on a time (currently on Transponder and 1st channel is BBC1 HD)
... it sits there on the year dot ... for a long time...... never had that with ViX (before hwclock or after)

 

[birdman]

The issue is less about getting the time set and more about ensuring that it if isn't set:

1. it keeps trying to set the time using a method that can work,
2. once the time is set that it keeps trying to check the time in the configured way, if that is possible,
3. until the time is set it doesn't run any Recording or Power timers.

I'm not sure that any of these is actually guaranteed in ViX.

 

[twol]

Well, I know it is an issue with Fat-Tony, but I don‘t have an issue and I am still flashing new images fairly frequently on NTP time.-........ so don’t get carried away with (perhaps) one particular issue.
As mentioned I get faster time setting in ViX than Pli.

 

[birdman]

Well, I know it is an issue with Fat-Tony, but I don‘t have an issue and I am still flashing new images fairly frequently on NTP time.-........ so don’t get carried away with (perhaps) one particular issue.
As mentioned I get faster time setting in ViX than Pli.

I've started so I'd like to finish....
If necessary I'll come up with a compromise and think about the loose ends later.

 

[Joe_90]

That's just it - I haven't had a single issue with my GB Quad+ which uses NTP (but is hardwired to the LAN). I've disabled the fake-hwclock script for now on the HD51 (but kept NTP sync) and I'll see how I get on with a standard Release build for a number of days. I'm now back on a clean build but without the hwclock script. Without a plausible time being available, maybe the fallback mechanism (to transponder time) will overcome any slowness in the wifi network. I'll monitor closely. Thanks to @birdman for all the work so far:thumbsup: ...and I will test any further updates to the code.