[GiGaBlue QUAD+ PLUS] Will this nuisance ever be fixed?

[leshay]

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.

 

[birdman]

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.

 

[birdman]

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.

 

[ccs]

.... gasp, I hope we won't have to sit a test on this tomorrow.

 

[leshay]

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.

 

[birdman]

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, 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.