[GiGaBlue UHD QUAD 4K] Missed 6 Recordings Overnight 30/31 Aug

[birdman]

1. config.autobouquetsmaker.nextscheduletime is only used when shutting the box down to deep standby so it knows the next wake up time.
2. 1546300800: # Tuesday, January 1, 2019 12:00:00 AM is used to detect the clock is set.
3. If your hardware clock shows a time later than this point ABM will work out the next scheduled download based on that time.

Which is wrong once fake-hwclock is in place, since the time will be after 2019, but will not be correct - it will be some time (hours) in the past.
Unless the scheduling doesn't take place until after enigma2 has had a chance to set the time itself (i.e. after the transponder time has had a chance to be used).

1. The scheduled download is a relative timer so once set it will tick down and do the download if the box is still alive at that point.
2. If the clock is reset in the mean time the running timer will not be affected and continues to tick towards the same relative target point.

But if the original clock was wrong then the original relative time for the timer will also have been wrong (which is, I think, where this started).
Why not set an absolute timer for the next download? This has more likelihood of running at the correct time if the clock needs to be corrected.

1. If you knew the clock had changed, calling AutoScheduleTimer.instance.doneConfiguring() will re-evaluate when the next schedule download should take place. Easy as pie.
2. So in order to do anything we need a signal from the time code to inform of a clock change. Not easy, especially as the update via dvb is handled in C++. Ideas.

Or we could find where the clock set/check is called (needs to be for both NTP and DVB), save the wallclock time (time()) before the call and check whether the time after the call has changed by > (say) 1 minute.
If so then update timers. If it is less than that then we don't really care.

 

[Joe_90]

...
But if the original clock was wrong then the original relative time for the timer will also have been wrong (which is, I think, where this started).
Why not set an absolute timer for the next download? This has more likelihood of running at the correct time if the clock needs to be corrected.
...

Yay! This is what I've been banging on about. I'm glad you're in a similar frame of reference at this point.

Yes, I think using absolute timers would probably work. Any time I've seen this error, the ABM schedule evaluation and relative timer set only missed a correct time setting (from transponder) by less than a minute. Now, this presumes that the user has set up a default service to be tuned at startup! Otherwise, the time may not be corrected until some event causes either a service tune or an NTP sync. But, overall I would think this would sort out this, admittedly, rare use case.

ps - your quotes of @Huevos's post has renumbered his originals

 

[Huevos]

Which is wrong once fake-hwclock is in place, since the time will be after 2019, but will not be correct - it will be some time (hours) in the past.
Unless the scheduling doesn't take place until after enigma2 has had a chance to set the time itself (i.e. after the transponder time has had a chance to be used).

It is not "wrong", it is a check that the clock is set, which it is. The plugin does not have a crystal ball to detect the clock is set wrong. This needs to be handled elsewhere on startup, not blame the plugin and all the other things that go wrong elsewhere when the clock is set incorrectly.

 

[Huevos]

if the original clock was wrong then the original relative time for the timer will also have been wrong (which is, I think, where this started).
Why not set an absolute timer for the next download? This has more likelihood of running at the correct time if the clock needs to be corrected.

Relative timers are what is used in enigma, i.e, from enigma import eTimer.

 

[Huevos]

we could find where the clock set/check is called (needs to be for both NTP and DVB), save the wallclock time (time()) before the call and check whether the time after the call has changed by > (say) 1 minute.
If so then update timers. If it is less than that then we don't really care.

As I already said the clock is set in C++ when accessing a DVB transponder, or the NTP script. With neither of those is a callback possible. And we are not going to add some stupid checks in enigma the use loop/sleep/poll.

 

[birdman]

And we are not going to add some stupid checks in enigma the use loop/sleep/poll.

Which is not what I suggested.

 

[Huevos]

[main-schedule] add NetworkTime callback to update timers when enigma… · oe-alliance/AutoBouquetsMaker@f941a46

… changes the system time Only compatible distros)

github.com

Joe can you reply to the comment please.

 

[Joe_90]

[main-schedule] add NetworkTime callback to update timers when enigma… · oe-alliance/AutoBouquetsMaker@f941a46

… changes the system time Only compatible distros)

github.com

Joe can you reply to the comment please.

Done!

 

[Joe_90]

Actually - time to update this thread. @Huevos has updated the NetwokTime code to flag if the system time has been updated significantly (> 1 min). In this case the schedule evaluation for ABM and OpenTVzapper is triggered and the relative timer corrected.

 

[CRMS]

Sorry for the late reply - been busy boat DIYing.
Many thanks for all your investigations and remedy.
Does this mean there will be revised code in a new OV version??

 

[Huevos]

Does this mean there will be revised code in a new OV version??

Yes, for example in 6.7.020.

 

[CRMS]

Great. Updated to 6.7.020 and all seems to be good.
If I look in the debug log, is there anything that shows the revision??
I'm amazed at the number of lines in a debug log. Is there a decode of the line titles - generally in the [ ] brackets just after the time??