Vix 5.1.006. Time wrong

[vuesolo]

OK guys updated the image successfully to 5.1.006.

Now the timer is wrong, the correct time should be 11.26 but it shows on the solo2 box 14.23

Help

 

[Ashley69]

Have you checked your time settings are correct in the menu/setup/time?

 

[Ev0]

Just move to a country where the time would be correct

 

[twol]

OK guys updated the image successfully to 5.1.006.

Now the timer is wrong, the correct time should be 11.26 but it shows on the solo2 box 14.23

Help

Are you on transponder time or NTP?? If NTP probably fixed next image update

 

[abu baniaz]

I think it is the fake hardware clock commits.

 

[vuesolo]

Hiya all seemed to have sorted itself out about 12.15pm. The time is currently now correct. Cheers

 

[bellejt]

had the same last week and needed to just choose right time zone and reboot box.

 

[abu baniaz]

Waking up from deep sleep = wrong time.
Perform an E2 restart after this, time corrects itself.

 

[SpaceRat]

E2 never syncs time if the time appears plausible (year is 2004 or later) on boot.
Either switch to NTP sync (which I would recommend after seeing the code in dvbtime.cpp) and/or wait for OpenViX to merge latest changes to dvbtime.cpp from OpenATV or OpenHDF.
During the holidays I didn't manage to create a pull for OpenViX, but the team should be able to pick it up.
The change makes E2 always try to sync with the transponder time, no matter what time/date the box has at boot.

Gesendet von meinem SM-N910F mit Tapatalk

 

[SpaceRat]

There is a pull request against branch Dev now: https://github.com/OpenViX/enigma2/pull/205

 

[abu baniaz]

Is this pull request going to fix the problems fake hardware clock has introduced?

Apart from Tm twin + Vhannibal +10e, never had a problems with transponder time.

 

[bellejt]

in first vix images we could choose to set time ourselfs.Maybe that should be re-enterred in image.
PS: did not have any problems besides the one 2 weeks ago and solution was mentioned.

 

[SpaceRat]

Is this pull request going to fix the problems fake hardware clock has introduced?

It removes the assumption that ANY time later 2004 is a correct one, so that E2 will wait for the first transponder sync again.

So yes, it should result in the old behaviour (Which wasn't good either, but I'm not capable of coming up with something better).

Gesendet von meinem SM-N910F mit Tapatalk

 

[jukkal2]

It removes the assumption that ANY time later 2004 is a correct one, so that E2 will wait for the first transponder sync again.

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..

 

[SpaceRat]

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..

I thought about that. It would easily be possible to patch in the build time at build.
But that would only be of limited use, as the image build time would be later, not to talk about last shutdown.
Additionally, systemd as well advances the system time to its build time if its 1970, so in the future we would always need to take care that the E2 build time is later than that of systemd (later) or the image.

The current patch changes, that the system time doesn't matter at all, the first sync is always performed, which equals the previous behavior.

Gesendet von meinem SM-N910F mit Tapatalk

 

[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