173 replies to this topic

[WanWizard]

No, please read the entire thread.

 

As SpaceRat already mentioned, once your time is off for more than 120s, any corrections outside that range are rejected, and includes setting the time correctly if you are 3min off.

 

Also, if you are using Oscam, it will prevent any time corrections.

[fcs001fcs]

No, please read the entire thread.

 

As SpaceRat already mentioned, once your time is off for more than 120s, any corrections outside that range are rejected, and includes setting the time correctly if you are 3min off.

 

Also, if you are using Oscam, it will prevent any time corrections.

 

I have read through the recent posts but have to admit I am confused as to what the problem actually is and all the suggestions to correct it that it seems may or may not work.

 

I am using OSCAM, so from your statement above, all I can do is a power off/on to correct the time.

 

My understanding is that the time is set at power-up (Sky News 28E) and when I power-up the time is set correctly. Also, once set to the correct transponder time, and kept powered up, the time cannot be reset/adjusted. How then a few days later does it skip to 3 mins lag if, from what I read here, it cannot be corrected after power-up due to OSCAM?

 

I really do not have the detailed knowledge to help fix the issue and appreciated all the discussions that hopefully will fix the issue I have and for other users like me.

 

As I mentioned earlier, this is a relatively new problem for me on my STBs.

[WanWizard]

Currently the only solutions are:

- find a known good transponder, pick a channel from it, and set that als your startup channel. I use BBC One HD on 28.2. 

- Set the box to deep standby, and switch it off

- Get a coffee to make sure the capacitors in the power supply are empty and the clock no longer runs

- Switch the box back on

 

or

 

- install the Systemtime plugin, set it to use internet time, have it sync on bootup (and set a delay if needed if you use a wifi adapter to allow for the connection time). It will use ntpdate before Oscam starts.

 

This will get you the correct time. 

 

The problem is that the code:

- checks and syncs the clock on every zap

- allows for a 120s drift of the clock

 

And this still makes that you can have a clock that's off after zapping a few times over a bad transponder. But as long as you zap regularly to a good transponder, your time will be corrected again, thanks to that same 120s window.

 

The problem has been made worse with the recent Oscam, which blocks this mechanism, meaning that once the time is off, it stays off, no matter what you do. You can start NTP, use the "date" command on the commandline, Oscam will block the change and reset it back to the wrong time.

 

After we've got 6.1-release out, we're going to look into this issue, beginning with compiling Oscam without this time anti-correction logic.

Edited by WanWizard, 6 January 2018 - 02:18.

[Persian Prince]

I think you mean this:https://github.com/o...cd70861267b50ce

[littlesat]

I think so.... instead of Clockfix it better could be called clockdestoyer...

Edited by littlesat, 6 January 2018 - 07:58.

[Pr2]

...

Some transponders are consciously tinkering with the timesignal to frustrate cardsharing but as usual watching legitimately with a card in reader of your opensource box is affected too.
 
To "fix" the time:
 
Kill oscam, fix your time and start it again.
 
Or just use whatever you want to fix your time correctly and use a non clockfix enabled oscam binary but dont complain about non working ratelimiters, black picture, bad cw cache, disconnected clients and more reported issues I already have forgotten about.
 
...

Hi,

I just quote what TheParasol wrote when mentioning that this problem come from OScam.
If this was implemented in OScam there are reasons for it (see quoted answer).

Moreover, as already mentioned by many, this is just a compilation flag that can be turned off.
So why not provide, right now, in the feed an OScam-noclockfix, so people experiencing this "bug" can install this OScam version and give a try.

 

So you can no longer says that the time broadcasted on DVB is the right one, so still using it as default is a mistake.  You think of starting to find a reference TP for every possible satellite to adjust time at start up.

It seems to me that OpenPLi should take the decision to install systemtime NTP as default time mechanism because I wonder how many users are not connecting there STB on a network without any outgoing access to the Internet?

- People that want to use the XMLTV EPG needs Internet access

- People that use IPTV needs Internet access

- ...

 

More and more devices are connected to the Internet now, so willing to keep a non Internet "simple" solution is quite strange, knowing that DVB time is no longer reliable.

 

Isn't it possible to cascade the time decision:

 

NTP  if Ethernet direct get time ,  if WLAN delay it slightly to let time to WLAN to connect

if not available DVB

if not available prompt user to manually enter time.

Pr2

[WanWizard]

As said, we'll look into it once 6.1-release is out the door. We only have a limited set of hands, we can't do everything at once.

[Persian Prince]

Well 6.1 stable is out

[Erik Slagter]

Technically only in a few hours. The general feeds are generated at the end of the build process. Without them your flashed image will be quite useless or source of install errors. So better wait.

[SpaceRat]

In my situation, with a 3 min lag between the DM7020HD with OpenPli 4 and correct time, how do I setup a NTP update that will actually correct the time on the DM7020HD?
 
 
BTW this is a recent issue as for many months/year I never had a time synchronisation issue with any of my STBs and their overnight recordings. I would say it changed during the last 3 months or so.

I would say: Impossible.
You are talking about OpenPLi 4, which is EOLed.

So actually you are just confirming that this problem has always existed.

Note: The problem to exist doesn't necessarily mean it has to occur always and for everybody (Which is what sometimes makes it somewhat hard to understand for some why it needs to get fixed anyways).
Reports of STB clocks being minutes or even hours ahead/behind (But mostly ahead) exist for years. If or how often it happens for a single user highly depends on a lot of circumstances like
- the stations (and thus transponders) used
- how often the box gets fully powered off
- how often the box gets restarted
- which softcam (and which version of it) gets used
- network configuration (There is only a very specific configuration for which the one-shot-NTP-sync at boot worked)
- ...

