Zap timers returning to standby too soon

[bpratt]

Recently updated, and did not restore settings.

I've noticed that when I set up a timer for every day at the same time, and zap to the channel, it does not work.

The T4 stays in standby mode, and does not turn on as it used to in the old 4.4 days

Is this new 'feature' that we didn't know about ?

[MrQuade]

I've noticed that when I set up a timer for every day at the same time, and zap to the channel, it does not work.

The T4 stays in standby mode, and does not turn on as it used to in the old 4.4 days

Can you explain what you mean exactly?

You've set up a daily repeating timer. When are you zapping to the channel? Or are you setting up a zap and record timer?

Is the timer firing from On/Standby/Deep Standby?

[bpratt]

T4 is in standby over night, and not coming out of standby when that timer happens.

The old 4.4 it would come out of standby and go in to On mode and zap to that channel.

I've also noticed that it doesn't come up with a end time when daily timers are being set up.

Sorry my earlier post was extremely vague.

It is a daily repeating timer.

Set up as zap only.

[Grumpy_Geoff]

I've noticed that when I set up a timer for every day at the same time, and zap to the channel, it does not work.

The T4 stays in standby mode, and does not turn on as it used to in the old 4.4 days

I can't check with 20170310 as my T2 and T4 are using (17.5) 20170802, but the behaviour I see is -
come out of standby
zap to timer's service
then immediately popup the '180 second' countdown timer
return to standby

[popup - "A finished record timer wants to set your Beyonwiz Tn to standby mode. Go to standby mode now?"]

You can work around it by using a Power TImer to wakep one minute before the zap timer.

[MrQuade]

I've also noticed that it doesn't come up with a end time when daily timers are being set up.

Again, that do you mean there?
Do you mean that it doesn't ask for an end date? (I think thats only a feature of Autotimers)
Or are you talking about "zap timers" specifically rather than "daily timers"?

[prl]

...
I've also noticed that it doesn't come up with a end time when daily timers are being set up.
...

I believe that that is a feature. I'm not sure its one I entirely agree with, because though "end time" doesn't mean all that much for zap timers themselves, you might want an "after" action attached to the end time.

[bpratt]

I've also noticed that it doesn't come up with a end time when daily timers are being set up.

Again, that do you mean there?
Do you mean that it doesn't ask for an end date? (I think thats only a feature of Autotimers)
Or are you talking about "zap timers" specifically rather than "daily timers"?

I'm getting a bit confused here.

Go in to timers and set up a daily timer to what used to take the T4 out of standby and turn it on, zap to chosen channel and leave it on for the set time.

When it got to the end time, it gave you the pop up to go back in to standby from whence it started up, or optionally stay turned on.

[bpratt]

...
I've also noticed that it doesn't come up with a end time when daily timers are being set up.
...

I believe that that is a feature. I'm not sure its one I entirely agree with, because though "end time" doesn't mean all that much for zap timers themselves, you might want an "after" action attached to the end time.

Yep, exactly.... go back in to standby if nothing it done, i.e. what used to happen, or stay turned on if you want it.

There are days when you simply want it to go in to standby if you aren't there to watch it and forget about it.

[prl]

I've noticed that when I set up a timer for every day at the same time, and zap to the channel, it does not work.

The T4 stays in standby mode, and does not turn on as it used to in the old 4.4 days

I can't check with 20170310 as my T2 and T4 are using (17.5) 20170802, but the behaviour I see is -
come out of standby
zap to timer's service
then immediately popup the '180 second' countdown timer
return to standby

[popup - "A finished record timer wants to set your Beyonwiz Tn to standby mode. Go to standby mode now?"]
...

That's also what I see in 20170310.

In 20160817 (4.4), a daily repeat zap timer with end time disabled does the same thing. A daily repeat zap timer with end time enabled and set to the same as the start time also does the same thing, because it actually turns into a zap timer with the end timer disabled. A daily repeat zap timer with end time enabled and set to the after the start time (even by only one minute) works as you might expect.

It looks like a bug, but not a new one. It's perhaps become more apparent because zap timers are now always "no end time".

[Grumpy_Geoff]

...
That's also what I see in 20170310.

