Timers with "After event" set to "auto" should return the T3 to shutdown if the recording started from shutdown

[prl]

This is about the behaviour of normal (optionally repeating) set timers (either completely manually or from the EPG), not about AutoTimer timers.

The help text for TIMER, GREEN Add says in the help text for "After event":

What action is required on complettion [sic] of the timer? 'Auto' lets the box return to the state it had when the timer started. 'Do nothing', 'Go to standby' and 'Go to deep standby' do ecaxtly [sic] that.

When "After event" field is set to "auto", and the T3 starts from shutdown to make the recording, it does not go back to shutdoen when the recording finishes.

When the field is auto, it should go back to its pre-recording state unless there has been user input from the remote or the USB keyboard. If there has been user input it should stay running. This is similar to how the DP series handles recordings.

The timer definition in /etc/enigma2/timers.xml has afterevent="auto" set in its entry, so the timer seems to be being constructed correctly.

This problem only affects "After event" "auto" recordings started from shutdown. The T3 remains in standby if a recording starts when the T3 is in standby, and it remains running when the recording finishes if the recording started when the T3 was running.

Reproduction steps

Press TIMER, GREEN Add to create a timer. Set the timer to record for 5-10 minutes in 10-15 minutes time. Set to "auto". Press OK to confirm the timer, then put the T3 into shutdown.

Wait for the timer to complete. The T3 stays running, and doesn't return to shutdown.

[Ian Brabham]

This Bug report now depends on the solution of Feature request 107

[Peter Urbanec]

The issue was updated with the following change(s):

• The status has been updated, from New to Delegated.

[Ian Brabham]

Part of the issue seems to be the flag file "/var/volatile/tmp/was_timer_wakeup.txt" always the contains "False".

This appears to be managed by "lib/python/Tools/StbHardware.py" and leveraged from "/proc/stb/fp/was_timer_wakeup" which always seems to be "0".

[Peter Urbanec]

The issue was updated with the following change(s):

• The category has been updated, from Not determined to Application / User Interface.

[prl]

There's also a problem in detecting startups from a power timer.

When Tools.StbHardware.getFPWasTimerWakeup() is called for the first time, it writes either "True" or "False" to /tmp/was_timer_wakeup.txt, and resets /proc/stb/fp/was_timer_wakeup to "0".

However, in PowerTimer.PowerTimerEntry.activate(), the code tests whether /tmp/was_timer_wakeup exists and whether its contents converts to an integer that is then tested by conversion to a Boolean as a precondition to testing whether the wakeup was from a power timer. This is wrong on several levels: it's not clear that the test needs to be done at all, the test is on the wrong file name, and it tests the contents incorrectly. For proper separation of function, this test, if it's necessary at all, should use Tools.StbHardware.getFPWasTimerWakeup().

[Peter Urbanec]

This should be fixed as of 20150128