PDA

View Full Version : [ViX_Misc] Zap timer problem



nekrub2
27-01-19, 22:45
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.58227

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
27-01-19, 22:54
Create an autotimer from the epg, set for everyday, you can zap rather than record.

Tkr001
05-02-19, 21:49
All you really need to do is change the timer value for repeats from daily to the days you want.

ccs
05-02-19, 22:08
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
06-02-19, 01:03
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
06-02-19, 01:06
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
07-02-19, 19:13
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
08-02-19, 02:26
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
08-02-19, 13:11
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
09-02-19, 09:30
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
09-02-19, 10:29
Actually I agree with Ian. Zap timers should have a duration. If not no collision warning will be given.

abu baniaz
09-02-19, 11:19
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
09-02-19, 12:36
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
09-02-19, 14:35
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
09-02-19, 14:41
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.

IanSav
09-02-19, 15:01
Hi,

I believe the underlying issue here is that the term "Zap" timer has been interpreted as two completely different types of timers. What was originally a "Zap" timer I believe could be more accurately termed a "Watch" timer. This "Watch" timer is like a "Record" timer in that it has a start time and an end time. That is, there is a duration for the timer and the timer needs to be sure that a tuner is available and the current service for the whole duration of the event and that there are no conflicts. "Watch" timers should also be displayed on the EPG. Looking at it simply, a "Watch" timer is exactly the same as a "Record" timer except that the current service is changed and a recording file is NOT created.

What we now have as a "Zap" timer can be also be considered to be "Reminder" timer. (I will use of the term "Zap" as it is most commonly known here.) I would view a "Zap" timer to be more like a "Power" type timer not a "Record" type timer. "Zap" timers are instantaneous actions that happen at a time and have no lingering actions or effects, just like "Power" timers. They simply trigger and activate a service change and then go away. There is no mandatory duration, no storage requirements, no after actions etc. There is no need for any timer conflict checking. All that needs to be checked is that there is a free tuner on which source the nominated service. Like "Power" timers "Zap" timers can repeat. For example, switch to the news channel every week day at 18:00. If the "Zap" timer is given a duration it works like a "Watch" timer except that the current service is not locked down like a real "Watch" timer.

A "Zap" timer is almost identical to a "Wakeup" timer except that you also get to specify the start up service. ;) The only special consideration may need to be that a "Zap" timer should not be able to override a "Watch" timer. The priority of "Watch" over "Zap" may need to be controllable via a configuration setting. Alternatively defining a "Watch" timer over a "Zap" timer, or a "Zap" timer over a "Watch" timer, could trigger the timer conflict resolution process.

I believe that what I describe creates a more logical and predictable UI and timer configuration.

Regards,
Ian.

IanSav
09-02-19, 15:05
Hi,

I should note and stress that the "Zap" timer used to work like what we term a "Watch" timer! This behaviour has been broken over time and the "Zap" timer has mutated into what we have now.

I believe that a "Watch" type of timer should be restored.

Regards,
Ian.

birdman
09-02-19, 17:52
I believe the underlying issue here is that the term "Zap" timer has been interpreted as two completely different types of timers. What was originally a "Zap" timer I believe could be more accurately termed a "Watch" timer. This "Watch" timer is like a "Record" timer in that it has a start time and an end time.That seems unlikely, given that there is no way to set an end time for a Zap timer. I don't recall there ever being so (but never use them, so ....).

birdman
09-02-19, 17:53
There is no need for any timer conflict checking.Yes, there is. As you need to have a tuner available for the time at which the Zap occurs.

birdman
09-02-19, 17:56
I believe that what I describe creates a more logical and predictable UI and timer configurationYou've omitted the requirement to prevent the user changing channel while this "Watch" timer is running. Remember - they have a timer running which has reserved the tuner.

abu baniaz
09-02-19, 18:12
While the iron is hot, can we code a fake recording timer so we don't have to use EPG refresh plugin?

birdman
09-02-19, 19:10
While the iron is hot, can we code a fake recording timer so we don't have to use EPG refresh plugin?
What's wrong with using a PowerTimer?

abu baniaz
09-02-19, 19:42
How do you use a power timer to activate a channel without switching on the display on the receiver?

adm
09-02-19, 20:10
While the iron is hot, can we code a fake recording timer so we don't have to use EPG refresh plugin?

