173 replies to this topic

[mattiL]

My Vu+ Duo2 running OpenPLi 6.0 from 2017-12-05 no longer keeps the correct time, it's running 8 minutes ahead.

 

I tried to find the settings for fetching time from transponder but could not find it, so then I installed the System Time plugin to allow the receiver to sync via NTP.

 

It does not seem to works as one would expect, if I manually read the time it will show a correct time, but the time in the receiver is not adjusted.

Restarted Enigma but still wrong time, rebooted, still wrong time.

 

Now the System Time plugin is set to sync every 20 minutes, but the time is still not adjusted, still 8 minutes ahead.

 

What can I do to resolve this?

 

Time to install 6.1 RC perhaps..

[janejak]

Try to turn ur box totally off and turn off the powerswish and wait for 2 min then power on and start ur box

Edited by janejak, 14 December 2017 - 19:04.

[WanWizard]

Before you do, find a good channel, select it in the channel list, press the menu button, and set the channel to your startup channel. That makes sure it starts up with the correct time.

[mattiL]

Try to turn ur box totally off and turn off the powerswish and wait for 2 min then power on and start ur box

I just did, and now the time is correct again!

Several reboots and an update did nothing, most peculiar..

 

I noticed during one restart that correct time was shown during startup, before Enigma opened up.

 

 

Thank's all for replying though!

[athoik]

It was mentioned before, unplug your receiver, let the capacitors discharge (5-10 min) and try.

Edited by athoik, 14 December 2017 - 19:28.

[SpaceRat]

The reason is idiotic logic in dvbtime.cpp

The transponder time sync code asks the transponder time but gives shit about the answer.
As soon as the time is off by more than 120 seconds, no more syncing is done.

Gesendet von meinem SM-N910F mit Tapatalk

[SpaceRat]

There is another silly check in dvbtime.cpp:

If the box already has a wrong but plausible time at start, it disables transponder time sync entirely by turning the time difference into a "fuckup factor" (of course referred to as "correction" factor inside the code).

This error has been inside E2 forever, allowing the time to slowly drift by years, but disallowing it to ever sync again.

We (I) managed to create a scenario in which this problem messes up time for non-networked boxes permanently:
In order to have other things (OpenVPN, WebDAV mounts, https in startup scripts, ...) work, the system time gets saved on shutdown and restored on boot. While it makes the time to be off by the time the box was off, it's good enough to keep the time within the validity period of certs ... but sadly also makes the "do no first transponder sync" bug in E2 kick in.

Gesendet von meinem SM-N910F mit Tapatalk

[Dimitrij]

Use this code:

eDVBLocalTimeHandler.getInstance().syncDVBTime()

Force update time for current transponder.

[SpaceRat]

Well, the question is not about possible workarounds but why this strange logic was put in place at all:

E2 trusts the transponder time enough to adjust the box' clock according to it no matter how much it differs, as long as the box has no plausible time (Based on a very silly check).
In later syncs, it does not trust the transponder time anymore and only syncs the box time with it if the difference is less than 120 seconds.

This makes absolutely no sense to me:
"I will allow you to make my time slowly drift away, but I refuse to let you correct my time if it is entirely wrong".

[WanWizard]

This mechanism was added dogs years ago (afaik in DMM days), to deal with the many dodgy transponders out there.

 

Before this mechanism, time was sycned with every transponder, causing time to fly all over the place. So a delta was introduced so transponders that are too far off are discarded (the infamous 120s). Obviiously, this only works if the time you started with is ok, which is why booting the box on a known good transponder (i.e. set a startup channel) is important, since boxes don't have an RTC.

 

Removing the delta mechanism will have the benefit of a bad time being corrected when you happen to zap to a transponder with the correct time, it will also re-introduce the problem of changing the time on dodgy transponders, causing EPG to be wrong, timers to record the wrong programs, etc.

 

Unfortunately, it is like having to choose between the pest and the cholera. 

 

It can only really be solved by having an RTC in the box (looking at you, mr. manufacturer!), or by disabling transponder syncs and using NTP (imho also a workaround, and only works if you have permanent network access).

[Erik Slagter]

This is, again, one of these issues that affects 0.1% of the users. It's not the best solution but there is no simple alternative. For those who really can't live with the idea, simply install an ntp client. All the others have no problems. Let's focus on matters that make the difference.

[SpaceRat]

I see myriads of threads "box time wrong" on the web, so this is a problem that really matters.

As long as transponders drift within the grace window of 120 sec per 15 min, the clock is allowed to drift before the Lord's birth or the end of the universe.
The 1190 seconds difference from 10 syncs aren't any better than 1190 seconds time difference in just one sync.
And I have seen that happen quite a lot, which is why I switch my boxes to NTP sync, but that's not a solution for non-networked boxes.

What I miss in dvbtime.cpp is any processing of the fuckup factor ... even if each and every transponder reports the box time to be off by days, E2 will not fix its time but instead just update the fuckup factor.

So one could as well delete the entire dvbtime.cpp and declare a clock going wrong an industry standard.

IMHO there needs to be a better algorithm.
E.g.: If the fuckup factor stays within a constant range even after changing transponders, the transponders are most probably right.

No such check is ever performed and so the "power off the box, let the capacitors unload and re-power the box" or "enable NTP sync" workarounds are all around the web.

I bet TechniSat, other decent brand boxes or even 20 EUR DIY market crap boxes have better code to handle this.

[SpaceRat]

To make the absurdity clear:
As soon as we have a fuckup factor, we could as well disable the transponder sync (As we will never sync to it again) to save CPU power.

[WanWizard]

IMHO there needs to be a better algorithm.

 

I think we can all agree to that.  

 

There have been several attempts, one uglier than the other, and none with a substantially better solution with none of the side-effects. So looking forward to a better suggestion.

[SpaceRat]

Just brainstorming:

May I assume that the main problem is transponders in local time rather than UTC?
In that case, the correction factor could be forced to be a multiple of 1800 sec (30 Min).
So if the transponder is off by 7340 seconds, we could semi-safely assume it is a local time from UTC+2 but that the 140 seconds are true drift of our clock.

[WanWizard]

Perhaps it's a good idea to add some debugging to it first, and then have people zapping past every transponder they can access, logging the timestamp and the delta.

 

So we have an idea of the problem. I hate assumptions...

[SpaceRat]

There is DEBUG code around, one just needs to define DEBUG ...

BTW: The amount of DEBUG logging in that file underlines the fact that not even the original author appeared to be happy with it and deemed it to need rework.

Edited by SpaceRat, 22 December 2017 - 14:40.

[twol]

I think you have just convinced me to change over to NTP

[WanWizard]

I think you have just convinced me to change over to NTP

 

Install the systemtime plugin if you want to do that.

[Satpal]

Correct me if I'm wrong, but hasn't there been a fix - also kind of a workaround but working well enough for me - before in Openpli where the startup transponder time from a trusted transponder defined by the startup channel was established as the correct time and wasn't subject to change after that anymore?

 

The systemtime plugin is working well enough in Openpli but there are other images that don't have it on their feeds.