[ViX_Misc] Sleep Timer Function on Vix images

[TK4|2|1]

Power timers not working on Technomate TM-2T either, since update to 027.


Sent from my iPad using Tapatalk

 

[birdman]

Is it box related because my power timer(s) puts my box (ET10k) into deep standby every night (running 5.0.027)? My other power times works as expected.

But you, like me, use a repeating timer to get it switched off when it's no longer in active use.
It could be that there is an issue with one-off PowerTimers (although I can't see anything obvious in the code that would make one fail while the other succeeds.)

 

[adm]

But you, like me, use a repeating timer to get it switched off when it's no longer in active use.
It could be that there is an issue with one-off PowerTimers (although I can't see anything obvious in the code that would make one fail while the other succeeds.)

You could be correct
I set a one off timer to put the box to go to deep standby 10 minutes in the future
On the run up to the time it reported "waiting" (repeat timers report "running")
When it got to the time the instruction to "go to deep standby" was ignored but the timer reported "done"

The one off timer knows what time it is and changes from reporting waiting to done at exactly the correct time but the box doesn't respond to the request.

EDIT Ignore the above - the box was recording at the time so the one off timer may have been inhibited

Edit 2
I've repeated the experiment when nothing has been recording (and timeshift buffer disabled) and still get the box not responding to the one off power timer.

 

[birdman]

I've repeated the experiment when nothing has been recording (and timeshift buffer disabled) and still get the box not responding to the one off power timer.

I'll mail myself a note to look at it on Thursday.

 

[adm]

I'll mail myself a note to look at it on Thursday.

Just to confirm that 2 of my existing repeat power timers both worked:
I have repeating power timer to put my box into standby at 00:30
I have a second repeating power timer to put the box into auto deep standby after the box has been in standby for 10 minutes

 

[adm]

This power timer definitely didn't work. Set to go into deep standby @08.15

<?xml version="1.0" ?>
<timers>
<timer timertype="deepstandby" begin="1505978100" end="1505978100" repeated="0" afterevent="nothing" disabled="0" autosleepinstandbyonly="no" autosleepdelay="60" autosleeprepeat="once">
<log code="15" time="1505977712">time changed, start prepare is now: Thu Sep 21 08:14:40 2017</log>
</timer>
</timers

The log may be a clue.

I have managed to get a one off go to deep standby and a one off go to standby power timer to work correctly BUT only once for each. If I try setting a second/third/fourth one off timer of the same type afterwards it doesn't work. I don't know of a reason why seemingly randomly I got the one off timers to work. I've tried resetting the box between experiments etc.

Pure wide speculation: One of the timers (deep standby) worked just after midnight where prior to midnight the same type had failed multiple times, and after it worked subsequent attempts failed. The other timer (standby) that worked was the first time I tried it today at approx 8:45pm - afterwards it always failed. Could something be reset at midnight with regards these non working timers or could it be that they fail after a certain time of day - a reference tick timer reset/initialised at midnight and overflows mid evening????? My repeat timer to go to standby and then to deep standby which always works is set for 30 minutes after midnight.


On a power timer that doesn't work a single line is written to the log to say that the time was set to xx.yy hours. The timer then later reports done with nothing else written to the log file. (the line in the log is as in the above quote)

On a one off power timer which works additional lines are written as per the attached image.

 

[birdman]

I've just set one for 23:55, and it worked (although it didn't actually start to process the shutdown until 23:56).

 

[adm]

I've just set one for 23:55, and it worked (although it didn't actually start to process the shutdown until 23:56).

That blows away my wild speculation that it's and end of day related The non-repeating power timers that fail to put the box into standby or deep standby still seem to be triggered at the correct time but apparently don't result in the box doing anything so is the problem in the power timer code block or in the routines that are called elsewhere?

When the one off power timers worked for me the on-screen information and countdown screen appeared approx 1 minute after the time configured - this may be the correct operation. I note that the log for the timer always says the timer is set to "prepare" to trigger 20 seconds before the time configured. Perhaps the correct operation always takes 80 seconds.

 

[birdman]

When the one off power timers worked for me the on-screen information and countdown screen appeared approx 1 minute after the time configured - this may be the correct operation.

hence my 23:55 timer starting shutdown at 23:56.

I note that the log for the timer always says the timer is set to "prepare" to trigger 20 seconds before the time configured. Perhaps the correct operation always takes 80 seconds.

I think the idea is that timers start up 20s early in order to do any preparatory work. For a RecordingTimer this means checking that there is sufficient disk space, etc... I can't see that a PowerTimer has anything to prepare - perhaps the 100s backoff after that (which is what it is) is a source of the problem.

 

[adm]

hence my 23:55 timer starting shutdown at 23:56.

I think the idea is that timers start up 20s early in order to do any preparatory work. For a RecordingTimer this means checking that there is sufficient disk space, etc... I can't see that a PowerTimer has anything to prepare - perhaps the 100s backoff after that (which is what it is) is a source of the problem.

Should a power timer check for a recording in progress and wait until it has finished? 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. This may have coincided with recording a late running film during which my repeat shut down power timers should have worked or alternatively it may have been after I had been watching something delayed by the time-shift buffer and i hadn't zapped channels to get back to real time. If the former maybe a bug. If the latter then the box may be considered to be still recording in order to provide a delayed version. However in both cases not relevant to this ongoing problem as I've seen a non-repeating power timer fail with time-shift disabled.

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.

 

[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 :thumbsup:

 

[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.