[dvbtime.cpp] Unconditionally do a first sync ...

[Schimmelreiter]

... as oe-a core always has a plausible time (image build time or last shutdown/reboot), the check now < 2004 always fails and time is considered as already "synced" resp. correct.
For non-networked boxes that means they never get a correct time again.
By making the first DVB transponder time sync unconditional, non-networked boxes get a correct time again.

[AbuBaniaz]

I have merged this. Hopefully it fixes the problems that the hardware clock addiction has introduced.

Almost all 28.2/UK users did not have problems until the fake HW clock commits.

[Schimmelreiter]

It did so in tests on non-networked boxes under OpenATV (Networked ones should get a time via NTP in either case).
And no, transponder sync has never been that unproblematic as you paint it now, as the old (and also the new) code allows the system clock to drift to wherever it wants to.
A lot of reports for transponder sync not keeping the box from drifting exist for any distro, as all distros share this crappy code.

The fake-hwclock was never meant to address these, it was meant to (and does) solve other problems, like OpenVPN not successfully connecting on boot.

[IanSav]

Does this initial fetch of the time from a DVB signal ever override a time obtained via NTP? I have no problem with a reasonable initial time coming from a DVB signal but I would be concerned if this time can EVER override a NTP update.

This concern is borne out of Australian broadcasters tendency to completely muck up their time signals for up to a week either side of daylight savings transitions. While they are getting better issues do still occur. In this case any DVB based updates can provide incorrect time signals that can wreck timers. If the DVB time is only used once to prime a "reasonable" initial time for the unit if no time is currently set and it will not change the time sourced via NTP then there should be no issue. If this NTP lookup can change an NTP set time then I would ask that this be checked/changed.

[Schimmelreiter]

Yes and no.
Most definitely it will overwrite the time from the NTP sync that is performed at boot, but only if transponder sync is chosen (not 100% sure about this) and on the other hand, the NTP sync at boot ALWAYS failed until a few days ago.

So basically:
Nothing inside E2 should have changed in comparison to before.

[AbuBaniaz]

Well, there is something weird going on.

Before the fake hw clock changes, time was always correct for most people. After it, fake time was wrong and always stayed wrong, unless you do a GUI restart. People lost recordings even though they never had an issue with time from transponder before.

With this commit, fake time is wrong but gets corrected afterwards. I hope more people do not get inconvenienced before a more robust solution is found.

Why do we need the fake hw clock? Surely you could have added a time sync command to E2 startup like we have had for months?