Jump to content


Photo

merge requests for PLi's git


  • Please log in to reply
1748 replies to this topic

Re: merge requests for PLi's git #1721 Dimitrij

  • PLi® Core member
  • 10,023 posts

+338
Excellent

Posted 27 October 2023 - 05:36

I think it will be right

[StartEnigma] use correct value DVB time when start E2


GigaBlue UHD Quad 4K /Lunix3-4K/Solo 4K


Re: merge requests for PLi's git #1722 littlesat

  • PLi® Core member
  • 56,275 posts

+691
Excellent

Posted 27 October 2023 - 06:10

Then also in cpp it is arranged that when the current date is before 2004’then transponder time is used. So somehow ntp did not work -or- box is not online is already coded in cpp. And it also results in the config may not have the true value what method is actually used.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1723 littlesat

  • PLi® Core member
  • 56,275 posts

+691
Excellent

Posted 27 October 2023 - 06:13

What would consider to leave the legacy config and let that forward it to cpp part and in usageConfig set this legacy config instead of swig to cpp. And then indeed go for initial False in startenigma.

For ntp did not work part I’m afraid some brainstorming is required.

Actually when ntp does not work it is somehow mandatory to get the time from something else. This is already arranged in cpp. So I suggest just remove the auto option and let ntp fallback to transponder as long ntp does not work…. But how do we switch back to ntp once fallback to transponder time?

Edited by littlesat, 27 October 2023 - 06:17.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1724 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 27 October 2023 - 06:26

I think this is absolutely wrong.
 
As we found out, this is only needed because it is used by plugins that are no longer needed.
 
If we leave it for plugins, then plugins use it to set which method to use, dvb or ntp.
 
Now the option to specify something in plugins has been removed.
Why is this even needed in that case?
Remove it and remove this option from plugins.


Re: merge requests for PLi's git #1725 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 27 October 2023 - 06:45

As an example, you can look at plugin systemtime which I found by searching for this config value in plugins: https://github.com/O...in.py#L268-L275
 
The sync method is set and then saved to this setting.
I see that this plugin was added by Dimitrij, so I'm surprised that he offers such changes in eigma that break his plugin.
 
We need to leave only the config in enigma and delete the time setting by changing the config value, or If we ignore this plugin, delete everything, including the config, as WanWizard recommends.


Re: merge requests for PLi's git #1726 littlesat

  • PLi® Core member
  • 56,275 posts

+691
Excellent

Posted 27 October 2023 - 07:52

There is still something that it is doing. See line 526.... when it is not on transponder/dvb time it can sets an RTC via a procs when the box have them. I speculate this is a 'front style RTC', that continues to run when the box is in deep standby. Likely also here something is wrong as I would say set the RTC when it exists at any time.

 

https://github.com/O.../StartEnigma.py

 

so it needs more investigation I'm afraid.... 

 

My brain is going in circles any time I looked into that code... As also the config is not aligned what really happened. It could be 'on linux time' while it is still running on transponder time due to cpp...

 

see here:

https://github.com/O.../dvbtime.cpp#L291

 

This detail also keeps dvb time when there is no ntp sync yet..... while the config tells it is ntp time...


Edited by littlesat, 27 October 2023 - 08:00.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1727 WanWizard

  • PLi® Core member
  • 68,625 posts

+1,739
Excellent

Posted 27 October 2023 - 11:12

 

I think this is absolutely wrong.
 
As we found out, this is only needed because it is used by plugins that are no longer needed.

 

Correct. That code can go completely. As you showed init now happens in usageConfig.

 

There is still something that it is doing. See line 526.... when it is not on transponder/dvb time it can sets an RTC via a procs when the box have them. I speculate this is a 'front style RTC', that continues to run when the box is in deep standby. Likely also here something is wrong as I would say set the RTC when it exists at any time.

 

https://github.com/O.../StartEnigma.py

 

Needs to change to using config.misc.timesync.

 

see here:

https://github.com/O.../dvbtime.cpp#L291

 

This detail also keeps dvb time when there is no ntp sync yet..... while the config tells it is ntp time...

 

Has to be removed completely, that serves no purpose, and is old code from the "transpondertime yes/no" period... Before NTP was used.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1728 littlesat

  • PLi® Core member
  • 56,275 posts

+691
Excellent

