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

[birdman]

The box time when these two jobs are initially checked reads as 18.05 on the previous day (when the box last shut down), so a start interval timer of some 23 hours and 45 minutes commences for ABM and 23 hours and 55 minutes starts for EPG update. The box gets its time from BBC 1 shortly after and the time is corrected maybe 20-30 seconds after the initial ABM and EPG interval timers have been started. But those interval timers are never re-evaluated.

That's a bug, then.
A relative timer should fire relative to when it is set, regardless of any change to the wall-clock time.
And an absolute timer set for a clock running in the past should just fire sooner when that clock is corrected.

 

[Joe_90]

I'm not sure what you mean by an absolute timer. The ABM schedule is pre-determined. In my case it was set for 18.00 every day. If, at boot time the actual time was 17.45 today and the system time was correct due to NTP sync, then the calculation would be (18.00 today minus 17.45 today = 15 minutes) and the relative timer would be set to expire after that interval and ABM would start at 18.00. If NTP sync wasn't done during boott the calculation would be (18.00 today minus 18.05 yesterday (when the box last shut down) = 23 hours and 55 minutes) and the relative timer wouldn't expire until all that time had elapsed, so ABM wouldn't run unless the box was left active or in normal standby. I presume what you mean by an absolute timer is an event to be triggered at a specific epoch time rather than what is being used in the ABM or OpenEPG schedule code which makes a calculation and tells the o/s or enigma to trigger the job in x minutes.

 

[birdman]

I'm not sure what you mean by an absolute timer.

If I set a timer for 10s from now, that's a relative timer. I want it to fire 10s from now, even if the wall clock is reset in between.