In 20160817 (4.4), a daily repeat zap timer with end time disabled does the same thing. A daily repeat zap timer with end time enabled and set to the same as the start time also does the same thing, because it actually turns into a zap timer with the end timer disabled. A daily repeat zap timer with end time enabled and set to the after the start time (even by only one minute) works as you might expect.

It looks like a bug, but not a new one. It's perhaps become more apparent because zap timers are now always "no end time".

The end time was set by the UI to be 1 second after the begin time. Even when I hacked the after event value to do nothing, the countdown popup still showed. Perhaps it's because the duration was less than a minute, or perhaps zap timers have it baked in.

Code: Select all

<timer begin="1501818300" end="1501818301" serviceref="1:0:1:563:506:1013:EEEE0000:0:0:0:" repeated="127" rename_repeat="1" name="The Morning Show" description="Kylie Gillies and Larry Emdur skip the hard news and present a morning show full of health, lifestyle and fashion advice." afterevent="nothing" eit="50040" tags="" disabled="0" justplay="1" always_zap="0" descramble="1" record_ecm="0" isAutoTimer="0">

[Grumpy_Geoff]

...
Perhaps it's because the duration was less than a minute, or perhaps zap timers have it baked in.

It appears zap timers must have it baked in, as I hacked the end time to be 1 minute after the begin time and the popup was delayed for 1 minute but the 'do nothing' after event action was ignored.

[prl]

...
Perhaps it's because the duration was less than a minute, or perhaps zap timers have it baked in.

It appears zap timers must have it baked in, as I hacked the end time to be 1 minute after the begin time and the popup was delayed for 1 minute but the 'do nothing' after event action was ignored.

The test on the popup is:

Code: Select all

			if self.afterEvent == AFTEREVENT.STANDBY or (not wasRecTimerWakeup and Screens.Standby.inStandby and self.afterEvent == AFTEREVENT.AUTO) or self.wasInStandby:

It's the "wasInStandby" that's being followed in this instance, I think. "WasInStandby" gets reset if there's any remote activity between the start and end of the timer. As the firmware is now, with only one second between them, you'd have to be quick I tested the remote activity reset of "wasInStandby" by editing timers.xml to extend the zap timer end time.

I doubt very much that the repeat status of the timer has anything to do with this issue.

[prl]

The zap timer problem seems to come from this commit merged into the Beyonwiz repository from OpenViX:

Code: Select all

commit 18f37ed9be26e6fbd477eebe8dfbb247c14836b5
Author: Andy Blackburn <andrew.blackburn644@btinternet.com>
Date:   Thu Apr 2 17:29:23 2015 +0100

    [TimerEntry] hide option 'Add End Time' for ZAP timer, as ZAP timer should be used as a reminder that event
    has started, and thus should not have a end time.

The "thus should not have a end time" is just a little bit misleading. The timer does in fact have an end time. It's set this way (#prl# comments added by me, they're not in the code):

Code: Select all

		# if the timer type is a Zap and no end is set, set duration to 1 second so time is shown in EPG's.
		#prl# The above comment is clearly untrue
		if self.timerentry_justplay.value == "zap":  #prl# It's a zap timer
			if not self.timerentry_showendtime.value:  #prl# The end time isn't shown in the settings, which is now always the case
				end = begin + (config.recording.margin_before.value * 60) + 1  #prl# Set the end time to the start time plus the *pre*-padding plus 1 sec

When code and comments disagree, both are probably wrong.

[Grumpy_Geoff]

...
It's the "wasInStandby" that's being followed in this instance, I think. "WasInStandby" gets reset if there's any remote activity between the start and end of the timer.
...

Yep, looks like it. I just then created a 3-min duration zap timer using OWIF, and put the T2 to standby. The T2 awoke and zapped at the designated start time . I then used the remote and the T2 remained in Live TV past the end time.
I tried it again, and this time didn't touch the remote once I'd put the T2 to standby. The T2 awoke, zapped, awaited the timer duration, then popped up the 3-min countdown and subsequently went to back standby.

[Grumpy_Geoff]

...
Yep, exactly.... go back in to standby if nothing it done, i.e. what used to happen, or stay turned on if you want it.

There are days when you simply want it to go in to standby if you aren't there to watch it and forget about it.

Try a test and create the zap timer using the OpenWebif browser interface. Set an end time for a few mins duration so that you don't have to wait too long to see the result.
Put the T4 to standby, and await the begin time. If you don't touch the remote once the zap timer fires, the T4 should go back to standby once the end time has been reached.

