173 replies to this topic

[WanWizard]

That isn't a fix, that is the standard procedure. If you pick a "reputable" transponder (BBC1, NED1, ARD, ZDF, etc) as your cold startup transponder, you shouldn't have this issue.

 

But it is still something manual the user have to do, it would be better if the software would "auto-correct" any problems.

[SpaceRat]

That isn't a fix, that is the standard procedure. If you pick a "reputable" transponder (BBC1, NED1, ARD, ZDF, etc) as your cold startup transponder, you shouldn't have this issue.

Not really: The dvbtime.cpp code will still allow the box' time to slowly but steadily drift.

For a networked box, NTP seems to be the better choice to me.

[Satpal]

That isn't a fix, that is the standard procedure. If you pick a "reputable" transponder (BBC1, NED1, ARD, ZDF, etc) as your cold startup transponder, you shouldn't have this issue.

This is the statement that has been driving me nuts for years now as it is obviously wrong! As SpaceRat pointed out the boards were and are still full of reports that prove otherwise. It may well be that you don't use any of the concerned transponders but there must be quite a lot of them out there and apparently they are being used by other people all the time.

 

Of course I use this "standard procedure" for years but still after a few hours or zapping the time is off by almost two minutes (before it was sometimes worse, but lately 90 seconds seems to be standard). But it seems you didn't get my point: I was under the impression that there had been a change implemented that you could stop the box from syncing the time after setting a startup channel if you wished to.

 

But thanks to SpaceRat I finally grasp how this result is even possible: a time that can easily be changed to a wrong one but then never back. Seems to be the worst of both worlds.

[SpaceRat]

OpenPLi:
https://forums.openp...ng-system-date/
https://forums.openp...ing-wrong-time/
https://forums.openp...time-displayed/
https://forums.openp...-time-and-date/

OpenATV:
https://www.opena.tv...lsche-zeit.html
https://www.opena.tv...ay-uhrzeit.html
https://www.opena.tv...eit-falsch.html
https://www.opena.tv...0-zeit-bug.html

OpenViX:
http://www.world-of-...show-wrong-time
http://www.world-of-...g-date-and-time
http://www.world-of-...wing-on-VIX-2-4
http://www.world-of-...lashing-VIX-2-1

...

Indeed, there are more important problems to solve ... maybe some whitespace fixes or rewriting counted for loops to do ... while?

WanWizard once asked me why I'm such an asshole sometimes.

It's simple:
Because I deem the OpenPLi devs to be very competent coders - if not the most competent remaining in the scene - and you can definitely take that as a compliment, but they are wasting their time rewriting the working parts of E2 again and again (I refer to OpenPLi as OpenReInventingTheWheel), not touching any of the true problems.
There is a shitload of bugs and ugly limitations in E2 and for years I eagerly waited for the time when some E2 box is ready for end users (That means: I would recommend my parents to get one).

If a bug that affects any box and any distro and loads of users is not worth being fixed, I don't know what is worth being fixed.

[WanWizard]

Our biggest challenge is that we don't have (by far) enough of them.

 

To be able to really attack major issues you need a few knowledgable people that are committed to work together for a significant amount of time. As long as that doesn't happen, and everyone just dabbles along, nothing significant is going to change.

 

Which, believe me, irritates me almost as much as you.

 

That is also where the remark comes from btw. You know a lot, sometimes have very valuable input, but stop at that point. So we get into a catch-22 situation where you know a solution but don't give it (in the form of a PR), and we don't have the manpower to pick it up and re-invent the wheel you obviously have already invented (or at least far enough to be of more help).

 

Which for us is very frustrating too, because we end up being assholes to each other, and nothing gets fixed.

[twol]

Guys, then obviously the solution is you automatically (transparently) change transponder time to NTP time and then there is no problem or ?????? .. if a network connection is present, which for most receivers will be true.

Edited by twol, 22 December 2017 - 18:50.

[betacentauri]

And what if there is no network connection? Use same algorithm like now?

[mattiL]

Just a little comment, I did install Systemtime, but it did not seem to work

Time was still off even efter one hour with 10 minutes sync interval defined.

 

And yes, I do have a constant network/internet connection to my receiver.

[WanWizard]

Then you've done something wrong. For example not restarted?

 

