1748 replies to this topic

[Dimitrij]

[epgimport] reorganize plugin

[WanWizard]

Merged

[Dimitrij]

Merged

thanks  

[Dimitrij]

[epgimport] fix first append afterStandbyRunImport in standby

[WanWizard]

Merged by @littlesat.

[littlesat]

You’re welcome

[Dimitrij]

thanks

[Dimitrij]

What enigma does is not relevant, it is completely handled at the network layer.

 

Do you have the /etc/network/if-up.d/ntpdate-sync symlink? Is it triggered when the network comes up, and what is the result (check dmesg or add some debugging to the script)?

 

Your plugin calls ntpdate too, the only difference is timing, or perhaps the IP of the NTP server used (see /etc/defaults/ntpdate).

 

If it sometimes works, sometimes not, I suggest you add a "sleep 1" at the top of the ntpdate-sync script, and see if that adresses the problem, as it suggests is may be fired when the interface is up but IP isn't yet (for example because of slow DHCP response).

I think the problem is here

	def timesyncChanged(configElement):
		if configElement.value == "dvb" or not GetIPsFromNetworkInterfaces():
			eDVBLocalTimeHandler.getInstance().setUseDVBTime(True)
			eEPGCache.getInstance().timeUpdated()
			if os.path.isfile('/var/spool/cron/crontabs/root'):
				Console().ePopen("sed -i '/ntpdate-sync/d' /var/spool/cron/crontabs/root;")
			if configElement.value == "dvb" and os.path.islink('/etc/network/if-up.d/ntpdate-sync'):
				Console().ePopen("unlink /etc/network/if-up.d/ntpdate-sync")
		else:
			eDVBLocalTimeHandler.getInstance().setUseDVBTime(False)
			eEPGCache.getInstance().timeUpdated()
			if not os.path.isfile('/var/spool/cron/crontabs/root') or not 'ntpdate-sync' in open('/var/spool/cron/crontabs/root').read():
				Console().ePopen("echo '30 * * * *    /usr/bin/ntpdate-sync silent' >> /var/spool/cron/crontabs/root")
			if not os.path.islink('/etc/network/if-up.d/ntpdate-sync'):
				Console().ePopen("ln -s /usr/bin/ntpdate-sync /etc/network/if-up.d/ntpdate-sync")
	config.ntp.timesync = ConfigSelection(default="auto", choices=[("auto", _("auto")), ("dvb", _("Transponder Time")), ("ntp", _("Internet (ntp)"))])
	config.ntp.timesync.addNotifier(timesyncChanged)
	config.ntp.server = ConfigText("pool.ntp.org", fixed_size=False)

Maybe

-		if configElement.value == "dvb" or not GetIPsFromNetworkInterfaces():
+               if configElement.value == "dvb" or (configElement.value == "auto" and not GetIPsFromNetworkInterfaces()):
			eDVBLocalTimeHandler.getInstance().setUseDVBTime(True)

Edited by Dimitrij, 23 October 2023 - 16:58.

[WanWizard]

Looking into it, I think the problem is elsewhere.

 

During startup, in startEnigma, it is called with a ConfigYesNo element called "useTransponderTime" set to true (this is now old, pre-NTP code). But passing that here causes the "else" to be excuted, NOT using transponder time.

 

So, this should be changed to using "auto" as that is the default for config.ntp.timesync.

 

Both "dvb" and "ntp" are settings that make permanent and prersistent changes to the filesystem, while "auto" is dynamic, meaning "use dvb if ntp is not available". With the fix to startEnigma in place, this code would do exactly that.

 

My guess is Littlesat forgot to update the start code when implementing this feature.

[Dimitrij]

My opinion, if the config.ntp.timesync is "ntp" not need check GetIPsFromNetworkInterfaces().

My new router only uses the mobile network and registering a local IP takes a very long time.

Edited by Dimitrij, 23 October 2023 - 18:28.

[WanWizard]

I think the idea behind that was that for "auto" and "ntp", if there is no network, both to fall back to "dvb". Which in itself should not be a problem.

 

Either way, it is not the reason your box doesn't get the time, if your observation is correct and the problem is not getting an IP before E2 starts, the "or" will make sure it will fall back to transponder time if the box doesn't have an IP at startup. No matter what the config setting is.

 

edit:

 

Oh, wait, your problem is you want "ntp", but don't have an IP in time. I guess in that case the swap from ntp to dvb due to the IP check isn't handy, no.

 

In that case I understand and agree with your proposed fix. But note that also startEnigma needs fixing.

Edited by WanWizard, 23 October 2023 - 18:44.

[Huevos]

The idea is to get the clock set correct before enigma starts. Otherwise any filenames that include dates created by enigma won't be correct.

[littlesat]

Isn’t the real issue triggered by that the router being too slow?

[Dimitrij]

Isn’t the real issue triggered by that the router being too slow?

I have seen problems with obtaining NTP time on different receivers and with different routers.

Of course, these may be different problems, but they need to be solved.

[mrvica]

rdate could be an alternative

https://forums.openp...dpost&p=1250414

[WanWizard]

The idea is to get the clock set correct before enigma starts. Otherwise any filenames that include dates created by enigma won't be correct.

 

That is not possible.

 

Either because the box uses transponder time (for which E2 needs to run and have a transponder tuned), or in case of NTP you have to wait with starting E2 until you have a time, which may never come in some cases.

[WanWizard]

rdate could be an alternative

https://forums.openp...dpost&p=1250414

 

Fetching the time is not the problem here.

 

The problem is that

1. during startup in StartEnigma the new timesync variable isn't used ( code never updated by Littlesat ), causing E2 to fall back to transponder time if no IP is present, which fails if there is no transponder (for example with IPTV).
2. the fallback still happens even if you have set the timesync to NTP ( which is what Dimitrij's suggested change fixes )

[Huevos]

 

The idea is to get the clock set correct before enigma starts. Otherwise any filenames that include dates created by enigma won't be correct.

 

That is not possible.

 

Either because the box uses transponder time (for which E2 needs to run and have a transponder tuned), or in case of NTP you have to wait with starting E2 until you have a time, which may never come in some cases.

 

In vix the clock is set before enigma starts. This is proved by the log files having the correct date. Obviously the network needs to be up.

[littlesat]

In vix the clock is set before enigma starts. This is proved by the log files having the correct date. Obviously the network needs to be up.

[WanWizard]

In vix the clock is set before enigma starts. This is proved by the log files having the correct date. Obviously the network needs to be up.

 

And that is exactly the problem here, the long delay before the network is up...
 

But that isn't the root cause here, I've given that in my previous post. VIX doesn't have that problem, it has different code to handle NTP time, and doesn't have the startenigma bug either.