When using this for your daily zap timer, you'd set the end time to at least match the program duration.

[peteru]

If you have a fix for the OpenViX bodge, please issue a pull request for the Beyonwiz fork. I want to get the release out soon-ish, so let's not waste time arguing the case with Andy.

[prl]

I could just undo the effect of Andy's changes. That would, I think, take it back to the 4.4 series behaviour.

I'd be happy to do that, but I don't think it really addresses the odd behaviour of zap timers started from standby (or why they should really do anything all that different from zap timers started from shutdown).

If that would do for now, I'll probably have time to do it tomorrow.

[peteru]

I don't mind whether the fix is an improved implementation or a reversion to the previous behaviour. The point I was trying to make is that if you do have a fix, you should not delay it's submission to the Beyonwiz repository because you are trying to get it upstream into OpenViX.

I don't see this problem as a show stopper that would stop the release candidate being promoted to full release. It's an uncommon use case with non-crashing behaviour and a workaround, so the priority is relatively low. If we can get it cleaned up quickly and/or with minimal changes, we could squeeze in another release candidate. It's nice to squash as many known issues as possible when making a release, but I need to draw the line somewhere and get the next release out the door.

[prl]

I wasn't plann8ng on trying to push the change upstream, or not for now, anyway.

[bpratt]

Try a test and create the zap timer using the OpenWebif browser interface. Set an end time for a few mins duration so that you don't have to wait too long to see the result.
Put the T4 to standby, and await the begin time. If you don't touch the remote once the zap timer fires, the T4 should go back to standby once the end time has been reached.

When using this for your daily zap timer, you'd set the end time to at least match the program duration.

Sounds like they are changing things back to the old way, which is great, so I won't worry too much about it now.

I did notice this morning the T4 had on the display REC flashing, even though it had nothing actually recording, other than the zap timer.

There was a end to the zap timer before, so when it got to the appropriate time and we weren't here, and had not used the remote at all, you'd get the pop asking you to do something before the T4 went back in to standby (which the zap timer had come out of).

[Grumpy_Geoff]

...
Sounds like they are changing things back to the old way, which is great, so I won't worry too much about it now.

It may take a few weeks before we see the 17.5 series general release, and it did take you four months to get around to installing the 16.1 series general release

I did notice this morning the T4 had on the display REC flashing, even though it had nothing actually recording, other than the zap timer.

I see different behaviour on my T4's front panel when a zap timer that I set using the UI has fired from standby - I only see the centred text - "A finished record timer wants to set your ...".
If I set the zap timer using OpenWebif and give it a duration, then once it fires the front panel isn't showing any REC indicator. It displays the service picon and tuner, event progress bar & remaining duration, event name, and current time.

[prl]

...

I did notice this morning the T4 had on the display REC flashing, even though it had nothing actually recording, other than the zap timer.

I see different behaviour on my T4's front panel when a zap timer that I set using the UI has fired from standby - I only see the centred text - "A finished record timer wants to set your ...".
If I set the zap timer using OpenWebif and give it a duration, then once it fires the front panel isn't showing any REC indicator. It displays the service picon and tuner, event progress bar & remaining duration, event name, and current time.

I see the same as what Geoff sees: when it comes out of standby, just the normal front panel dieplay for live TV, with no flashing REC ndicator. And then at the actual end of the "no end" zap timer, the "A finished record timer wants to set your..." popup with the same text on the front panel.

[prl]

I've submitted a reversion back to the previous zap timer behaviour that allows zap timers to be given sensible end times.

I've also changed the code that sets the default for "Show end time" so that it is more likely to guess the right setting when the timer
is opened for editing.

[IanSav]

Hi Prl,

I think discussion of how zap timers work and how recording and zap timers interact with the power state deserves a separate topic.

Agreed. I assume you will harvest the relevant posts and move them to an appropriate topic.

Regards,
Ian.

[prl]

Hi Prl,

I think discussion of how zap timers work and how recording and zap timers interact with the power state deserves a separate topic.

Agreed. I assume you will harvest the relevant posts and move them to an appropriate topic.

Regards,
Ian.

The posts that are mainly about discussion of problems with zap timers and how zap and recording timers should operate have been moved to Review of zap and record timers.