One thing I noticed when playing around with them today is that I can set 2 (or more) Zap timers for exactly the same time to change channels/programmes without a conflict warning appearing. Which zap timer will be used to change channels? The first one in the list? OR will the box attempt to change to more than one channel/programme.
(I deleted the conflicting zap timers before they activated so I don't know the answer to the above questions)

abu baniaz
09-02-19, 20:50
@ADM's finding prove that there is an error in the current functionality. There needs to be some conflict awareness.

My understanding is that a zap timer should have a start and an end. User can end it at will without being locked into that zap.

If TV was awake and on another service, it should zap back at end.
If it was in deep or regular standby, it should return to standby unless interrupted by zapping onto another service or a recording kicking in.

bbbuk
09-02-19, 21:00
How about a compromise, if possible?

ie an option to either just zap (and forget about it - ie open ended - do nothing else after this specific zap event) or zap for a specific time period (user defined)?

This would surely resolve both angles? Either way, as ADM has mentioned, a timer conflict check should be done to avoid potential timer conflict!

abu baniaz
09-02-19, 21:41
For a conflict check to be conducted, both start and end times must exist. In the absence of both, that tuner will be unavailable indefinitely for validation purposes.

adm
09-02-19, 21:55
If TV was awake and on another service, it should zap back at end.

I can see that being annoying especially as broadcasters break up films and other programmes with additional C*** five minute “celebrity” programmes. A zap timer with an end time may only see the half way point in a film as the end. I watch the start of a film, go out to make a cup of tea during the 5 minute interval break and while I'm out of the room the box changes channel again. I'm now watching, say, the adverts on this changed channel without realising that the second half of the film has started. I cannot even rewind because the act of changing channels has cleared the timeshift buffer.

I would prefer that a zap timer only changes channels once.



If it was in deep or regular standby, it should return to standby unless interrupted by zapping onto another service or a recording kicking in.


The point is to watch the programme so it can wake up from standby/deep standby and then the user can switch his box back to standby/deep standby after he has finished watching the live broadcast. Alternatively do as I have and set up a power timer to set the box to standby/deep standby after a user defined period of remote control inactivity.

abu baniaz
09-02-19, 22:05
Or....
Set a start up service. When box wakes up, it will go to that service.

You cannot compare/rationalise an infinite item with a finite one. This is what needs to be done for clash detection.

Methodology/logic must be agreed before coding changes.

adm
09-02-19, 22:21
For a conflict check to be conducted, both start and end times must exist. In the absence of both, that tuner will be unavailable indefinitely for validation purposes.

If you already have the maximum number of possible record timers set-up and then you set a zap timer (currently without an end time) it does detect a conflict. This tells you that you cannot zap to that channel because all tuners will be used for other purposes at that (start) time.

Similarly if you have a zap timer set and then try and set record timers requiring more than the available tuners (the zap timer already having reserved one tuner) you also get a conflict warning indicating that you cannot record because a zap timer will attempt to change channels during that recording. (this will need further confirmation as i can see various different setting senarios)

What you may not get without a zap end time is a conflict warning if you set a record timer, say, to start 10 minutes after the zap timer is set to change channels.

I'm not sure that there is an ideal solution to how a zap timer should work and different people may have valid different ideas based on how they use there box on a day to day basis.

The conflict check doesn't seem to work when setting two zap timers for the same time.

ccs
09-02-19, 22:26
Thank goodness I don't use zap or power timers. Way too complex for me.:confused:

IanSav
10-02-19, 01:42
Hi Bbbuk,

How about a compromise, if possible?

ie an option to either just zap (and forget about it - ie open ended - do nothing else after this specific zap event) or zap for a specific time period (user defined)?

This would surely resolve both angles? Either way, as ADM has mentioned, a timer conflict check should be done to avoid potential timer conflict!
Except for the selection of a service this is exactly what a "Wakeup" "Power" timer does. This is why I am suggesting that "Zap" type timers may be appropriately moved to the "Power" timer area.

Regards,
Ian.

IanSav
10-02-19, 01:57
Hi Birdman,

That seems unlikely, given that there is no way to set an end time for a Zap timer. I don't recall there ever being so (but never use them, so ....).
I have used them in the past and they are now broken in that they don't hold the tuner and they don't properly appear in the EPG.

Regards,
Ian.

birdman
10-02-19, 01:59
How do you use a power timer to activate a channel without switching on the display on the receiver?Set a Power timer for time x and a Zap timer for time x+1.

birdman
10-02-19, 02:04
@ADM's finding prove that there is an error in the current functionality. There needs to be some conflict awareness.If you have two tuners (or the two channels can be recorded from one at the same time) then the current conflict code will pass such a situation as OK.


My understanding is that a zap timer should have a start and an end. User can end it at will without being locked into that zap.But they do not. Look at the menu that sets them - there is no option to set a time extent.


If TV was awake and on another service, it should zap back at end.The current code is based on the assumption that there is a user sitting in front of it and all that they wish to do is to ensure the channel switches as a start of a programme they wish to watch. So they don't miss the start.

You are all discussing a sort of timer which does not currently exist but, for some reason, keep assuming that it is what the Zap timer is.

birdman
10-02-19, 02:08
The conflict check doesn't seem to work when setting two zap timers for the same time.It does. It just doesn't do what you want it to.
It's will find sufficient available tuners - it doesn't know that you are trying to view two at once.

birdman
10-02-19, 02:11
Except for the selection of a service this is exactly what a "Wakeup" "Power" timer does. This is why I am suggesting that "Zap" type timers may be appropriately moved to the "Power" timer area.Power timers are there to affect the power state of the box (On, Standby, DeepStandby).
A Zap timer is solely to change the active channel - nothing to do with Power.
Power timers don't have any conflict checks.

birdman
10-02-19, 02:12
I have used them in the past and they are now broken in that they don't hold the tuner and they don't properly appear in the EPG.What release of Vix was this on? Or (roughly) when?

EDIT:
This is the current code in Screens/TimerEntry.py (which explains my 3m01s, as I have a default margin of 3m).

# if the timer type is a Zap and no end is set, set duration to 1 second so time is shown in EPG's.
if self.timerentry_justplay.value == "zap":
if not self.timerentry_showendtime.value:
end = begin + (config.recording.margin_before.value*60) + 1
That code hasn't changed in the last 5 years.

IanSav
10-02-19, 02:15
Hi Birdman,

Yes, there is. As you need to have a tuner available for the time at which the Zap occurs.
As this would be considered a lesser priority timer than a "Record" or "Watch" timer the only conflict checking required would be to see, at the time of the timer firing, if there is a tuner free to display the service. If there is, use it. If not then the current service can't be selected. This is a simplistic conflict check and is all that should be required.

Regards,
Ian.

birdman
10-02-19, 02:20
Also, remember that you can set Zap timers to run in PiP.
(And, IIRC, some boxes can run multiple PiPs at the same time(?)).
So multiple overlapping Zap timers may be OK in some cases.

IanSav
10-02-19, 02:28
Hi Birdman,

What's wrong with using a PowerTimer?
The current "Wakeup" "Power" timer does not have an option to select a service. perhaps we need a "Zap" timer to do this for us? :P ;)

