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

[birdman]

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.

But I think I can see how it goes wrong.

The only PowerTimer I had in place was the one I was testing. This had an end action of wakeup-to-standby.
So the box was woken up by a PowerTimer, and /tmp/was_powertimer_wakeup was created at start-up.
The only PowerTimer in place was now past its begin time, so that never got to StateRunning
and was just rescheduled for 1 day ahead.
I then edited that timer (or deleted it and created a new test one).
When this did get to StateRunning it saw /tmp/was_powertimer_wakeup and so set the PowerTimer to be wasPowerTimerWakeup. Consequently this PowerTimer was ignored.

I can't see why a PowerTimer to go to DEEPSTANDBY would ever be ignored if the box had been woken up by a PowerTimer.
(Nor why only the first PowerTimer to get to StateRunning could ever get this setting).

Suggestions welcome....

 

[Joe_90]

Ok - I'm now confused! Before I copied in your new PowerTimer.py I decided to test the existing code to see if I could trigger an error and reproduce it consistently. I had assumed that when this issue arose on my system a running recording was messing with my daily PowerTimer and decided to test two slightly different scenarios. Please note that my daily PowerTimer wakes the box from deep standby and then performs some actions and then returns the box to deep standby.

1. I set a daily PowerTimer to wake the box from deep at 09:20 and run ABM at 09:30 and put the box into deep standby at 09:35. I also scheduled a recording to start at 09:30 and finish at 09:45 thus holding off the end time of the PowerTimer. This all worked as expected (box booted from deep) and the return to deep was held off until the recording finished. There was no alteration in the PowerTimer start or end times for tomorrow.

2. I set a daily PowerTimer to wake the box from deep at 10:20 and run ABM at 10:30 and put the box into deep standby at 10:35. I started a recording beforehand at 10:15 with a finish time of 11:00 and the box was recording in standby mode when the PowerTimer triggered. Again, this all worked as expected and the return to deep standby was held off until the recording finished. No alteration to the PowerTimer start or end times for tomorrow.

I now can't figure out what scenario will mess with the timers

 

[Huevos]

If the box is recording at the Reboot time, the Reboot is delayed until the recording is completed.

What does "at the reboot time" mean?

 

[birdman]

What does "at the reboot time" mean?

I think it means shutdown (to Deep Standby).

 

[birdman]

I now can't figure out what scenario will mess with the timers

The OP has the PowerTimer to do the reverse of yours.
It shuts the box down at the beginning and starts it up (to standby) at the end.

 

[birdman]

I now can't figure out what scenario will mess with the timers

The reason yours showed no problem is because for a PowerTimer that wakes up then shuts down the timer is always "alive" on the system. So the final do_activate() call restores the correct (original) begin and end times when it reaches StateEnded.

For a PowerTimer that shuts down then wakes up the backed-off begin time will be written to pm_timer.xml as the system shuts down. When the system wakes up again it believes this backed-off time is the intended begin time.

My changes just ensure that the intended (original) begin time is always written to the file (even if the working value has been backed-off).

 

[Joe_90]

The reason yours showed no problem is because for a PowerTimer that wakes up then shuts down the timer is always "alive" on the system. So the final do_activate() call restores the correct (original) begin and end times when it reaches StateEnded.

For a PowerTimer that shuts down then wakes up the backed-off begin time will be written to pm_timer.xml as the system shuts down. When the system wakes up again it believes this backed-off time is the intended begin time.

My changes just ensure that the intended (original) begin time is always written to the file (even if the working value has been backed-off).

I was pretty sure I had the scenario where my wake up / shutdown PowerTimer got messed up at some point where the shutdown time was being "held off" for some reason and the next wakeup time was altered. Maybe I'm mis-remembering when I last had the problem and this issue has been fixed? I only use PowerTimers in a "wakeup-then-shutdown" fashion, so I wouldn't even consider using them the opposite way around. @Orlandox PowerTimer was that way around. I hadn't realised that @CRMS was using PT in that fashion also.

 

[birdman]

I was pretty sure I had the scenario where my wake up / shutdown PowerTimer got messed up at some point where the shutdown time was being "held off" for some reason and the next wakeup time was altered. Maybe I'm mis-remembering when I last had the problem and this issue has been fixed?

It could have been a long time ago, and this was why the real_begin and real_end fields were added (but that was nearly 10 years ago).

[PowerTimer]Fix proceeding start time bug. · OpenViX/enigma2@3201bb1

Code by Birdman

github.com

[PowerTimer] fix wakeup bug · OpenViX/enigma2@2413119

thx Birdman

github.com

The code that is currently there only fixed it for the way round that you have your PowerTimer.

 

[Joe_90]

It could have been a long time ago, and this was why the real_begin and real_end fields were added (but that was nearly 10 years ago).

[PowerTimer]Fix proceeding start time bug. · OpenViX/enigma2@3201bb1

Code by Birdman

github.com

[PowerTimer] fix wakeup bug · OpenViX/enigma2@2413119

thx Birdman

github.com

The code that is currently there only fixed it for the way round that you have your PowerTimer.

Thanks @birdman - I only use PowerTimers in the way I described, but I could have sworn I had the issue of a "wandering" start time at some point in the past year. In any case I couldn't provoke the issue with the current image. I'll test using your new code later today to ensure no new issues.

 

[birdman]

It occurred to me overnight that there might be a problem with the change. The real_begin and real_end fields might be left around even when the timer is rescheduled for its next run. This would cause problems.

I'll look into whether that is the case. (It might not be - the do_activate() code which is already there may handle it).

 

[Joe_90]

It occurred to me overnight that there might be a problem with the change. The real_begin and real_end fields might be left around even when the timer is rescheduled for its next run. This would cause problems.

