Zap timer startup sometimes blocked when user is in MovieSelection

If the system is fully running (not in standby) and the user is in the MovieSelection screen after returning to the MovieSelection screen after playing media or a recording from MovieSelection, and a zap timer starts, the zap timer will not be acted on until the MovieSelection screen is exited or the user plays media or a recording (in which case, the zap-to service is played instead of the selected media file).

The issue is with the test MoviePlayer.instance is not None in RecordTimerEntry.activate(). This appears to be intended to detect whether there is media or a recording being played, but is an incorrect test for that condition, because when media or a recording is played from MovieSelection and MovieSelection is re-entered when the playback is stopped or runs to its end, the MoviePlayer instance is not closed (which would set MoviePlayer.instance to None), but is suspended (not execing) when it opens MovieSelection.

If that test succeeds, the MoviePlayer instance is closed (via a call to NavigationInstance.instance.isMovieplayerActive()). If the MoviePlayer is not actively playing at that time, MoviePlayer will not be in execing state, so the close will be deferred until execBegin() is called on the MoviePlayer instance. The timer begin time is advanced by 1 second, and activate() returns False to indicate that it did not advance the timer state. One second later, activate() is called on the timer again, and if the user remains in MovieSelection, the same error occurs, and the start time for the zap timer keeps increasing until the user exits MovieSelection or invokes MoviePlayer.

When the zap timer's start time is incremented, its new value is not checked against the end time, so the timer's start time can be set to be after its end time.

The correct test for "is media/a recording being played?" is MoviePlayer.instance is not None and MoviePlayer.instance.execing. Then when the zap timer starts, it will only attempt to close the MoviePlayer instance if it is in a state where it can be closed.

With the bug fixed, it also becomes unnecessary to increment the zap timer start time, because the next call of activate() (on any timer) can only occur after the close of the MoviePlayer instance has completed.

This bug does not affect zap timers that start while the system is in standby (even if the user was in MovieSelection having already played media or a recording when standby was entered. This is because of the way that the zap-to service is started is different when standby is exited because of a zap timer.

However, in that case, if there are two or more zap timers that run after startup from standby, the second and subsequent timers will be affected by the bug, since they are started in a now-running system. The most recent report of the problem on the Beyonwiz forum was for this case: the user had 5 zap timers set to run in order to do an EPG refresh and had entered standby while in MovieSelection and after playing media or a recording.

Replication steps

Ensure that MENU>Settings>TV>Recording settings>Behaviour when a movie is stopped is set to Return to movie list.

Set a zap timer a short time into the future. Set its end time a short time after that (e.g. 1min).

Change channel to a different service from the one in the zap timer.

Then before the zap timer starts, MEDIA, and start playing media or a recording, then STOP and return to the media list. Remain in the media list until after the zap timer completes.

After the zap timer starts, [RecordTimer] zapping messages will start appearing in the debug log, one second apart. They will continue while you remain in the media selection screen. The messages will also appear in the timer log, but that's not accessible in the UI without exiting MovieSelection.

When the time has passed the end time of the zap timer, exit the media selection screen. The logging messages will stop, and the zap-to channel will be started.

Restart the GUI to write the timer start and end times to /etc/enigma2/timers.xml, and then check the zap timer's start and end times in the timers.xml file: the start time will be after the end time (this is mostly an issue when the zap timer is set to repeat).

Comments (2)