Vix 5.1.006. Time wrong

[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

 

[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-alliance-core/commit/5bade215ef650fe2080ea626ad2d715a98f63604 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-alliance-core/commit/5bade215ef650fe2080ea626ad2d715a98f63604 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-alliance-core/commit/14752b0de72bb3a7d3cbff186617cfb20554668d

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