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