Vix 5.1.006. Time wrong

[birdman]

Hmm.. "any time later than 2004"? Now it is 2017, and soon 2018.
I think no time before the compile time of the build in use should be considered sane, there probably is a way to check that..

No! That won't help at all.
The clock will get set to the time of the last shutdown at start-up (by fake-hwclock). So it may be a few hours slow - and will never get corrected if you are using Transponder time (which is the default)... That is the problem!

[abu baniaz]

I've built an image with the commit. Leave receiver in deep sleep for a while, time will be wrong when you wake it up. It then corrects itself. I'm guessing other processes will get messed up. I've not checkec datestamp on debug logs.

Without the fake clock changes, almost all users did not have a problem.

I hope you can quickly resolve the problem you have brought to the fore.

[Sicilian]

I've built an image with the commit. Leave receiver in deep sleep for a while, time will be wrong when you wake it up. It then corrects itself. I'm guessing other processes will get messed up. I've not checkec datestamp on debug logs.

Without the fake clock changes, almost all users did not have a problem.

I hope you can quickly resolve the problem you have brought to the fore.

What happens to deep standby timers? Are these now broken too?

[ccs]

I'd have thought that waking up from deep standby for a timer was a good clue what the date and time nearly is (it'll be in timers.xml), and any other source can be treated with caution.

[SpaceRat]

No! That won't help at all.
The clock will get set to the time of the last shutdown at start-up (by fake-hwclock). So it may be a few hours slow - and will never get corrected if you are using Transponder time (which is the default)... That is the problem!

Nope:
It will get set to a image boot time early on first boot or to last shutdown on every consequent boot.
Usually that time is good enough for cert based OpenVPN connections, HTTPS, ... to work, that previously failed with "certificate not valid yet".

Later during boot, the time from the front panel pseudo-RTC gets restored (if the box has one) and slightly later an NTP one shot is performed (it was always performed, but previously always failed due to happening too quickly after ifup, now it will wait some seconds in background and then perform the NTP update).

And to make sure also boxes without network get a time, the first transponder sync is always performed and no longer skipped if the time "looks" ok but isn't.

For a starting point, this is near perfect. The only problem remaining already existed before: Transponder sync was never allowed to make bigger adjustments after the first sync and still isn't.
So if you start on a bad transponder or your box clock drifts away, transponder sync will not fix it (and never did).

Gesendet von meinem SM-N910F mit Tapatalk

[birdman]

And to make sure also boxes without network get a time, the first transponder sync is always performed and no longer skipped if the time "looks" ok but isn't.

It is with the latest commit to dvbtime.cpp. But it wasn't before, and that is what was causing all of the problems for those using the default setting of using Transponder time.

[birdman]

What happens to deep standby timers? Are these now broken too?

They don't work the same way. They are countdown timers set as the box shuts down (they have to be, as if they were RTC timers then the boxes would all have RTCs, which they don't). They are also nothing to do with Enigma2 - they are implemented by the hardware.

[birdman]

I'd have thought that waking up from deep standby for a timer was a good clue what the date and time nearly is (it'll be in timers.xml), and any other source can be treated with caution.

The wakeup isn't done by the actual wall clock time. It's done by waiting a certain time after shutdown.
When boxes wake-up most of them have no ides at all what the time is.

[SpaceRat]

Of course I talk about current code.

We can also discuss the past, but don't mention the war.

You started it.
No, I didn't.
Yes, you did.
No, I didn't.
Yes, you did.
No, we didn't.
Yes, you did, you invaded Poland.

Btw: That parrot isn't dead, he's just taking a nap.

Gesendet von meinem SM-N910F mit Tapatalk

[birdman]

The only problem remaining already existed before:

Well, it might be worth making the default setting NTP time for any box that has a working Internet connexion.

[ccs]

The wakeup isn't done by the actual wall clock time. It's done by waiting a certain time after shutdown.
When boxes wake-up most of them have no ides at all what the time is.

I know, but when the box wakes up after a specified period, doesn't the first timer in timers.xml have the exact time and date when it is expected to start?

[twol]

Of course I talk about current code.

We can also discuss the past, but don't mention the war.

You started it.
No, I didn't.
Yes, you did.
No, I didn't.
Yes, you did.
No, we didn't.
Yes, you did, you invaded Poland.

Btw: That parrot isn't dead, he's just taking a nap.

Gesendet von meinem SM-N910F mit Tapatalk

You are correct, history is history but we should learn from it ..... like perhaps doing this first on OEA 4.2 or nextp3??

[SpaceRat]

They don't work the same way. They are countdown timers set as the box shuts down (they have to be, as if they were RTC timers then the boxes would all have RTCs, which they don't). They are also nothing to do with Enigma2 - they are implemented by the hardware.

Most boxes DO have a pseudo-RTC in their front panel. Unlike a real RTC, they are not battery backed-up and only continue to keep the time as long as the box is powered.

So the situation was as follows:
A box rebooting or waking up from deep standby has no valid system time (1970-01-01 0:00 UTC), but a hopefully correct time in its pseudo-RTC.
E2 restored pseudo-RTC time as system time and then checked "current time (from pseudo-RTC) < 2004"? No -> DON'T really do transponder syncs AT ALL.

A box starting up from power off has ZERO idea about the time, it's 1970-01-01 0:00 UTC (plus current uptime) for them. The unbuffered pseudo-RTC has no time either, so time remains in 1970.
E2 then checked "1970 < 2004"? Yes -> Do ONE transponder sync.


The known problems were:
Time can drift away, as later transponder syncs have no effect. Only powering off and restarting from off could solve this, as this was the only condition under which a sync was really done.
This was/is a quite frequent problem as the clock chips in boxes don't appear to be very accurate.

An E2 box had absolutely no decent time during startup of the core OS (yocto Linux), making cert based things like OpenVPN fail at boot time.

The fake-hwclock addressed the second problem, but also made the quirk "now < 2004" Yes: Sync once; no: never sync fail.


Gesendet von meinem SM-N910F mit Tapatalk

[abu baniaz]

Well, it might be worth making the default setting NTP time for any box that has a working Internet connexion.

We have this. It worked until it got broken by current batch of fixes. Hopefully it will get fixed

[SpaceRat]

Well, it might be worth making the default setting NTP time for any box that has a working Internet connexion.

Thought about that but thrown away the thought:
How to reliably make such an assumption?

It is possible that a box that is going to run w/o network still gets in touch with a network from now to then.
It's especially very likely that a box gets set up networked (to perform couch flash, install plugins, ...) and only gets moved to its non-networked location later.
Or a box normally running network-less gets attached to a network to get its hard disk filled with media from time to time.
Somebody mentioned his box in his caravan. .. although I would have an UMTS/LTE router in mine

So you can not make safe assumptions that networked once = always networked.
One could only add "NTP first", which would try NTP and fall back to transponder sync if NTP fails. But: After how many fails over which time period?

Gesendet von meinem SM-N910F mit Tapatalk