Regards,
Ian.

birdman
10-02-19, 02:39
The current "Wakeup" "Power" timer does not have an option to select a service. perhaps we need a "Zap" timer to do this for us?Already answered that in #34 (https://www.world-of-satellite.com/showthread.php?60846-Zap-timer-problem&p=481720&viewfull=1#post481720) and #37 (https://www.world-of-satellite.com/showthread.php?60846-Zap-timer-problem&p=481723&viewfull=1#post481723)

IanSav
10-02-19, 03:08
Hi,

I am having issues accessing this forum so my answers are not in the correct order.

Regards,
Ian.

IanSav
10-02-19, 03:09
Hi,

So with all the comments and opinions, where are we now?

Regards,
Ian.

birdman
10-02-19, 03:24
So with all the comments and opinions, where are we now?I'm awaiting an answer to post #38 (https://www.world-of-satellite.com/showthread.php?60846-Zap-timer-problem&p=481724&viewfull=1#post481724) and any comments about this from post #35 (https://www.world-of-satellite.com/showthread.php?60846-Zap-timer-problem&p=481721&viewfull=1#post481721):

You are all discussing a sort of timer which does not currently exist but, for some reason, keep assuming that it is what the Zap timer is.

IanSav
10-02-19, 06:14
Hi Birdman,

I don't have a good answer for when it was broken but it was a few years ago.

"Zap" timers used to be what we are now calling a "Watch" timer. You just need to look at the EPG code to see the work that went into handling "Zap" timers that had a duration. They had a green lightning bolt icon and coloured the cell green rather than the red as for "Recording" timers. I believe there is a need and place for all three types of timer ("Record", "Watch" and "Zap").

Regards,
Ian.

birdman
10-02-19, 20:36
I don't have a good answer for when it was broken but it was a few years ago.That'll do. It wasn't any time recently.


"Zap" timers used to be what we are now calling a "Watch" timer. You just need to look at the EPG code to see the work that went into handling "Zap" timers that had a duration. They had a green lightning bolt icon and coloured the cell green rather than the red as for "Recording" timers. I believe there is a need and place for all three types of timer ("Record", "Watch" and "Zap").I'll look, but the code that sets the end of a Zap timer in Vix to start + end_margin is over 5 years old, so I'll never have seen anything else.