If I set a timer for 2025 Sep 07 12:34:56, that is an absolute timer and I want it to fire then (or immediately at any time after that if it hasn't already fired - as a result of a sudden walk-clock step forward).

 

[Joe_90]

Ok - that's what I surmised. The problem is that ABM / EPG schedule code is using relative timers and the fake-hwclock trips it up on occasion when no NTP sync is done during boot. Recordings code must be using absolute timers.

 

[birdman]

Ok - that's what I surmised. The problem is that ABM / EPG schedule code is using relative timers and the fake-hwclock trips it up on occasion when no NTP sync is done during boot. Recordings code must be using absolute timers.

If it isn't firing with a relative timer then the calculation of the relative time is incorrect.
So it's still a bug.

I don't use ABM and only use the EPG from the transponders, so I can't check anything.

 

[Joe_90]

If it isn't firing with a relative timer then the calculation of the relative time is incorrect.
So it's still a bug.

That's what I've been saying - the calculation is wrong because of fake-hwclock - the system time is plausible but in the past. In my case it's almost 24 hours in the past on my test boxes if NTP doesn't work as they are booted just once per day. If ABM and OpenEPG schedule time evaluation was done using absolute timers the issue wouldn't arise providing the system time is set from transponder shortly after enigma starts.

 

[birdman]

That's what I've been saying - the calculation is wrong because of fake-hwclock - the system time is plausible but in the past. In my case it's almost 24 hours in the past on my test boxes if NTP doesn't work

All of which is irrelevant to a relative timer, as if it is set to, say, 10mins it will fire in 10mins regardless of what happens to the system clock in the meantime.

 

[Joe_90]

All of which is irrelevant to a relative timer, as if it is set to, say, 10mins it will fire in 10mins regardless of what happens to the system clock in the meantime.

Yes - but in the case I outlined in #22, the relative timer which, all things being equal and good, should be 10 minutes or 15 minutes, is being set to 23 hours and 45 or 50 minutes because the clock is wrong! That initial relative timer calculation is done once at very early enigma startup and never done again.

 

[birdman]

Yes - but in the case I outlined in #22, the relative timer which, all things being equal and good, should be 10 minutes or 15 minutes, is being set to 23 hours and 45 or 50 minutes because the clock is wrong! That initial relative timer calculation is done once at very early enigma startup and never done again.

If I want to set a relative timer for 10mins I would set it for 10mins.
The current (and future) state of the clock is irrelevant to a relative timer.

You seem to be describing the result of using an absolute timer as a "relative" one by doing some time calculation to work out what to set. But that is still an absolute timer and prone to the problem you describe.

 

[Huevos]

If I want to set a relative timer for 10mins I would set it for 10mins.

The point is there is no RTC on some models and the hardware timer does not run at the correct rate. That is not a software bug.

 

[birdman]

The point is there is no RTC on some models and the hardware timer does not run at the correct rate. That is not a software bug.

The setting of timers is a bug if it doesn't work as it could.
The software should handle clock changes (jumps).

 

[Huevos]

The setting of timers is a bug if it doesn't work as it could.
The software should handle clock changes (jumps).

How can the software handle a box booting with the clock wrong if there is no DVB or network clock source. Please explain how you think that is a software bug.

 

[Huevos]

If I want to set a relative timer for 10mins I would set it for 10mins.
The current (and future) state of the clock is irrelevant to a relative timer.

This is what you don't understand. The on board timer is not accurate. After several hours it is out by several minutes.

 

[Joe_90]

Neither you or @Huevos seems to be getting the point. As regards the hardware timer mentioned (@Huevos), none of my boxes, apart from one (mbtwin), ever had an issue waking up at the correct time after a period in deep standby, so the countdown timer (ticker) worked ok.

The issue with the schedule timer code in ABM and OpenTV EPG modules seems to be that the calculation of the relative timer is done by subtracting the box/system time (which is in the past) from a stored scheduled epoch time when the ABM/EPG should run and, occasionally, instead of getting the correct interval of x minutes to trigger the job is getting an interval of x + (the time elapsed since the box was last shut down).

Here's a worked example:

The schedule for ABM on my test box says it is to trigger today at 18:00 local. That's 7 September 2025 at 18:00, which is 1757264400 seconds in unix epoch time. The box was last shut down on 6 September 2025 at 18:05 local which is 1757178300 seconds unix epoch time at which point the clock is correct from the transponder or NTP and that time is stored in the fake-hwclock. A PowerTimer is set to boot the box at 17:45 every day and shut it down at 18:05.

If all goes well and the box gets the correct local time from NTP when it boots today 7 September at 17:45 the box will have a system time of 1757263500 seconds epoch time plus some elapsed seconds. The ABM schedule code is run just before any transponder is tuned and an relative timer is set for (1757264400 - ~1757263500 = ~900 seconds which is 15 minutes). All correct because the box time had been set correctly before schedule evaluation.

If the box fails to get NTP time before the ABM schedule code is run and before any transponder is tuned the box will have fake-hwclock time and the calculation is (1757264400 - ~1757178300 = ~86100 seconds which is 23 hours and 55 minutes). So, in this case, a relative timer is set which will never elapse unless the box is left active or in normal standby for almost 24 hours.

The problem (as I see it) is that the ABM/EPG schedule code is run once at system start (when it determines the next run time) before any transponder is tuned and I don't see any examples of it running again until the system is put into shutdown. 99.9% of the time, the box has the correct time from either NTP or once a transponder is tuned (from a reliable tuner source), so - within a minute of enigma start. Recording or zap timers don't seem to be affected as (again - assumption on my part) they seem to use absolute timers.

It's not a widespread problem as most users just have their boxes in normal standby or are using them for long periods. In the case of the OP (@CRMS) or my particular test box setup the issue occasionally arises, but it is an error and has been happening on Vix since the introduction of fake-hwclock some seven or eight years ago. Before that, I think any timer evaluation was held off until the box got a time from either transponder or NTP.

 

[birdman]

The issue with the schedule timer code in ABM and OpenTV EPG modules seems to be that the calculation of the relative timer is done by subtracting the box/system time (which is in the past) from a stored scheduled epoch time when the ABM/EPG should run and, occasionally, instead of getting the correct interval of x minutes to trigger the job is getting an interval of x + (the time elapsed since the box was last shut down).

So, a software bug. Or perhaps a logic bug, with the bug implemented in the software.

 

[Joe_90]

So, a software bug. Or perhaps a logic bug, with the bug implemented in the software.

I can't agree with your conclusion that this is a software bug. It is a an error caused by bad input data - the wrong system time (so - GIGO). It's a system issue which arises because of using an untrustworthy system time source, namely fake-hwclock. Prior to the introduction of that, enigma would have a system time of 1/1/1970 when starting if no NTP sync was done and would wait until it got a plausible time before checking scheduled events etc.
The solution to this occasional issue may lie in detecting if the system time is flagged as being based on fake-hwclock and unsetting that flag once a transponder or NTP time is set before evaluating scheduled timers, maybe? But, I'm not a programmer - more a systems guy (retired!). I think OpenATV has code which checks if system time has changed substantially and re-evaluates timers etc. in that event. I haven't really done any testing on OpenATV, so I can't verify but I get the impression that time handling options in that code are more complex or varied.

 

[CRMS]

Gosh. And many thanks. Way over my head reading it through once!
I'm just using Freesat EPG and have removed the other EPGs.
It appears that after start up, the Freesat EPG updates fairly quickly.
As it is a time issue, is there a simple work round eg have a longer interval between start up and ABM running? to ensure the box has picked up satellite time and implemented it.

 

[abu baniaz]

@CRMS, I suggest that you remove the ABM schedule. Just run it manually when you need to. You can add to extensions menu so it is available to execute via the blue button.

 

[Huevos]

I can't agree with your conclusion that this is a software bug. It is a an error caused by bad input data - the wrong system time (so - GIGO). It's a system issue which arises because of using an untrustworthy system time source, namely fake-hwclock. Prior to the introduction of that, enigma would have a system time of 1/1/1970 when starting if no NTP sync was done and would wait until it got a plausible time before checking scheduled events etc.
The solution to this occasional issue may lie in detecting if the system time is flagged as being based on fake-hwclock and unsetting that flag once a transponder or NTP time is set before evaluating scheduled timers, maybe? But, I'm not a programmer - more a systems guy (retired!). I think OpenATV has code which checks if system time has changed substantially and re-evaluates timers etc. in that event. I haven't really done any testing on OpenATV, so I can't verify but I get the impression that time handling options in that code are more complex or varied.

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.
4. 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.
5. 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.
6. 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.
7. 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.

 

[Joe_90]

@Huevos - all that tallies with my view. The problem with using item 2 is that fake-hwclock always sets the clock to the last shutdown time, so it's always plausible. fake-hwclock runs as almost the first init job. As regards item 7 the only thing I can think of is a flag set at shutdown to indicate fake-hwclock set, which is then unset after any successful NTP sync or succesful DVB time update. When ABM schedule code runs it could check for the presence of the hwclock flag and exit or some other process could check the flag each minute and call ABM schedule. It also affects OpenEPG schedule.