I think it will be right
[StartEnigma] use correct value DVB time when start E2
Posted 27 October 2023 - 05:36
GigaBlue UHD Quad 4K /Lunix3-4K/Duo 4K
Posted 27 October 2023 - 06:10
WaveFrontier 28.2E | 23.5E | 19.2E | 16E | 13E | 10/9E | 7E | 5E | 1W | 4/5W | 15W
Posted 27 October 2023 - 06:13
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
Posted 27 October 2023 - 06:26
Posted 27 October 2023 - 06:45
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
Posted 27 October 2023 - 11:12
Why is this merged: https://github.com/O...c2e6b99ed101c02I 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.
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 Ultimate (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.
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
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
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
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
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
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 Ultimate (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.
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 Ultimate (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.
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
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...
Edited by Taapat, 27 October 2023 - 16:06.
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 Ultimate (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.
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 Ultimate (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.
0 members, 21 guests, 0 anonymous users