Posted 27 October 2023 - 14:01

I'm afraid the RTC on the frontprocesser needs always to be updated (when it exists)... here we do not care if it is coming from ntp or dvb.... when there is a reasonable time/date it should update the front processor RTC. I do not see any reason for this setting... I only recommend to only 'set' it when there is a reasonable time/date.


Needs to change to using config.misc.timesync.


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1729 littlesat

  • PLi® Core member
  • 56,275 posts

+691
Excellent

Posted 27 October 2023 - 14:02

I hope it does not have side effects... but indeed it is better to remove this and leave the logic to the python part... There is even more done there. It is very 'spaghetti' code in c++....


Has to be removed completely, that serves no purpose, and is old code from the "transpondertime yes/no" period... Before NTP was used.


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1730 littlesat

  • PLi® Core member
  • 56,275 posts

+691
Excellent

Posted 27 October 2023 - 14:09

I suggest something like this is also needed.... And maybe consider to change it to today..... as 01-01-2004 is long time ago.... so we have already almost 20 years of not reasonable date/times.

void eDVBLocalTimeHandler::setUseDVBTime(bool b)
{
                if (m_use_dvb_time != b) {
                                if (!b)
                                {
                                                time_t now = time(0);
-                                                if (now < 1072224000) /* 01.01.2004 */
-                                                {
-                                                                eDebug("[eDVBLocalTimeHandler] invalid system time, refuse to disable transponder time sync");
-                                                                return;
-                                                }
-                                                else
-                                                if (now >= 1072224000) /* 01.01.2004 */
                                                                m_time_ready = true;
                                }
                                if (m_use_dvb_time) {
                                                eDebug("[eDVBLocalTimeHandler] disable sync local time with transponder time!");
                                                std::map<iDVBChannel*, channel_data>::iterator it =
                                                                m_knownChannels.begin();
                                                for (; it != m_knownChannels.end(); ++it) {
                                                                if (it->second.m_prevChannelState == iDVBChannel::state_ok)
                                                                {
                                                                                it->second.timetable = NULL;
                                                                }
                                                }
                                }
                                else {
                                                eDebug("[eDVBLocalTimeHandler] enable sync local time with transponder time!");
                                                std::map<iDVBChannel*, channel_data>::iterator it =
                                                                m_knownChannels.begin();
                                                for (; it != m_knownChannels.end(); ++it) {
                                                                if (it->second.m_prevChannelState == iDVBChannel::state_ok) {
                                                                                int system = iDVBFrontend::feSatellite;
                                                                                ePtr<iDVBFrontendParameters> parms;
                                                                                it->second.channel->getCurrentFrontendParameters(parms);
                                                                                if (parms)
                                                                                {
                                                                                                parms->getSystem(system);
                                                                                }
 
                                                                                it->second.timetable = NULL;
                                                                                if (system == iDVBFrontend::feATSC)
                                                                                {
                                                                                                it->second.timetable = new STT(it->second.channel);
                                                                                }
                                                                                else
                                                                                {
                                                                                                it->second.timetable = new TDT(it->second.channel);
                                                                                }
                                                                                it->second.timetable->start();
                                                                }
                                                }
                                }
                                m_use_dvb_time = b;
                }
}

Edited by littlesat, 27 October 2023 - 14:12.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1731 littlesat

  • PLi® Core member
  • 56,275 posts

+691
Excellent

Posted 27 October 2023 - 14:12

And then here:

change it such a way thet the RTCtime is set when there is a reasonable date/time... Instead of checking the config. Then the config can be removed....

if not config.misc.useTransponderTime.value:
    print("[StartEnigma] DVB time sync disabled... so set RTC now to current linux time!", strftime("%Y/%m/%d %H:%M", localtime(nowTime)))
    setRTCtime(nowTime)

Edited by littlesat, 27 October 2023 - 14:13.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1732 littlesat

  • PLi® Core member
  • 56,275 posts

+691
Excellent

Posted 27 October 2023 - 14:18

Then a third step is.... we need to 'find' a kind of trigger when we do have ntp and we want to force 'ntp' that we have a kind of trigger or polling mechanism to set it 'back' to ntp.... or something like that....

But unless all of this the complete time sync code from enigma2 looks hacky..... A lot effort is inside trying to resolve jittering in transponder time/date I think...


