5 replies to this topic

[Satpal]

I opened a topic on this issue a while ago: and I must say I'm still not impressed with the way it was dealt here.

 

The short version: the system time and date of the box get easily messed up, too easy for my taste, when trying to tune in channels that are on the edge of reception. Of course I accept that this can happen, what I still cannot accept is the fact that after this happens the box is stuck with this new time (e.g. today March 30, 2017) and doesn't revert to normal time when switching to a "good" transponder.

 

Furthermore I don't understand how it is possible that when this happens my timers are corrupted and then cannot even be edited to their old times and dates, sometimes all of them, sometimes only a few.

 

There are so many things added into Openpli many of which I welcome and hoped for like Hotkeys, PiP handling, hide VBI lines, even sort menu but there are also some things which I consider pretty much a complete waste of time compared to such a problem. That's why I don't understand why it shouldn't be possible to address such a basic issue as it has been done by others before, in this case I'm referring to the Power-Board image which I used for quite a while before making the move to Openpli. Their solution: Take the time from a fixed channel/tp.

 

Why would it be so hard to take the system time from a channel picked by the user as it's done with the default starting channel (which in 99.9% of cases will give the correct system time anyway)? And especially: what the heck would be a valid argument against that except for the few lines of code it would need?

If this was done as an additional option as it is for the default starting channel nobody would even notice the difference unless he activated it.

[WanWizard]

Most boxes don't have an RTC.

 

So in order to get the time after startup, it takes the time from the startup transponder. It also has wrong-time protection, if you zap to a transponder who's time delta is too large, it will not pick up this time, but will ignore it. And this is probably your issue. If you start your box on a "wrong" transponder, it will take that time as correct, and all correct ones as wrong.

 

Easily fixed: set the known good transponder (I use BBC 1) as startup transponder. Problem solved. Alternatively, install the system time plugin, disable transponder time, and internet time (NTP).

 

I have no clue what you mean by

 

 

Why would it be so hard to take the system time from a channel picked by the user as it's done with the default starting channel (which in 99.9% of cases will give the correct system time anyway)? And especially: what the heck would be a valid argument against that except for the few lines of code it would need? If this was done as an additional option as it is for the default starting channel nobody would even notice the difference unless he activated it.

 

nor what your problem is. If the box boots up to the correct startup transponder, the time is correct, and it will ignore transponders with an incorrect time.

[Satpal]

Of course my startup channel (Das Erste 19.2E) gives a correct time. And of course if I just keep watching only the strongest satellites nothing bad will happen. But that's not really the point of having such an expensive box (Vu Solo2/ET10000). If I wanted to use a cheap crappy box I could just use the one forced upon me by my provider, but that's not really the point now, is it? Apparently your "wrong-time protection" only kicks in after it got the wrong time otherwise I wouldn't have those problems.

 

Yet still no one could explain or even comment on the timer issue. If this wouldn't happen it would be only half dramatic, a quick reboot and done. But if you have a list of 10-20 timers that become unusable every time this happens it's pretty annoying.

[Pr2]

The solution to avoid this problem is already provided to you: use network time protocol (NTP).

[WanWizard]

It is not "my" wrong-time protection, it's been part of Enigma for many years, it was already in E1.

 

If the time received deviates from the current time with more than a given delta, it should ignore that time. If that doesn't work, someone has broken this mechanism, and need to be tarred and feathered!

 

To check, can you stop enigma using

init 4

and then start it again using

ENIGMA_DEBUG_LVL=4 enigma2

It should give you a lot of "[eDVBLocalTimerHandler]" debug output.

 

Can you try this, zap to some transponders with incorrect time, verify that the time is incorrectly updated, and then post the debug output here?

[WanWizard]

p.s. OpenPLi has the option to sync with any transponder time on the spot, it has been there since March 10th. But it's GUI counterpart is part of the systemtime plugin (it has the sync-with-transponder menu option).