I'll look into whether that is the case. (It might not be - the do_activate() code which is already there may handle it).

I'll await your findings before I test the new code.

 

[birdman]

It occurred to me overnight that there might be a problem with the change. The real_begin and real_end fields might be left around even when the timer is rescheduled for its next run. This would cause problems.

No, it's OK, but for a much simpler reason that the original do_activate() code handling it.

Since the code now only ever writes the requested begin/end times to file then for a timer that does a shutdown with a later wakeup, when it wakes up it will read the requested begin/end times and never know that there was any backoff that changed the internal timer.

In the process of looking I did find a test that was being done twice in the space of ~6 lines, so I've combined the actions to follow just one test.

That is in the newly-attached code.

I've also figured out why the code ignores a DEEPSTANDBY timer if wasPowerTimerWakeup is set.
If you set a DEEPSTANDBY timer with an end action (as the OP did in this thread, and I've been testing with) then manually wake up the box before the auto wakeup then the timer will fire.
This line stops it going straight back to DEEPSTANDBY (via a query).

There's (at least) a logic fault here, but it's not directly connected to the OP's problem, so I'll treat it separately (the code has been there for ages).
The issues are:

• You could have multiple timers for DEEPSTANDBY, but only the first to run would ever see it (might not be a real problem, as having two DEEPSTANDBY timers with overlapping times would make no real sense).
• If the box wakes up normally the was_powertimer_wakeup file will hang around until the next timer is Running. This means that the next run of any timer will be ignored if it is a DEEPSTANDBY one (unless the system is rebooted in between). [I hit this several times in testing]

The wakeup flags in /tmp (there's a recording and cec one as well) need to be cleared somehow.

 

[Joe_90]

No, it's OK, but for a much simpler reason that the original do_activate() code handling it.

Since the code now only ever writes the requested begin/end times to file then for a timer that does a shutdown with a later wakeup, when it wakes up it will read the requested begin/end times and never know that there was any backoff that changed the internal timer.

In the process of looking I did find a test that was being done twice in the space of ~6 lines, so I've combined the actions to follow just one test.

That is in the newly-attached code.

I've also figured out why the code ignores a DEEPSTANDBY timer if wasPowerTimerWakeup is set.
If you set a DEEPSTANDBY timer with an end action (as the OP did in this thread, and I've been testing with) then manually wake up the box before the auto wakeup then the timer will fire.
This line stops it going straight back to DEEPSTANDBY (via a query).

There's (at least) a logic fault here, but it's not directly connected to the OP's problem, so I'll treat it separately (the code has been there for ages).
The issues are:

• You could have multiple timers for DEEPSTANDBY, but only the first to run would ever see it (might not be a real problem, as having two DEEPSTANDBY timers with overlapping times would make no real sense).
• If the box wakes up normally the was_powertimer_wakeup file will hang around until the next timer is Running. This means that the next run of any timer will be ignored if it is a DEEPSTANDBY one (unless the system is rebooted in between). [I hit this several times in testing]

The wakeup flags in /tmp (there's a recording and cec one as well) need to be cleared somehow.

Thanks @birdman - I'll test your new version. As an aside, I have a permanent "goto DEEPSTANDBY" timer running which checks if the receiver is in normal standby for more than 20 minutes. I'm conscious of that timer running so, if I ever use another PT which wakes the box to standby and then subsequently shuts it down, I do it within a 20 minute time window.

 

[Joe_90]

Thanks @birdman - I'll test your new version. As an aside, I have a permanent "goto DEEPSTANDBY" timer running which checks if the receiver is in normal standby for more than 20 minutes. I'm conscious of that timer running so, if I ever use another PT which wakes the box to standby and then subsequently shuts it down, I do it within a 20 minute time window.

New version tested ok for me - no issues noted. The new PT which I set up to boot at 12:10 each day and go to deep standby at 12:20 was interrupted (deliberately) by a running recording. I did this to ensure that when the PT eventually did shut down the box that the initial timers were not corrupted. However, my other running PT, which shuts down the box after 20 minutes idle in standby, was the one actually which shut the box down. This meant that the new PT never advanced the next run date to tomorrow (8th). But after I looked at the PT in the timer GUI and saw that the PT still had the date of the 7th, the date was advanced when I reviewed the log on-screen. Something in the code seems to have advanced the date while I was looking at the log.

 

[birdman]

This meant that the new PT never advanced the next run date to tomorrow (8th). But after I looked at the PT in the timer GUI and saw that the PT still had the date of the 7th, the date was advanced when I reviewed the log on-screen. Something in the code seems to have advanced the date while I was looking at the log.

Yes, I've seen that too.
The timers are kept in memory and only get written to file at certain points (when a timer reaches the end point; at shutdown). So the file contents are unlikely to be up to date.

But I've also seen a shutdown/wakeup timer that has passed still show today's date in the menu. Restarting the GUI wrote tomorrow's date into the pm-timer.xml file and showed it in the menu, so it was always correct.

 

[birdman]

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.

I've now tested that bit too.
The original code did work (the loop taking begin to end does happen, but does stop). If you look at such a backed-of timer in the menu then both its begin and end time have been backed-off into the future, even though it is only the end time being delayed.

The fix works, and leaves the menu display with the correct begin time.

 

[Joe_90]

@birdman - have you committed the PowerTimer.py changes? I haven't seen them in subsequent builds.

 

[birdman]

No. I just remembered about it this morning and have left myself a note to get it done later today.

 

[birdman]

PRs submitted:

https://github.com/OpenViX/enigma2/pull/1205
https://github.com/OpenViX/enigma2/pull/1206

 

[Huevos]

@Joe90 these changes are in 6.8.004.001. Can you please verify it works ok please.