173 replies to this topic

[SpaceRat]

The "roughly valid time" feature is something Spacerat implemented in OpenATV, which doesn't fix anything, it is a dirty workaround that replaces one problem with another one.

So given the fact that the box boots with epoch time, how do you suggest it will find and set the correct time, and keeps the time correct during operation. And very important: how to determine what is "correct"?

Actually it's a bit more complex:
I have seen myself and got reports of things failing at boot due to the lack of a proper time.
And the fake-hwclock script is just a slightly more Debian/Raspbian variant of the save-rtc script that is by default part of yocto and which gets removed/invalidated by some bbappend.
So actually I haven't added a workaround, I removed one.

The second quoted part contains the relevant point: How to determine what's correct?
You can't, but the dvbtime.cpp code contains (or rather contained) a wild assumption, which is simply invalid in multiple scenarios.

The quirky dvbtime.cpp code is the problem.
You will notice if OpenPLi really ever does systemd builds, as systemd advances the time to build time if it currently is 1970.
And the current code "relies" on some bug in yocto that makes the one-shot NTP sync on ifup fail.

Normally I would expect OpenPLi to be more into real solutions than workarounds.
Personally I prefer clean solutions. And crippling the base OS in multiple ways just to keep some silly assumption valid is definitely NOT clean.

Gesendet von meinem SM-N910F mit Tapatalk

[WanWizard]

Ah, wait, you're not talking about the enigma mechanism. Didn't get that at all. I wasn't even aware that yocto also introduced something vague (although I'm not suprised ). 

 

The quirky dvbtime.cpp code is NOT the problem. It is just there are a precaution, to guard against rediculous drift of time. You do need something like this, as you know there are transponders out there with an incorrect clock.

 

The code BECOMES a problem if the box doesn't have the right time to begin with. So the root cause is the lack of a correct start time. And that is the problem that needs to be addressed.

 

The current solution is:

- make sure you boot on a known good transponder

- use an NTP client solution

 

If there is a better solution, I sure like to know.

 

A derived discussion may be that assuming you have the correct time, why would you accept any deviation at all in dvbtime.cpp? Or even, why would you want to set the time again all the time, because the one you have is good?

 

I can only guess that cheap hardware can cause a drift if the box is on long enough (you can see that if you sync with ntp at regular intervals), and this code has been designed to allow for small time corrections (although one has to wonder how long a box should be in standby for to get a 120s drift).

[birdman]

The quirky dvbtime.cpp code is NOT the problem.

Yes it is!!!!

As it isn't documented anywhere as to what it does and that it is a requirement that anything that sets a system time at boot up must set an accurate system time, as setting a vague approximation is likely to result in you never having the correct system time - ever again.

 

So fake-hwclock was added (so that ssl certificates had an approximate time to work with?) and, as a result, it totally screwed the system time on any system using transponder time.

Edited by birdman, 27 December 2017 - 03:06.

[Rob van der Does]

You might not be connected to a network....you will be connected to a transponder.

Nope; when travelling around with my caravan I sometimes have neither a dish nor a network. Although (correct) time in that case (using the box as mediaplayer) is not an essential thing, it's still annoying/misleading to see a complete wrong date/time.

[littlesat]

Here just my 2 cents...

 

I would go for this in pseudo code...

 

Try NTP server time, when this is not successful use transponder time

 

When the box cannot connect to the internet then the user could improve the procedure by themselves by select a service that selects a good transponder at bootup.

 

you can already get this by installing that special time plugin (which I think should be included by default in a more nicer structured way).

 

BUT.....

 

Also as far I understood another change should be made in E2. When the time drifted and NTP does re-synchronise something can go 'badly wrong' at this moment. As far I can see E2 cannot adjust the time to systemtime in the correct way (think about the delays etc)....

Edited by littlesat, 27 December 2017 - 09:24.

[littlesat]

It's still annoying/misleading to see a complete wrong date/time.

It could be considered the UI does not show 1 January 2017 12:00:00... but -- --- ---- --:--:-- instead....

[Erik Slagter]

I am not a huge fan of yet another device in my house that's constantly spraying ntp packets to the internet.

[Pr2]

Hi,

 

NTP is not constantly spraying packet, it get the time from internet and set it on the device, then if you have some doubts, you set it up to go on a recurrent base check the time on the Internet.

So if you are confident on your box internal clock it will only get one request toward the internet NTP servers and then became silent.

 

By default, system time plugin only get NTP from internet once.

 

I also think that it would be better to implement NTP properly by default in OpenPLi image.

 

Pr2

[littlesat]

I am not a huge fan of yet another device in my house that's constantly spraying ntp packets to the internet.

 

Explain....

 

i think synchronizing more than once per 24 hours is sufficient... But still to do it right we need to add changes in the E2 binary cpp code as far I know... 

Edited by littlesat, 27 December 2017 - 11:53.

[Eragon]

I'm not a coding expert so please forgive me if now I'm saying something wrong or not possible to do.

 

I followed this thread and it looks like a box time setting error might occur if at startup the first tuned transponder has a wrong time value.

 

So I'm wondering if to solve this possible issue at startup the box could always briefly tune the satellite's default transponder before accessing the last tuned transponder or the transponder selected in settings for the box startup.

 