Edited by littlesat, 27 October 2023 - 14:20.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1733 WanWizard

  • PLi® Core member
  • 68,625 posts

+1,739
Excellent

Posted 27 October 2023 - 14:26

The

time_t now = time(0);

can go too.

 

The only thing still relevant there is

if (!b)
{
    m_time_ready = true;
}

 


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1734 WanWizard

  • PLi® Core member
  • 68,625 posts

+1,739
Excellent

Posted 27 October 2023 - 14:31

Then a third step is.... we need to 'find' a kind of trigger when we do have ntp and we want to force 'ntp' that we have a kind of trigger or polling mechanism to set it 'back' to ntp.... or something like that....

 

Why?

 

If I want NTP, I want NTP. And I don't want Enigma to secretly do something else behind the scenes.

 

The issue is AUTO, that feature needs to be rewritten with a proper check on a working ntp (either by testing ntpdate itself, or by scanning /var/log/messages for valid ntp updates).

 

And if ntp has turned out not to be working (yet), it needs to enable transpondertime, and add a callback (for example 5 or 10 minutes) to do the check again. Otherwise it needs to disable transpondertime.

And probably there should be a limit to how many times you want to do the callback, if there is no NTP after an hour, it will probably never work...


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1735 littlesat

  • PLi® Core member
  • 56,275 posts

+691
Excellent

Posted 27 October 2023 - 15:15


The only thing still relevant there is

Not true.... this should only be set when there is a reasonable time... without reasonable time the time is not ready...


WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1736 littlesat

  • PLi® Core member
  • 56,275 posts

+691
Excellent

Posted 27 October 2023 - 15:18


Why?

 

To ensure enigma2 does sync with the system time... and does not adjust the system time and versa... When you 'never' synch with system time when you do not depend on dvb time then engima2 itself is running forever years and years ago and you do not get EPG info etc... When I miss something please point me where enigma2 is synchronizing with system time...


Edited by littlesat, 27 October 2023 - 15:18.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1737 Taapat

  • PLi® Core member
  • 2,343 posts

+120
Excellent

Posted 27 October 2023 - 16:06

 


Why?

 

To ensure enigma2 does sync with the system time... and does not adjust the system time and versa... When you 'never' synch with system time when you do not depend on dvb time then engima2 itself is running forever years and years ago and you do not get EPG info etc... When I miss something please point me where enigma2 is synchronizing with system time...

 

 

If I want dvb as a ntp fallback, I choose auto.
If I choose ntp in that case only ntp, if dvb in that case only dvb.

Edited by Taapat, 27 October 2023 - 16:06.


Re: merge requests for PLi's git #1738 WanWizard

  • PLi® Core member
  • 68,625 posts

+1,739
Excellent

Posted 27 October 2023 - 16:24

Exactly.

 

And I don't want any "automagic" in Enigma that secretly changes configured behaviour.

 

In my case, if NTP doesn't work I have a configuration error I must fix (either on the box or in the network), secretly switching to transponder time hides that error, and will have my boxes running on a time source I don't want to use.


Edited by WanWizard, 27 October 2023 - 16:26.

Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.


Re: merge requests for PLi's git #1739 littlesat

  • PLi® Core member
  • 56,275 posts

+691
Excellent

Posted 27 October 2023 - 18:36

Ntp only is not possible now without cpp fix now. To get auto really work we need also something special.

WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W


Re: merge requests for PLi's git #1740 WanWizard

  • PLi® Core member
  • 68,625 posts

+1,739
Excellent

Posted 27 October 2023 - 18:48

What cpp fix?

 

There is nothing to fix, the code that still enables dvb time when False is passed needs to be removed. Period. It doesn't belong there.

 

If timesync is configured for NTP, nothing, nowhere, may enable dvb time. NEVER.

 

And I have already explained how AUTO could be addressed. Without any repsonse whatsover.


Currently in use: VU+ Duo 4K (2xFBC S2), VU+ Solo 4K (1xFBC S2), uClan Usytm 4K Pro (S2+T2), Octagon SF8008 (S2+T2), Zgemma H9.2H (S2+T2)

Due to my bad health, I will not be very active at times and may be slow to respond. I will not read the forum or PM on a regular basis.

Many answers to your question can be found in our new and improved wiki.



1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users