These settings should work fine, they do here (this box doesn't have tuners), so I need to use NTP.

Attached Files

•  1_0_19_1E46_809_2_11A0000_0_0_0.jpg   87.87KB   6 downloads

[mattiL]

Then you've done something wrong. For example not restarted?

 

These settings should work fine, they do here (this box doesn't have tuners), so I need to use NTP.

Looks like the settings I used, and I did restart, several times in fact.

Will test again tomorrow.

 

Thx!

[Erik Slagter]

 

That isn't a fix, that is the standard procedure. If you pick a "reputable" transponder (BBC1, NED1, ARD, ZDF, etc) as your cold startup transponder, you shouldn't have this issue.

Not really: The dvbtime.cpp code will still allow the box' time to slowly but steadily drift.

For a networked box, NTP seems to be the better choice to me.

Everbody is already free to do so.

[Erik Slagter]

Our biggest challenge is that we don't have (by far) enough of them.

And that's why we're focussing on just keeping it working for 99.9% of the users. There are always piles and piles of stuff that don't work completely as expected for a minor group. It would be nice if we could make them happy too, but it's a luxury we can't afford.

[mattiL]

Then you've done something wrong. For example not restarted?

 

These settings should work fine, they do here (this box doesn't have tuners), so I need to use NTP.

Ok, it seems to work now:

 

Dec 22 22:27:13 vuduo2 daemon.notice ntpdate[1575]: adjust time server 178.73.198.130 offset -0.009480 sec

Dec 22 22:32:13 vuduo2 daemon.notice ntpdate[2457]: adjust time server 178.73.198.130 offset -0.005679 sec

[Pr2]

Hi,

 

Indeed I don't understand why NTP is not the standard to get time, I recently decide to install systemtime plugin and enable it on NTP on every boxes.

 

Why not activate the NTP as default method with a fall back to transpoder time when network is not available.

 

NTP is also a solution for people that use STB as IPTV only box and for people that use both IPTV and DVB if they turn off the box on an IPTV channel it won't get time with the current default transponder time method.

 

Pr2

[Erik Slagter]

NTP is also a solution for people that use STB as IPTV only box and for people that use both IPTV and DVB if they turn off the box on an IPTV channel it won't get time with the current default transponder time method.

Yes and that's why supply the system time plugin with ntp access.

There is simply no such use for everybody, not even even "most of us".

[birdman]

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.

 

Some boxes do have a RTC - or have already set the correct time using NTP.

If setting a start-up channel were so important then it should have been forced - not left with the ability to use the "last tuned channel".

 

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

 

All of my transponders have the correct time (UK Freeview Terrestrial).

 

However - the issues here is that someone added the fake-hwclock code to ensure that a roughly-valid time is always set at boot (it sets it to the time of the last shutdown). But this mechanism means that the transponder time is now out by > 120s at start-up, so it is never used and the incorrect "roughly-valid" time is never corrected, so none of your recording get done.

 

So whomsoever added the fake-hwclock code didn't think through (or test!) the consequences of adding it.

Edited by birdman, 26 December 2017 - 18:52.

[birdman]

Hi,

 

Indeed I don't understand why NTP is not the standard to get time

 

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

 

But the most relevant thing here is that it is the standard, so a lot of people will be using and and will be messed up as a result of recent untested changes.

Edited by birdman, 26 December 2017 - 18:51.

[WanWizard]

If setting a start-up channel were so important then it should have been forced - not left with the ability to use the "last tuned channel".

 

It isn't.

 

It is only in case you happen to have a provider (or you're a feedhunter) that has transponders using incorrect time, and you happen to be on such a transponder when you switch off your box (as it will boot up again on this transponder if no startup channel is configured). In all other cases, this is a non-issue.

 

All of my transponders have the correct time (UK Freeview Terrestrial).

 

Exactly. Same is true for all SKY transponders, and most if not all transponders normally used in Europe.

 

However - the issues here is that someone added the fake-hwclock code to ensure that a roughly-valid time is always set at boot (it sets it to the time of the last shutdown). But this mechanism means that the transponder time is now out by > 120s at start-up, so it is never used and the incorrect "roughly-valid" time is never corrected, so none of your recording get done.

 

Not on OpenPLi it isn't.

 

Every OpenPLI boots (assuming no RTC is present) with epoch time, and expects an external timesource (by default, the first transponder locked) to fix that. The 120s delta, is there to make sure that when you zap to a transponder that is too far off, it's time is ignored. If that mechanism is not there, setting the correct time (at any point) is useless, because every zap could reset your time to god knows what.

 

I don't know where you got the idea that this is untested (it is, and it does exactly what it was meant to do), and this code has been in Enigma for dogs years, it was already in Enigma1. 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.

 

Rather than complaining and coming up with incorrect statements, I prefer to see a more constructive approach.

 

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"?

[ccs]

 

It is only in case you happen to have a provider (or you're a feedhunter) that has transponders using incorrect time, and you happen to be on such a transponder when you switch off your box (as it will boot up again on this transponder if no startup channel is configured). In all other cases, this is a non-issue.

Surely this case has to be avoided/catered for - in post #3 you advised the OP to select a "good" transponder before powering off.

[WanWizard]

You can't avoid the case, unless you "climb up" and fix all satellites floating around in space.

 

I advised the OP because appearently the OP had this issue, and the current methods to cater for it is to either make sure the box boots with a known-good transponder, or install an NTP client solution.