Zap timer problem

[nekrub2]

Dear all

I would like to use the timer function to ZAP for a given regular transmission, whenever it starts. So I entered from single EPG to the timer settings and filled out what was needed. The transmission is on from MO to SA at the same time.

I was surprised that also on Sunday the box switched to the channel. Obviously the timer does not look up the EPG but just runs like the old video recorders did by data/time.

Is is possible to have set the timer in a way that it only switches when the selected transmission really starts?

I attach a screenshot with my settings.Timer_settings.jpg

Furthermore I noticed that when the timer starts from standby it asks me whether it should go back to standby? This is very odd.

Thanks for your help
nekrub2

[ccs]

Create an autotimer from the epg, set for everyday, you can zap rather than record.

[Tkr001]

All you really need to do is change the timer value for repeats from daily to the days you want.

[ccs]

All you really need to do is change the timer value for repeats from daily to the days you want.

That only runs on the days you specify and at the time you've specified, an autotimer automatically adjusts the times and days when the program is actually broadcast.

[birdman]

I would like to use the timer function to ZAP for a given regular transmission, whenever it starts. So I entered from single EPG to the timer settings and filled out what was needed. The transmission is on from MO to SA at the same time.

"whenever it starts" and "at the same time" are, to me, incompatible. It's one or the other.
To do it whenever it starts, use an AutoTimer to set the relevant Timer(s).

[birdman]

Furthermore I noticed that when the timer starts from standby it asks me whether it should go back to standby? This is very odd.

Do you think it should not prompt and go straight to Standby (whilst you may still be watching) or that it shouldn't prompt and stay active?

[nekrub2]

Hi birdman

The prompt comes just after waking up from standby. At this point it does not make sense to ask, whether I would like to go to standy again. So no prompt at all and stay active.

Best regards
nekrub2

[birdman]

The prompt comes just after waking up from standby.

Ah, that is significant!

At this point it does not make sense to ask, whether I would like to go to standy again.

True.
My suspicion is that this timer, being a Zap timer, is finished as soon as the box wakes up (a recording timer is only finished when the recording ends).
And the default action of a timer when it ends is to ask you about going back to the original state if that was a standby state.
Looks like this should be ignored for Zap timers - particularly since a Zap timer doesn't allow you to set what to do at the end of it (recording times do).

EDIT (for me..):
Looks like the code at RecordTimer.py:620 (...next_state == self.StateEnded...) should check self.justplay and skip the "From here on we are checking whether to put the box into Standby or Deep Standby." blocks if True.

[birdman]

I can reproduce this.
It appears to be result of the zap timer being a repeat one (a one-off zap looks OK - but I'm not sure why* - so setting an Auto Timer, which is what you really want anyway, wouldn't show the problem).
Not quite as simple as I first thought, though, as the log entry for this timer shows:

<log code="12" time="1549627501">stop recording on tuner: (fallback) stream</log>

when it stops. So the logging code needs to handle zap timers better too....

EDIT:
*it seems that the end time for a one-off Zap timer is set to be 3m01s ahead of the start time. So you have to wait that long to get the prompt...so the AT comment is incorrect.

EDIT2:
Fix submitted:

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

EDIT3:
Fix committed:

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

[IanSav]

Hi,

The issue is that a previous change to this code removed the duration element of Zap timers. Without the duration as soon as the Zap timer fires it immediately triggers its after event.

Apart from this after event issue removing the duration from Zap timers also creates the following issues:
- As the Zap timer no longer has a duration it is no longer able to be displayed in the EPG.
- As the Zap timer effectively finishes when it starts other timers can then take over the tuner and change the service while the Zap timer should actually be active.

All these hacks to the code should be reversed. Zap timers should be put back the way they were originally designed and implemented.

Regards,
Ian.

[Huevos]

Actually I agree with Ian. Zap timers should have a duration. If not no collision warning will be given.

[abu baniaz]

Zap timers are shown on EPG even with no end time.

Change that has been committed fixes the reported issue. If there is a better fix, it can be added.

[adm]

Actually I agree with Ian. Zap timers should have a duration. If not no collision warning will be given.

But what duration? For instance I zap to a news programme, watch the headlines at the start and then usually immediately change channels again if there is nothing of interest in those headlines. Isn't the function of a zap time fulfilled immedately it changes channels?

There is a "Enable timer conflict detection" option when setting a Zap timer. Isn't this good enough to show that when setting the time of change the channel there may also be something in conflict for recording/zapping.

[birdman]

The issue is that a previous change to this code removed the duration element of Zap timers. Without the duration as soon as the Zap timer fires it immediately triggers its after event.

As I noted, the ones I set had a duration of 3m01s (possibly just 3m...).
And the issue was what happened at the end of this time.

[birdman]

But what duration? For instance I zap to a news programme, watch the headlines at the start and then usually immediately change channels again if there is nothing of interest in those headlines. Isn't the function of a zap time fulfilled immedately it changes channels?

It should be.
You could argue that you should be able to set the end of a zap timer, to force a free tuner for the whole duration of a programme you wish to watch. But that would be a Watch timer, not a Zap timer, and that is not how the code currently works, nor is it how it is currently intended to work.
Of course, if you had such a timer you'd then have to implement code to disable the user from switching channel without deleting the current "Watch timer". All of which strikes me as wrong.

There is a "Enable timer conflict detection" option when setting a Zap timer. Isn't this good enough to show that when setting the time of change the channel there may also be something in conflict for recording/zapping.

Yes - that is all in place.