Sleep Timer Function on Vix images

[birdman]

Should a power timer check for a recording in progress and wait until it has finished?

Yes. Although for some reason I don't understand a DEEPSTANDBY PowerTimer won't do anything if the box was woken up by a PowerTimer. Mind you, the code to check that has a bug in it (it checks for the presence of one file, then reads a different one).

In the past I've turned the TV on in the morning and found a "stuck" power timer wishes to shut down you box message.

That might have been fixed several months back by this:

https://github.com/OpenViX/enigma2/commit/eea4bfed71646b8661709620768c9ca1c8426972

The timer log suggest that a failed non-repeating power timer is not triggering any preparatory checking whereas a successful non-repeating power timer has multiple lines in the log file suggesting that it has triggered a multi-stage (checking?) routine.

Agreed. I've just had a failure that is now being reported as "done", but at no point did the activate() function ever get called (I'd added a debug statement at the start).

The 100s back-off for the successful ones may well be significant - it's the MaxWaitTime for a Timer object.

[birdman]

I think I can see the problem.

The timer.py code has this:

                min = int(now) + self.MaxWaitTime

                self.timer_list and self.timer_list.sort() #  resort/refresh list, try to fix hanging timers

                # calculate next activation point
                timer_list = [ t for t in self.timer_list if not t.disabled ]
                if timer_list:
                        w = timer_list[0].getNextActivation()

                if int(now) < 1072224000 and min > now + 5:
                        # system time has not yet been set (before 01.01.2004), keep a short poll interval
                        min = now + 5s

                self.setNextActivation(now, min)

So it sets a time 100s in the future for the next run (min), then looks at the earliest timer it has to handle (w).
But it always set the next activation to min. Having determined w it does nothing with it at all!
I think it should be setting min to w if w is < min....
Without this the PT will often appear to be passed by the time the timer activation code looks at it.

I'm about to try this out.....and it seems to have fixed things.

[birdman]

Pull request sent:

https://github.com/OpenViX/enigma2/pull/193

[birdman]

In case anyone is wondering, it's quite possible (likely) that this has been having an effect on other timers as well.
However:

• repeating PowerTimers will eventually run anyway, and work
• Recording Timers run from a different timer list (using the same code), but if these get seen late they just start the recording anyway (unless the slot has already ended..)

so the effect would have been just a slightly late start with no noticeable effect.

It seems to be only one-off PowerTimers that get chopped if their time has passed before they get looked at.

[adm]

Pull request sent:

https://github.com/OpenViX/enigma2/pull/193

I've changed the timer.py code as per your changes and run it on my box

3 times in a row the box went into standby at the expected time - all OK

I set a recording for 20 minutes and set a non-recurring go to standby power timer to trigger half way through this recording. At the half way point (plus the countdown time) the box entered standby. The box can record in standby and continued with the recording - all OK.

I repeated the recording test with a non-recurring go to deep standby power timer set to trigger half way through the recording. At the trigger time the power timer changed its reporting from 'waiting' to 'about to start' and reported a new (start) time that coincided with the end of the recording. As the recording finished the power timer cut in and the box went to deep standby - all OK

It looks as if the bug is fixed

[birdman]

It looks as if the bug is fixed

The unusual 100s between timer stages on the one successful run I recorded was the key to tracking it down.

[birdman]

Following on from the bug mentioned in #31 I've submitted a Pull Request to get the correct filename checked when checking to a PowerTimer wake-up.

https://github.com/OpenViX/enigma2/pull/195

[RolandSaller]

With build 28 the power timers are working as ecpected. Thanks for the fix

[Joe_90]

I've changed the timer.py code as per your changes and run it on my box

3 times in a row the box went into standby at the expected time - all OK

I set a recording for 20 minutes and set a non-recurring go to standby power timer to trigger half way through this recording. At the half way point (plus the countdown time) the box entered standby. The box can record in standby and continued with the recording - all OK.

I repeated the recording test with a non-recurring go to deep standby power timer set to trigger half way through the recording. At the trigger time the power timer changed its reporting from 'waiting' to 'about to start' and reported a new (start) time that coincided with the end of the recording. As the recording finished the power timer cut in and the box went to deep standby - all OK

It looks as if the bug is fixed

That's happened to me in the past with a recurring daily Powertimer which is set to boot from deep at 06:00 and go back to deep at 06:10. If the time coincides with a recording already in progress (usually F1 grand prix from Asia) the Powertimer gets pushed out until the end of the recording and a new daily start time is set, which could after 09:00 depending on the length of the recording - which is not correct. I think @birdman tried to fix this some time ago (like 18 months ago!) but it doesn't quite seem to work as intended.

[adm]

That's happened to me in the past with a recurring daily Powertimer which is set to boot from deep at 06:00 and go back to deep at 06:10. If the time coincides with a recording already in progress (usually F1 grand prix from Asia) the Powertimer gets pushed out until the end of the recording and a new daily start time is set, which could after 09:00 depending on the length of the recording - which is not correct. I think @birdman tried to fix this some time ago (like 18 months ago!) but it doesn't quite seem to work as intended.

I think it is working.

I've just set a repeating go to deep standby at 14:30 but had an ongoing recording that finished at 15:05
The timer set a new start time for 15:05 and at that time the box went to deep standby - the timer waited for a recording to finish.
On starting up the box again I checked the repeating deep standby timer it had reverted back to a start time of 14:30, as originally configured.

I'm not seeing with build 28 that the start time is permanently changed.

[birdman]

I think @birdman tried to fix this some time ago (like 18 months ago!) but it doesn't quite seem to work as intended.

That was a separate issue. For that, if a repeating timer were deferred it remembered its original time-slot and used that for the next occurrence when it finally ran. As far as I'm aware that is till OK (it was working when I wrote the code...).