Vix 5.1.006. Time wrong

[SpaceRat]

perhaps doing this first on OEA 4.2 or nextp3??

Some things can not be lab tested.
It needed non-networked boxes for any problem to appear, one needs bad sat positions to understand why transponder sync doesn't really sync but only monitor (Astra and Hotbird usually deliver good times, we could throw out half of the code and still get better syncs, but then people from down under would complain as they appear to get crappy transponder times).

One question:
If everything would be as great as it gets painted sometimes, why does OpenViX switch oe-a core branches at all?
Using the perfect 4.0 branch where no changes happen anymore appears like the logical solution to me.
And why did OpenViX create a RELEASE version that bad? If the problem was that obvious, they should have noticed and waited for the fix ...

So sometimes things aren't as simple as they might appear at a first glance.
If OpenViX would do nighly builds, you would have had the stb-hwclock addition which also takes the pseudo-RTC into account, like only one or two days later.
That would have reduced the affected boxes to those that get fully powered off already.
The stb-hwclock btw worked great in tests, but on one box (AX51) it made the box get stuck at boot. How to know before someone runs it on one?
The whole concept of trying to create "golden" releases from a moving target is subject to fail. There have been enough snapshots in the past that were great for some boxes and sh$t for others.


Gesendet von meinem SM-N910F mit Tapatalk

[abu baniaz]

Whatever solution you come up with, it should cater for those who are connected to the interweb but choose to sync time using DVB.

Suggesting that if you have network, no need to use DVB is wrong approach IMO

[Sicilian]

I found a more or less all VU's not booting or extremely slow booting with release 5.1.006 due to these changes, tested with new flash. Latest dev build boots fine. I'm going to build a release build later today to cure the non booting boxes.

[SpaceRat]

I found a more or less all VU's not booting or extremely slow booting with release 5.1.006 due to these changes, tested with new flash.

fake-hwclock and stb-hwclock might add milliseconds to the boot process, not more.
fake-hwclock only reads a timestamp and sets the system time accordingly and stb-hwclock only copies the time from pseudo-RTC to the system time. Nothing time consuming.

In fact, the boxes boot up even faster, because I removed the delay waiting for the one-shot ntp-sync again which I added some time ago, reducing boot time by 5-15 seconds again.

And actually, the Vu+ boxes booted even faster than ever before, just plain wrong, for a day or so due to vuplus-platform-util failing on first boot

Just make sure to build from https://github.com/oe-alliance/oe-al...2d715a98f63604 or later.

[abu baniaz]

If a user selects NTP update/sync, are your changes going to result in the DVB time overriding this?

[SpaceRat]

If a user selects NTP update/sync, are your changes going to result in the DVB time overriding this?

The only definite answer is:
Unlikely, but if, then only once.

But:
I'm rather sure that "use transponder time=no" does work.
So I would say "no, if the box is set to use NTP, then no DVB sync should be performed at all", but as dvbtime.cpp contains a rather complicated C++ class which in turn communicates with Python code outside, I'm not entirely sure it doesn't get invoked once on startup.

[Sicilian]

fake-hwclock and stb-hwclock might add milliseconds to the boot process, not more.
fake-hwclock only reads a timestamp and sets the system time accordingly and stb-hwclock only copies the time from pseudo-RTC to the system time. Nothing time consuming.

In fact, the boxes boot up even faster, because I removed the delay waiting for the one-shot ntp-sync again which I added some time ago, reducing boot time by 5-15 seconds again.

And actually, the Vu+ boxes booted even faster than ever before, just plain wrong, for a day or so due to vuplus-platform-util failing on first boot

Just make sure to build from https://github.com/oe-alliance/oe-al...2d715a98f63604 or later.

Our release 5.1.006 was built 2 days before that commit. Building release 5.1.007 this evening.

[SpaceRat]

Our release 5.1.006 was built 2 days before that commit. Building release 5.1.007 this evening.

Then it most definitely doesn't contain this fix: https://github.com/oe-alliance/oe-al...17cfb20554668d

That means first boot always fails on Vu+ and Octagon.

You should most definitely delete the 5.1.006 build before more users install it.

[birdman]

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?

Well - all timers have the time at which they are expected to start, but:

• not all boxes provide an indication as to why they have started up (you might have pressed the power button but the next recording isn't until next week...),
• if a box has been asleep for 20 hours and is supposed to wake up 5 mins before recording time it might actually wake up 6 mins before (or, in the case of an MBTwin, ~40 mins before, as it's front-panel count-down timer runs a little fast...)

[birdman]

It needed non-networked boxes for any problem to appear,

No, it didn't.
All it needed was a box set to use Transponder time (the default setting).
Which is how mine was set and I lost all recording on Christmas Day because my box started up with the time set to when it last shutdown (about 11 hours slow).

[birdman]

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 solution to that is:

• don't run these until there is a valid system time set.
• set the system time early in the boot-up sequence (beit using NTP or querying a transponder) before enigma2 ever starts up.

[birdman]

So you can not make safe assumptions that networked once = always networked.

I wasn't. I was thinking of three settings.

• Always use NTP
• Always use transponders
• If I (now) have a network use NTP otherwise if I (now) have a transponder use that, otherwise report that no time could be set....

The last being the default setting.

[birdman]

Of course I talk about current code.

So do we. Hence this comment (by you):

You should most definitely delete the 5.1.006 build before more users install it.

indicating that the current code is broken.

[abu baniaz]

Just flashed latest Dev image. No restores. This is what I get. Screenshot taken at 06:24, receiver has network connection. Previous behaviour would have had correct date in this scenario.

[abu baniaz]

root@vusolo4k:~# date
Thu Dec 28 22:34:31 GMT 2017
root@vusolo4k:~#

Posting this so that Spacerat can see this.