[GiGaBlue UHD QUAD 4K] Programme Recording Alters Power Timer Reboot

[CRMS]

What type of support thread are you creating?

Possible bug

What OpenViX Image build number are you using?

6.7.20

Have you tried re-flashing WITHOUT settings restore?

NO

Have you tried re-flashing WITH a settings restore?

NO

I think I've discovered why the Power Timer Reboot time keeps changing.
If the box is recording at the Reboot time, the Reboot is delayed until the recording is completed. Which makes sense.
But, the Reboot time is also changed from the original set time.
So, it would be good if the software didn't allow the time to be changed.

 

[Joe_90]

I think you may be right in regard to the PowerTimer trigger. I recall this happening in the past but hadn't encountered this in recent releases. I'm away at the moment but will liaise with the devs on testing a fix when I get back.

 

[birdman]

I seem to recall looking at something similar with Power/Recording timers that are delayed in the past.
I'll have a look....

 

[birdman]

I've found the code I was thinking about.
It says:

# If this is the first backoff of a repeat timer remember the original
# begin/end times, so that we can use *these* when setting up the repeat.

So what does this Power Timer actually look like? How is it set-up?

 

[Orlandox]

@birdman , here is an example:

 

[birdman]

@birdman , here is an example:

Hmmmm....interesting.

I would do that as two separate repeating PowerTimers - one for the "go to deep standby" and one for "wakeup".

 

[Joe_90]

Hmmmm....interesting.

I would do that as two separate repeating PowerTimers - one for the "go to deep standby" and one for "wakeup".

Here's my daily PowerTimer, which wakes the receiver up and then shuts it down 15 minutes later. In the intervening time I have EPG update and ABM running. Works 99.9% of the time, but once recently the receiver was running a recording when the PowerTimer fired and the delay in shutdown time (I think until 05.30 when the recording finished) caused all subsequent PowerTimers to start and finish later.

 

[Joe_90]

I've found the code I was thinking about.
It says:

So what does this Power Timer actually look like? How is it set-up?

If you point me at the code I'll have a look. I'm no programmer but I might spot an issue which causes the timers to shift if it can't shut down.

 

[birdman]

I'll take a look at the code tomorrow.

I should be able to set up an equivalent timer and get it delayed.
I suspect the issue is related to this not being a auto-repeated timer. But that's just a guess.

 

[birdman]

In the process of setting up a test I noticed something about this issue that I hadn't realized.
It's not the start time that is changed, it's the end time.

As I noted, I only ever added single events, not ones with extents.

However, when I set one up and the reboot time is delayed by 5 mins then the timer data ends up as expected (for the next day).
The log entry looks like this:

<timer timertype="wakeuptostandby" begin="1767376800" end="1767377100" repeated="127" afterevent="deepstandby" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepea
t="once">
<log code="15" time="1767290209">time changed, start prepare is now: Thu Jan 1 17:59:40 2026</log>
<log code="5" time="1767290380">activating state 1</log>
<log code="6" time="1767290380">prepare ok, waiting for begin</log>
<log code="5" time="1767290400">activating state 2</log>
<log code="5" time="1767290700">activating state 3</log>
<log code="10" time="1767290700">backoff: retry in 5 minutes</log>
<log code="5" time="1767291000">activating state 3</log>
<log code="15" time="1767291000">time changed, start prepare is now: Fri Jan 2 17:59:40 2026</log>
</timer>

Those new times are:

[gmllaptop]: date --date=@1767376800
Fri Jan 2 18:00:00 GMT 2026
[gmllaptop]: date --date=@1767377100
Fri Jan 2 18:05:00 GMT 2026

 

[birdman]

I can see a possible cause.

When a timer reaches StateEnded it is saved, even if it will, in fact, be backed-off because of a recording. If it does have to be delayed (do_backoff() called), then the begin time is incremented, even if it's the end time that is delaying things.

I'll need to set up some cases to check this.

 

[Joe_90]

It's the following begin time that is incremented in any situation that I have encountered. A delay of 30 minutes because of a backoff caused by a recording in progress results in a corresponding delay in the the start/begin time on the next PowerTimer iteration.

 

[birdman]

It's the following begin time that is incremented in any situation that I have encountered.

Yes. I can think I see how that can happen.
But it's the fact that the end time is delaying things that is probably causing the problem.

 

[birdman]

Yes. I can think I see how that can happen.

That part is true...

But it's the fact that the end time is delaying things that is probably causing the problem.

....but that is not. It is the begin time being delayed and the timer updated accordingly. I think that because the timer does a shutdown it never gets reset to the correct value.

It is the case that an end time delaying things will update the begin time (which might end up in a tight loop...), but that's a separate issue, and offhand I can't think of a sensible timer where that would occur.

 

[birdman]

I have reproduced this.
And I think I have a fix.
Which just amounts to always writing the "real" begin/end times to the pm_timers.xml file rather than (as currently) the backed-off values. The problem is that if the action is to shutdown (goto deep standby) then these get left in place so the timer is wrong at the next start-up.

A quick test has worked, but I now have recordings running, so it will be tomorrow before I can do some more tests.

 

[Joe_90]

I'll give it a test also once you have code committed.

 

[Huevos]

I'll give it a test also once you have code committed.

Should be tested before committing.

 

[Joe_90]

Should be tested before committing.

Ok - when available, then

 

[birdman]

Well, that was fun.....
I've tested it, and it works (for me, for the case given here).

However, in the process I came across two other bugs in the code, one of which messed up my testing when I did it in a particular way.

The modified PowerTimer.py is attached.

This is the diff:

113c113,114
<               # begin/end times, so that we can use *these* when setting up the repeat.
---
>               # begin/end times, so that we can use *these* when setting up the repeat
>               # and when writing out the pm_timer.xml file.
119a121
>               # (and delay the correct part)
121c123,126
<               self.begin = time() + self.backoff
---
>               if self.state + 1 == self.StateEnded:
>                       self.end = time() + self.backoff
>               else:
>                       self.begin = time() + self.backoff
151a157
>                               self.log(5, "timer has been cancelled")
154a161
>                               self.log(5, "timer has failed")
225a233
>                               self.log(5, "timer ignored: DEEPSTANDBY with wasPowerTimerWakeup set")
503a512,521
>                       # If we have saved original begin/end times for a backed off timer
>                       # use those values for begin/end, otherwise we'll end up setting
>                       # the next occurrence after a "goto deepstandby" based on the
>                       # backed-off time.
>                       if hasattr(timer, "real_begin"):
>                               begin = timer.real_begin
>                               end = timer.real_end
>                       else:
>                               begin = timer.begin
>                               end = timer.end
516,517c534,535
<                               int(timer.begin),  # noqa: E122
<                               int(timer.end),  # noqa: E122
---
>                               int(begin),  # noqa: E122
>                               int(end),  # noqa: E122

I've added some log info (lines 157 and 161) just to be helpful.

The two other bugs are:

• do_backoff() was updating the begin time, even if it was the end time that was being backed-off. I doubt that anyone has a timer where the end time could be backed-off, but if they did it might end up in a weird loop (that might finally exit once begin reached end).
  That's fixed by lines 123-126.
• If you set a timer with an end event of a wakeup of some sort then if the box stays up until a DEEPSTANDBY PowerTimer runs then it will be ignored! I noticed this as I was running a test then editing the PT to do another test shortly afterwards, and this one was ignored.
  So I've added a log report of this happening (line 233).

Note that I don't know what the fix is for this second bug, as I'm not sure at the moment why the code does what it does.

 

[Joe_90]

Only seeing this at 00:40 - will test in the morning, thanks @birdman.