View Full Version : [GiGaBlue QUAD+ PLUS] Will this nuisance ever be fixed?
Hi
Long time issue. I have a Power Timer set up to go to deep stand-by after 10 minutes in stand-by.
The Power Timer works as expected, and recordings are made and box returns to deep stand-by afterwards.
However, if I start watching while the box is awake (from the Power Timer wake up), and interact with the box - change channels, watch recording etc then I would have expected the currently running Power Timer would be 'aborted'. Instead, after the allotted time, I get the pop-up about 'am I sure I want to shut down (with a count down)'.
As has been the case many times, if I am not actually there at the time (making coffee/toilet break/many other reasons), then when I get back, the box has gone to deep stand-by.
In a way, the box is just doing what you have made it do. What I am wanting, is that you make it so that if there has been user interaction during the Power Timer operation, that the shut down is aborted - preferably without the on screen alert.
If you have a PowerTimer set to switch from Standby to DeepStandby after 10 mins then that shouldn't be doing anything if you just pop off to the kitchen to make a coffee.
So - how does it get to Standby?
If you have a PowerTimer set to switch from Standby to DeepStandby after 10 mins then that shouldn't be doing anything if you just pop off to the kitchen to make a coffee.
So - how does it get to Standby?
Hi
The Power Timer causes it to go back to deep standby.
If the box is already in deep standby and I wake it up via the power button on the remote, then all is well.
If the box is already in a woken up state (having been woken up to record), then regardless of my interaction with the box - starting a playback, just watching a channel, using the remote to do normal things - then when the recording that woke the box up is finished, I will get the pop up asking if I want to allow shut down - with the count down timer. Normally, I am there at that point and select 'No' and all is well. However, the 'nuisance' comes from the times I am not there to select 'No', in which case the box goes to deep standby and I come back to have to restart the box.
Hi
The Power Timer causes it to go back to deep standby.But only if it is currently in Standby (according to what you said). Which it isnt.
If the box is already in a woken up state (having been woken up to record), then regardless of my interaction with the box - starting a playback, just watching a channel, using the remote to do normal things - then when the recording that woke the box up is finished, I will get the pop up asking if I want to allow shut down - with the count down timer. Normally, I am there at that point and select 'No' and all is well. However, the 'nuisance' comes from the times I am not there to select 'No', in which case the box goes to deep standby and I come back to have to restart the box.That sounds more like a Recording setting of "Deep Standby after recording" (which can, IIRC, be set as a default).
Is that set on your recordings?
Mind you, I thought I'd worked out a fix for that some months ago - what version of Vix are you currently running?
You did....
http://www.world-of-satellite.com/showthread.php?48847-Power-Timer-looping-(and-eventually-crashing-enigma2)&p=384526&viewfull=1#post384526
@Birdman - if the box is woken from deep standby to perform a recording it will return to that state afterwards (which is my default setting). It is separate to the "deep standby after 10 minutes in standby" powertimer. This is what is causing leshay's issue. I presume it's not specific to GB Quad Plus, though?
I would agree that it's a nuisance to have a completed recording powertimer try to shut down the box when it's obviously not in standby due to user interaction after the initial wake time. Your previous fix didn't make it into mainline code, presumably.
You did....
http://www.world-of-satellite.com/showthread.php?48847-Power-Timer-looping-(and-eventually-crashing-enigma2)&p=384526&viewfull=1#post384526
Thanks. That went into Vix 3.2.024.
(I now have an extended version of this to check for streaming clients and cater for someone manually putting th e box into Standby while a playback is running - neither of which obtains here).
All my recordings return to deep standby by default, but Birdman's fix overrides this if I'm viewing/pausing a recording.
Any other "activity" suggests that someone is there to override the shutdown prompt.
@Birdman - if the box is woken from deep standby to perform a recording it will return to that state afterwards (which is my default setting). It is separate to the "deep standby after 10 minutes in standby" powertimer. This is what is causing leshay's issue. I presume it's not specific to GB Quad Plus, though?It's generic.
I would agree that it's a nuisance to have a completed recording powertimer try to shut down the box when it's obviously not in standby due to user interaction after the initial wake time. Your previous fix didn't make it into mainline code, presumably.The fix went in at 3.2.024.
I'm sure it was meant to cover this case (but that doesn't mean that it did...).
I'll have to read through the code...
Still happening in ViX 4 - at least on the Quad Plus in any case.
Thanks. That went into Vix 3.2.024.
(I now have an extended version of this to check for streaming clients and cater for someone manually putting th e box into Standby while a playback is running - neither of which obtains here).
The "No shutdown prompt while watching recording" fix isn't in VIX.
The one you're referring to is "NoSleep-during-Playback", which is a different beast, relating to powertimers.
On further reflexion (and actually reading some code and comments and actually thinking...) the code for this would be in RecordTimer.py.
I do have some (non-standard) code to stop it putting the box to Standby or DeepStandby after a recording if there is a playback in progress. It probably doesn't handle the case of "there has been user-interaction since boot-up". I suspect it should.
If there has been interaction and you want it to shutdown at the end you could put it into Standby.
So I'll look for trapping the case of "Box not in Standby, keys have been pressed".
So I'll look for trapping the case of "Box not in Standby, keys have been pressed".
I much prefer the current solution with recordtimer.py.
All my timers go into deep standby when finished.
If I'm watching a recording, there is no shutdown dialogue.
If I'm watching a recording when the last recording of the day finishes, it's up to me to power down.
Otherwise the box always goes into deep standby automatically.
Are you suggesting that key pressing and playback might be treated the same?
Are you suggesting that key pressing and playback might be treated the same?Sort of.
A possibility is that if there has been any interaction (keypress) then the AutoDeepStandby wouldn't have any effect unless it was in Standby.
Can you see that being a problem?
I can imagine that users with only Satellite tuners may run their box as their only TV source (any TV set would just be a screen) and hence may be using it to watch live TV (!!) rather than recordings.
Mind you - that first requires me to be able to detect a key press - and I'm currently failing on that score...whoops, wait, I can: I was mis-reading my logs.....
... another way (for me) to look at it, if I set up a recording (an interaction) to start in a couple of minutes and it finishes at 03:00am, it won't go into deep standby, and I won't be there to do something about it either.
... another way (for me) to look at it, if I set up a recording (an interaction) to start in a couple of minutes and it finishes at 03:00am, it won't go into deep standby, and I won't be there to do something about it either.Hmmm....an interesting, and common, case....which punts that thought into touch.
I could envisage adding per-recording keypress checkers. This would cater for the above (probably - unless the recording starts while you are still fiddling...) but then leaves you with the case of box on, choose channel for a long session, recording starts, stops, you get prompted...which is where we started.
Another option would be a one-off PowerTimer to switch to DeepStandby after <n> minutes or at the end of the last active recording, whichever comes latest.
... just to clear, I'm not using powertimers, and I'm quite happy for shutdown prompts if I'm just watching tv (because I rarely use the box that way.)
Earlier, I was going to suggest "interaction" to mean anything but live tv, but, as you've suggested, that's probably how satellite owners use their boxes.
So, we have
leshay, with the problem that a recording with AutoDeepStandby set for after the recording can find the box shutdown if he pops off to make tea at the wrong time.
ccs, who want to be able to set a recording with AutoDeepStandby set for after the recording, continue to watch (and press keys) until he goes to bed knowing that the box will shutdown after the recording ends.
These are, I think, incompatible.
However, what about having additional options for Auto(Deep)Standby-if-inactive-since-boot for post-recording options? leshay could then use those. Or could he just not set the AutoDeepStandby for any recording? (I don't set it and have PowerTimers which get the box shutdown within an hour or so of inactivity).
Hi
Just to clarify what I have:
I have an Power Timer set to Timer Type: Auto deepstandby, Only active when in standby: Yes, Sleep Delay: 010, Repeat Type: repeated.
That's all the setup I have. I do not set Timers to have After Event other than Auto.
Hi
Just to clarify what I have:
I have an Power Timer set to Timer Type: Auto deepstandby, Only active when in standby: Yes, Sleep Delay: 010, Repeat Type: repeated.But for that to have any effect something must be putting it into Standby. It's not you, and it's not a Powertimer, so....
That's all the setup I have. I do not set Timers to have After Event other than Auto.It must be that Auto setting, which will put the box back to DeepStandby iff it woke it up to start the recording. Which (on re-reading) is what you wrote in post #1.
So you don't have the problem if the box is already on when a recording starts?
That then becomes a simple(?) matter of ignoring the Auto setting if the box was woken up to record (it knows this) if there has been a keypress since then (which I can code for - in fact I've already got that working). And that shouldn't affect ccs's shutdown after he's gone to bed.
But for that to have any effect something must be putting it into Standby. It's not you, and it's not a Powertimer, so....
It must be that Auto setting, which will put the box back to DeepStandby iff it woke it up to start the recording. Which (on re-reading) is what you wrote in post #1.
So you don't have the problem if the box is already on when a recording starts?
That then becomes a simple(?) matter of ignoring the Auto setting if the box was woken up to record (it knows this) if there has been a keypress since then (which I can code for - in fact I've already got that working). And that shouldn't affect ccs's shutdown after he's gone to bed.
Hi
Yes, that is correct, the only time the issue occurs is when the box has woken up to record and despite me arriving in the midst of it and using the box it still thinks it needs to shut down.
Sounds like you have a good handle on it. Hope it makes it into a new build sooner rather than later.
Hi
Yes, that is correct, the only time the issue occurs is when the box has woken up to record and despite me arriving in the midst of it and using the box it still thinks it needs to shut down.OK. Coding that won't take long.
Testing it will...but I have a plumber arriving tomorrow for a few hours, so might fill my time with it then.
OK. Coding that won't take long.
Testing it will...but I have a plumber arriving tomorrow for a few hours, so might fill my time with it then.I've added code to check for key-presses. that works. I also reckoned it made sense to reset things if it went into Standby. That sort of worked - it wasn't recording the key-press used to come out of standby (or rather it was, but that was immediately wiped out by re-instating the key-press check handler). However, while working out what to do about this I realized that it was all unnecessary! All that is needed is a re-think about what an AUTO handler does at the end of a recording.
The intention of an AUTO handler is to get the box back to where it would have been if there had been no recording. So, it should only ever try to go to DeepStandby if it woke the box up in the first place and the box is now in Standby (since, if it woke it up it would have put it into Standby, so if the box isn't now in Standby then the user must have intervened*, manually or via a PowerTimer). It should never try to put the box into Standby, as if it isn't in Standby it must be either because it was originally "active" or the user has made it so since the recording started. (And it can't be in DeepStandby...).
So the tests for an AUTO handler at the end of a recording just needs to be:
was the box woken up for this recording in the first place?
is the box now in Standby (note that it is allowed to have been out of Standby in between, so you could change some setting - such as add a new timer - put it back to Standby and it should still shutdown)
Although I do need to think about what happens when a second timer starts up which ends after the first one. Ideally the "wasRecTimerWakeup" setting should be carried forward. I think it might be already, but it might be tricky to confirm - see footnote.
*We can leave aside the issue of boxes such as my MB-twin that usually wake up too soon and so think they haven't woken up to record and so don't go into Standby in the first place.
.... gasp, I hope we won't have to sit a test on this tomorrow. :)
I've added code to check for key-presses. that works. I also reckoned it made sense to reset things if it went into Standby. That sort of worked - it wasn't recording the key-press used to come out of standby (or rather it was, but that was immediately wiped out by re-instating the key-press check handler). However, while working out what to do about this I realized that it was all unnecessary! All that is needed is a re-think about what an AUTO handler does at the end of a recording.
The intention of an AUTO handler is to get the box back to where it would have been if there had been no recording. So, it should only ever try to go to DeepStandby if it woke the box up in the first place and the box is now in Standby (since, if it woke it up it would have put it into Standby, so if the box isn't now in Standby then the user must have intervened*, manually or via a PowerTimer). It should never try to put the box into Standby, as if it isn't in Standby it must be either because it was originally "active" or the user has made it so since the recording started. (And it can't be in DeepStandby...).
So the tests for an AUTO handler at the end of a recording just needs to be:
was the box woken up for this recording in the first place?
is the box now in Standby (note that it is allowed to have been out of Standby in between, so you could change some setting - such as add a new timer - put it back to Standby and it should still shutdown)
Although I do need to think about what happens when a second timer starts up which ends after the first one. Ideally the "wasRecTimerWakeup" setting should be carried forward. I think it might be already, but it might be tricky to confirm - see footnote.
*We can leave aside the issue of boxes such as my MB-twin that usually wake up too soon and so think they haven't woken up to record and so don't go into Standby in the first place.
Hi
Now, several updates later, I still have the same issue. Perhaps your changes haven't yet made it into an update, but in case they have, I still have exactly the same dialog that the box is about to shutdown at the behest of a Timer.
Hi
Now, several updates later, I still have the same issue. Perhaps your changes haven't yet made it into an update..No, they haven't. I was having problems with various bits of logic around this (e.g. see #18 (http://www.world-of-satellite.com/showthread.php?51258-Will-this-nuisance-ever-be-fixed&p=399564&viewfull=1#post399564), plus others that popped into my head from time to time).
I did run into my notes about it yesterday...
I'll have another look.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.