Zap timer problem

[IanSav]

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]

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]

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]

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]

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

You'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]

While the iron is hot, can we code a fake recording timer so we don't have to use EPG refresh plugin?

[birdman]

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]

How do you use a power timer to activate a channel without switching on the display on the receiver?

[adm]

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]

@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]

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]

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]

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]

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]

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.