[Mut@nt] HD51 OpenViX 5.1.027 will not return to Deep Standby affter recording

[adm]

Hi

Well, I have just looked through all upcoming recording timers and every one has the After Event set to Auto. I haven't ever changed/used that setting in the past.

Have you checked all your Autotimer settings for the same?

 

[leshay]

Have you checked all your Autotimer settings for the same?

Hi

I don't use auto timers at all so that can't be the cause.

 

[birdman]

Have you checked all your Autotimer settings for the same?

POI. AutoTimers just set Record Timers. The relevant thing would be any Record Timer they set.

 

[birdman]

Well, I would have thought that if it can detect that there have been key presses sent to it that it could conclude the box is 'in use' and cancel any pending calls to shut down.until the next time it finds itself in st/by mode.

It restarts any repeating Power Timer on a key press.
But if you don't press any key for longer than the repeat time the Power Timer will kick in.

However, the message you reported was from a Record Timer, so key presses are irrelevant.

 

[adm]

POI. AutoTimers just set Record Timers. The relevant thing would be any Record Timer they set.

I'm aware of that.

I only suggested checking autotimers because leshay said he had checked the "upcoming recording timers". If an autotimer was waiting to set something not yet in the EPG for that channel then he may not have seen an upcoming timer with a go to deep standby option in his list.

 

[birdman]

Hi

Well, I have just looked through all upcoming recording timers and every one has the After Event set to Auto. I haven't ever changed/used that setting in the past.

All I can suggest is that the next time it happens, clear the prompt and immediately connect to the box and take a copy of the timers.xml file in /etc/enigma2.
Then post it here.

 

[leshay]

All I can suggest is that the next time it happens, clear the prompt and immediately connect to the box and take a copy of the timers.xml file in /etc/enigma2.
Then post it here.

Hi

OK, will do.

 

[Mickkie]

Back to the OP issue, I've downgraded to 5.1.026 and Mut@nt behaves as it should:

1. It wakes up from Deep Standby due to a timer;
2. Remains into Standby while recording;
3. Then goes back into Deep Standby once the recording is finished.

Therefore my problem is caused by some change in the latest OpenViX version, 5.1.027. Where/how should I be reporting this?

Re. leshay's problem: If I take the box out of standby during stage 2 above, I will also get a warning that the box is about to return to Deep Standby after the recording is finished and it starts a countdown. Unless I interrupt (exit) the warning the box will eventually go into Deep Standby. I have not noticed spurious warnings for going back into Deep Standby in circumstances like leshay's, i.e. if I power on the box after stage 3 above. However, I have not set up any cron or power timers at all. Only autotimers. I cannot confirm if this behaviour occurs with 5.1.027 - but I expect not, because the box stays on and does not return to Deep Standby.

 

[leshay]

Back to the OP issue, I've downgraded to 5.1.026 and Mut@nt behaves as it should:

1. It wakes up from Deep Standby due to a timer;
2. Remains into Standby while recording;
3. Then goes back into Deep Standby once the recording is finished.

Therefore my problem is caused by some change in the latest OpenViX version, 5.1.027. Where/how should I be reporting this?

Re. leshay's problem: If I take the box out of standby during stage 2 above, I will also get a warning that the box is about to return to Deep Standby after the recording is finished and it starts a countdown. Unless I interrupt (exit) the warning the box will eventually go into Deep Standby. I have not noticed spurious warnings for going back into Deep Standby in circumstances like leshay's, i.e. if I power on the box after stage 3 above. However, I have not set up any cron or power timers at all. Only autotimers. I cannot confirm if this behaviour occurs with 5.1.027 - but I expect not, because the box stays on and does not return to Deep Standby.

Hi

That looks like a suitable candidate for me to look out for - I can't recall specifically whether or not my issues followed that pattern,but maybe so. It is a very possible situation that I could have been in, and many days, I know that I must have taken the box out of a st/by which a recording had set.

If that is actually what is happening, then that must be an 'unwanted feature' or, a 'bug' maybe.
I realize from birdman that it is a Recording Timer calling for the shut down, but under the circumstance above, shouldn't the pending shutdown be cancelled when user takes box out of a st/by which was set by Recording Timer wake up?

 

[birdman]

If that is actually what is happening, then that must be an 'unwanted feature' or, a 'bug' maybe.
I realize from birdman that it is a Recording Timer calling for the shut down, but under the circumstance above, shouldn't the pending shutdown be cancelled when user takes box out of a st/by which was set by Recording Timer wake up?

Well, it's certainly the case that if the recording thinks it was a "wakeup to record" and put the box into Standby then if it isn't in Standby at the end there must have been some user-interaction, so it shouldn't do anything.
I'll see what the code says....

 