AFAIK in this way the time value of the satellite's default transponder should always be correct and then the box could get a valid date/time value.

[WanWizard]

 

The quirky dvbtime.cpp code is NOT the problem.

Yes it is!!!!

As it isn't documented anywhere as to what it does and that it is a requirement that anything that sets a system time at boot up must set an accurate system time, as setting a vague approximation is likely to result in you never having the correct system time - ever again.

 

So fake-hwclock was added (so that ssl certificates had an approximate time to work with?) and, as a result, it totally screwed the system time on any system using transponder time.

 

You need to read. This is only a problem if the incorrect time has been set before.

 

There are two issues that need to be solved:

1. How does the box aquire the correct time on cold boot
2. How does the box maintain the correct time, given the absence of an RTC and the inaccurancy of the hardware clock?

If 1 has been dealt with by setting a known good startup channel or by using an ntp client, the infamous 120s will will take of 2. Therefore 2 isn't the root cause of the problem, 1 is.

Edited by WanWizard, 27 December 2017 - 12:12.

[SpaceRat]

Hi,

NTP is not constantly spraying packet, it get the time from internet and set it on the device, then if you have some doubts, you set it up to go on a recurrent base check the time on the Internet.

Furthermore, any decent SOHO router can act as an NTP server (and client) at the same time, also announcing itself as such via DHCP.
So the router grabs a time via NTP from external servers and clients on the LAN can grab theirs from the router.

Gesendet von meinem SM-N910F mit Tapatalk

[Erik Slagter]

I am not a huge fan of yet another device in my house that's constantly spraying ntp packets to the internet.

Explain.... i think synchronizing more than once per 24 hours is sufficient... But still to do it right we need to add changes in the E2 binary cpp code as far I know...

If you say this, you need to get familiar with how NTP works first.

Edited by Erik Slagter, 27 December 2017 - 12:19.

[littlesat]

if you say this, you need to get familiar with how NTP works first.

I'm aware how it works.... but you can limit the 'spray'....

And here my router also 'behaves' like a ntp server... 

Edited by littlesat, 27 December 2017 - 12:23.

[Erik Slagter]

Most devices will not honour a local ntp server handed via DHCP.

 

So if we're going to make this default, at least a construct should be made that fetches the local ntp server from the DHCP lease instead of spraying (yes!) the internet.

 

How do you think NTP makes the clock sync after the initial burst?

Edited by Erik Slagter, 27 December 2017 - 12:48.

[birdman]

There are two issues that need to be solved:

1. How does the box aquire the correct time on cold boot
2. How does the box maintain the correct time, given the absence of an RTC and the inaccurancy of the hardware clock?

If 1 has been dealt with by setting a known good startup channel or by using an ntp client, the infamous 120s will will take of 2. Therefore 2 isn't the root cause of the problem, 1 is.

 

A further issue is getting the time set correctly as part of the (early) boot process rather than waiting for enigma2 to set it after everything has actually started up.

[fcs001fcs]

My recent experience today on 2 DM7020HDs (OpenPli 4) and a VU+ Zero (OpenPli 6):

 

I noticed that a few recorded programs had the ending cut-off. This happened a month or so ago also.

 

The transponder time was off approx. 3 minutes ahead to the correct time on all 3 STBs. On all 3 STBs I have Sky News on 28E set as the startup channel.

 

I downloaded the plugin via GUI for system-time and did a soft reboot. It would not adjust the time to the correct NTP server time (3 mins back). On query, the transponder time in the plugin reported back the incorrect time (3 mins ahead). GUI restart or soft reboot did not change the situation. I also tried manual change but  no change was taken. This System-Time Plugin did not adjust the time in any way I could see on the DM7020HD.

 

I did a hard reboot (power switch) and the DM7020HD sync'd to the correct time in the Sky News channel on start-up. I did the same hard reboot for the other 2 STBs and they were also fixed for correct time.

 

I have no idea why the original 3 minute error happened but it has happen in the past but I never investigated as I did today.

 

What ever the solution the Devs decide on concerning system-time, kindly have a detailed look at the plugin as it did not work for me with the 3 min time error.

Edited by fcs001fcs, 27 December 2017 - 13:43.

[WanWizard]

If you've followed this thread, you'll know that the plugin didn't work (nothing works any more at that point) because of the infamous 120s delta in dvbtime.cpp, which rejected your 180s correction.

 

You absolutely need the correct time at cold boot, a normal reboot keeps the box under power, so the hardware clock keeps on running. You really need to switch it off, wait until the capacitors in the power supply are drained (so the hardware clock is dead), and switch it on again.

 

The reason it can be 180s off was described by @Spacerat, the 120s delta still allows the clock to drift, as long as it happens with increments within that delta.

 

So two issues need to be adressed:

- getting the correct time at cold boot

- keeping the time correct once you've got it

[fcs001fcs]

Sorry I missed the plugin not working. I did scan the thread but must have overlooked that fact.

 

Maybe the System-Time Plugin should be removed from the plugin list if it is not working at all.

[Dimitrij]

 

 

Maybe the System-Time Plugin should be removed from the plugin list if it is not working at all.

In telnet:

/usr/sbin/ntpdate -s -u pool.ntp.org