Power Off Timer in Standby = boot to Half-Awake (and stay there)

T

texarkana

Member
I’ve been trying to work out why my HDR-FOX T2 has been “running” when I’d expect it to be in Standby. (Where “running” = WebIf diagnostics show fan has been active; unexpected timestamps in Remote Scheduling; timestamps in activity.log; etc). I’ve had Power On/Off timers set to 17:30 and 23:00 respectively (though I appreciate their use appears to be deprecated on this forum).

Anyway, I’ve realised that on my HDR-FOX T2, if a Power Off Timer occurs whilst the unit is in Standby, then the unit boots to (and stays in) Half-Awake state. (Or is that Delinquent Half-Awake state?). Pressing the power button on the remote control turns the unit On, and pressing it again puts the unit into Standby.

Typically, we turn the unit off (via the power button on the remote control) before going to bed. So if we retire before 11pm, then the box “wakes up” at 11pm, and runs all night.

Many thanks to Black Hole for the suggestion to attach an LED light to the front USB port: it makes it very obvious that the box is not actually in Standby (since as he points out here USB power is not present in Standby).

Please forgive this post if this behaviour is common knowledge. (I didn’t really find any references when I searched the forum).
Humax version 1.02.32; Custom firmware version 3.13; Web Interface version 1.5.2-5
 
texarkana said:
if a Power Off Timer occurs whilst the unit is in Standby, then the unit boots to (and stays in) Half-Awake state. (Or is that Delinquent Half-Awake state?).
Click to expand...
"Delinquent" is meant to mean it is in half-awake when it should be in standby.

I am rather surprised that you say a POWER OFF time occurring during STANDBY results in delinquent HALF AWAKE. I don't recall this being reported before, and it seems decidedly weird, because POWER OFF should only have an effect while the unit is ON.

Please confirm this is what you mean.
 
Yes, that is what I am seeing, and it is completely repeatable (at least for me): set Power On/Off Timers (e.g. to turn on in 15 minutes time, and turn off in 45 minutes time); place unit in STANDBY (using power button on remote control); wait for Power On Timer to boot unit to ON; before Power Off Timer occurs (e.g. midway between On Timer and Off Timer) place unit in STANDBY again (using power button on remote control); wait for Power Off Timer to occur; units enter DELINQUENT HALF-AWAKE.

I see the custom firmware version number on the VFD display as the Power Off Timer causes the unit to boot.
The activity.log file shows "system booted" (not sure of exact mesage, not in front of box at the moment) at the Power Off time.
 
I can confirm this effect.
Sometimes, rebooting via software while it's supposed to be awake results in it going to sleep, until the next Power-off timed event when it wakes up again and then stays on for 24 hours. It's quite annoying.
I've tried poking values at the front-panel controller too, without achieving anything useful. Testing is painfully slow of course.
 
Perhaps this isn't delinquent behaviour then, but expected Humax snafu. I'll add it to Things Every. The work-around would seem to be never to put the unit into standby manually!

We are aware of circumstances where an enforced reboot ends up with it in standby, there is a warning in the WebIF when that is likely to happen.

texarkana said:
though I appreciate their use appears to be deprecated on this forum
Click to expand...
Not exactly "deprecated", but as you have found they're not reliable. For situations where you might want to provide a known awake period to enable processing or fetching new instructions from RS, it's better to use a manually-set reminder schedule, but that's can't achieve a standby period.

A big reason not to turn off is for hardware longevity, but also if you use the HDR as a tuner as well (for convenient access to all the usual facilities including live pause) having it on all the time is simply easier.

The use-case I have (but not got around to implementing) is a nightly brief standby during which a power-cycle is implemented using an external timer. This means lock-ups get resolved unattended, with no more than 24h loss of service – and if the unit has not locked up, then performing a standby first minimises risk of data corruption.
 
Last edited:
A problem I found with using a manually set reminder (from 17:30 to 23:00), was that it appeared to "bag" a tuner. So e.g. in the RS, I got warnings about conflicts if I had two recordings scheduled that overlapped with the reminder. (I confess, I didn't wait to see what actually got recorded). At the moment, I've disabled the Power On/Off timers, and have a short reminder set mid-afternoon weekdays, to pick up any recordings I schedule on RS at lunch time (whilst at work). And we manually turn the box on and off in the evenings. (I appreciate power cycles cause wear, but so do power on hours e.g. in drying out electrolytic caps in power supplies).
 
By the way, one thing I've found with the LED light connected to the front USB port, is that on boot, the light comes on bright, then quickly dims briefly, then comes on bright again. So the 5V power supply appears to be collapsing on start up. Not sure if that's a standard feature, or whether its a sign my power supply is about to die :(.
 
texarkana said:
A problem I found with using a manually set reminder (from 17:30 to 23:00), was that it appeared to "bag" a tuner. So e.g. in the RS, I got warnings about conflicts...
Click to expand...
Indeed it would. I only use it outside normal hours, eg to prevent an OTA scan (which it will still do, regardless of there being no OTAs to find).
 
My idea, if it was one, was that we could intercept any Standby command while running and turn it into a one-off PowerOff timer set to as close to now as possible, whereas a Standby command when not running would proceed as normal.
 
You must log in or register to reply here.
Back
Top