[birdman]

Re. leshay's problem: If I take the box out of standby during stage 2 above, I will also get a warning that the box is about to return to Deep Standby after the recording is finished and it starts a countdown.

OK.
That does seem to be what the code will do.
The relevant line is:

 elif self.afterEvent == AFTEREVENT.DEEPSTANDBY or (wasRecTimerWakeup and self.afterEvent == AFTEREVENT.AUTO):

Looks like there should also be a "Screens.Standby.inStandby" check in the parenthetical test as well.

 

[birdman]

I've submitted a PR to fix it:

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

 

[ccs]

Re. leshay's problem: If I take the box out of standby during stage 2 above, I will also get a warning that the box is about to return to Deep Standby after the recording is finished and it starts a countdown. Unless I interrupt (exit) the warning the box will eventually go into Deep Standby.

That's what I want it to do, the last recording of the day goes to deep standby if I've gone to bed.

I always wake the box up from "recording in standby" first thing in the evening, and never use, nor need to use, power timers.

I assume that "after event" set to "deep standby" won't be affected by this PR ?

 

[birdman]

I assume that "after event" set to "deep standby" won't be affected by this PR ?

Shouldn't do - it only affects AUTO ones.

 

[Mickkie]

Shouldn't do - it only affects AUTO ones.

My AutoTimers After Event setting is set at 'Standard' which I think is the default setting and they generate Timers with After Event set at Auto.

I run a couple of experiments (still on 5.1.026) to see what might affect this problem, although I did not enable logging/debugging yet. This is what I observed.

If the tuner is on a channel in the same MUX as that of the next timer when the box goes into Deep Standby, then the box wakes up from Deep Standby, goes into Standby, starts the recording, finishes it and returns to Deep Standby. Just as expected.

However, if the tuner is left on a channel in a different MUX to that of the next timer when the box goes into Deep Standby, the box wakes up, does its recording on the different MUX/channel, but it neither goes into Standby while the recording takes place, nor does it return into Deep Standby when it finishes. Leaving the box on with the disk running and buffering while no one is watching/using it, is not a reasonably expected behaviour.

I don't know if the behaviour is different with Mut@ant boxes with satellite receivers, mine has two terrestrial receivers only. I've only run the above experiment once, after I noticed that the box was not returning to Deep Standby reliably even on version 5.1.026. I'll update again to 5.1.027 to see if there is a difference.

 

[ccs]

I only have terrestrial tuners on my et10k, the 1st recording of the day is always the local weather forecast (bbc1 sd), which is on a different mux to the wake up channel, which I've got set to be bbc1 hd.

As I said before, this works as expected most of the time.

I'll see if I can spot a pattern, although the shutdown channel mux is unlikely to be the same as bbc1 sd.

 

[birdman]

However, if the tuner is left on a channel in a different MUX to that of the next timer when the box goes into Deep Standby, the box wakes up, does its recording on the different MUX/channel, but it neither goes into Standby while the recording takes place, nor does it return into Deep Standby when it finishes.

That sounds interesting - thanks. I'll take a look.

Leaving the box on with the disk running and buffering while no one is watching/using it, is not a reasonably expected behaviour.

You can set a timeout on the disk spinning (and the default is not "never", IIRC). But I suppose if you have timeshift enabled that won't help...

 

[birdman]

If the tuner is on a channel in the same MUX as that of the next timer when the box goes into Deep Standby, then the box wakes up from Deep Standby, goes into Standby, starts the recording, finishes it and returns to Deep Standby. Just as expected.

However, if the tuner is left on a channel in a different MUX to that of the next timer when the box goes into Deep Standby, the box wakes up, does its recording on the different MUX/channel, but it neither goes into Standby while the recording takes place, nor does it return into Deep Standby when it finishes.

The only thing I can see that would cause the latter behaviour is if the Timer type were set to "zap and record". It would prompt you to go to Standby at the end of the recording, but it would do that regardless of whether it had had to switch mux.

 

[Mickkie]

The only thing I can see that would cause the latter behaviour is if the Timer type were set to "zap and record". It would prompt you to go to Standby at the end of the recording, but it would do that regardless of whether it had had to switch mux.

I just checked and the timers are set to "record".

I've updated to 5.1.027, run a test with recordings on the same and on different channel/MUX. The box will not return to Deep Standby or Standby no matter what. It's just left running and because I have Timeshift on, the disk keeps spinning no end. So, this can't be right.

 

[ccs]

I had a problem with going to deep standby ages ago, it was a timeshift setting, although I don't use timeshift.

Maybe this will help.....?

https://www.world-of-satellite.com/...er-a-recording&p=382915&viewfull=1#post382915