I am using OSCAM, so from your statement above, all I can do is a power off/on to correct the time.

Yes.

 

My understanding is that the time is set at power-up (Sky News 28E) and when I power-up the time is set correctly. Also, once set to the correct transponder time, and kept powered up, the time cannot be reset/adjusted. How then a few days later does it skip to 3 mins lag if, from what I read here, it cannot be corrected after power-up due to OSCAM?

You have to understand that every method to measure something also has certain faults, so that people invented ways to compensate them.
Roughly said: oscam does not prevent the fault, it only invalidates the compensation.

To make it somewhat more simple to understand (At least for people old enough to remember conventional wristwatches):
At time A you adjusted your wristwatch, usually according to a so-called "master clock" (Historically found at train stations, airports, ...).
In Germany, one would usually pick a clock which has the "TeleNorma" brand on it (TeleNorma = "Telefon und Normalzeit" = "Telephone and master time").

Without touching the adjustments again (Equalling oscam's CLOCKFIX mode), you then compare your wristwatch's time with a master clock again at time B (Several days/weeks/months later, depending on if the watch is Chinese or Swiss/Saxonian Made ) and notice a more or less big time disparity.
How can this be as you didn't change the watch's time?

Well, time can not be measured at all, only the "effects of time".
A wristwatch only counts moves of mechanical parts ("Unruh", "balance-wheel") or the disintegration of a quar(t)z.
Even if the wristwatch might be designed for X movements of the balance-wheel or X% of disintegration per second, might actually do X+/-Y movements/percent of disintegration per second, so it will not move exactly 1 second per real second, but let's say 0.95 or 1.05 shown seconds per real second.

So from time to time it needs re-adjustment.

The very same still applies to modern computers and thus also your STB:
The computer simply counts "ticks" since it was started. Consequently writing a tool to check the Windows uptime involves invoking the "GetTickCount" function, not a "GetUpTime" function!

Supposed result:
"The return value is the number of milliseconds that have elapsed since the system was started."

No matter what, at some level of the hardware that performs the counting we will end up with it actually just being a counter for swings of a resonant circuit or disintegration of a quar(t)z too.
21st century or not, the TickCount suffers from the same inherent inaccuracies as the wristwatch.

oscam's CLOCKFIX can do nothing about this inherent tick inaccuracy (it can't or it would need to hold on time at all), just like any other program it will live with the fact that 1000 ticks are only close but not 100% equal to 1000ms.
Let's claim that your tick counter actually does 1000.05 ticks per second.
That changes "nothing" for timings, but still: Your clock will go 60003 ticks per minute, 3600180 ticks per hour, 86404320 ticks per day. So per day, it will have advanced additional 4.32 seconds.

This is still no problem, as that's what NTP (or DVB) syncs are for: To get the system clock back in sync. For the example above, E2 will simply adjust the clock back by 1 sec about every 6 hrs and we are all fine ...
.. but wait, here is where oscam's CLOCKFIX steps in and forwards the system clock by 1 sec again instantly to prevent the time from going backwards.

So oscam does not prevent the addition (the real fault) of 4.32 seconds per day (in this example), but only the correction of them.

And now imagine your clock does 1000.5 or even 1001 ticks per second ... at 1000.5 ticks per second, after only 3days E2 would even give up adjusting the time at all, as the disparity now exceeds 120sec (3x43.2 seconds)!

In the end it doesn't matter at how many ticks per second your counter ("system clock") really runs, as long as it is slightly above 1000.00000000000000000000000000000000000000000000000000000000000000 ticks/sec it will be ahead by 1sec, 2sec, ... sooner or later.

And now the reason why NTP worked better:
Even if NTP sees your system time being ahead it won't turn back time, it will only change the speed at which it continues to advance!
It calculcates a correction factor which will slightly overcompensate the existing disparity, so if your counter normally does 1000.05 ticks/second, it might modify it to do 999.92 ticks/second.
-0.05 ticks to compensate the already summed up drift over a specific time and additional -0.03 ticks to compensate future drift.
After multiple syncs, the clock will then go at a rate much closer to 1000 ticks/sec.
As the clock still continues to advance only, oscam doesn't prevent this (even with CLOCKFIX enabled!).

That's what I've added to E2 too, but for OpenPLi it will only be in 6.1 or even 6.2 and not inside your ancient OpenPLi 4.0:
The E2 DVB-sync will now also use the mechanism described above and called "slewing".
E2 will then only slow down or speed up the counter driving the system time, as long as the disparity is within a time period that can be slewed inside a foreseeable future resp. is irrelevant enough.
Time will no longer be set back by 1, 2 or 14 seconds, which would drive oscam mad, but only move on ... slower if necessary, but still forward.

The ultra-short version:
oscam's CLOCKFIX means nothing else but "forward ever, backward never" and allows forward corrections as well as forward faults/drift.
As slewing turns backward corrections into slower advancing of the clock, it should work even for oscam's with CLOCKFIX.

The reasons why CLOCKFIX should be disabled anyways are:

• It's much more unlikely that it will ever step in under normal circumstances
• If the system clock is that much ahead that it would need to be stepped back rather than slewed, it's most probably for a reason.
  In such a case it's probably much better to lose 1 second of a recording due to decryption problems than to make the whole recording useless due to missed beginnings or ends.

[WanWizard]

Excellent explaination, chapeau!

[littlesat]

+1000.0000000

[fcs001fcs]

@SpaceRat

 

Excellent explanation.

 

I am a bit disappointed that OpenPLi 4 won't be corrected but I understand the limitation on focusing on the current efforts, OpenPLi 6.

[WanWizard]

We'll see what we can do. Without any guarantees...