• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Reboot ending up in standby

af123

af123

Administrator
Staff member
I would like to try and fix the issue where a Humax can sometimes end up in standby following a reboot from the web interface (or RS).

The following sequence always seems to make mine do this and, if it turns out to be the same for other people, it provides a test case that I can try some fixes for.
  1. Set a recording for about 20 minutes in the future (POP is a good channel for this!);
  2. Put the box into full standby.
  3. It will wake up ready to record (either 15 minutes before for AR or just on time for padding);
  4. While it is recording, use the remote to bring it out of standby;
  5. Once the recording is finished, reboot it from the web interface.

Anyone willing to see if there box behaves in the same way? I have some ideas about what's going on but need to do some more testing.
 
I recognise that kind of sequence as one which does it, but I'm pretty sure it does not account for every instance. My units are at your disposal...
 
cdmackay said:
Not sure if this helps, or is even relevant, but my own experience has been that about 1/5 times I perform a reboot from WebIF, the T2 ends up in standby.

In my case, it is never in standby beforehand - the picture is visible on the TV. The reboot appears to work normally, with the Humax logo, right up until the disk is about to spin up. The clunk of the disk powering up occurs, but is immediately associated with the TV going blank, and the normal whine of the disk spinning up does not occur.

Just for whatever it's worth...
Click to expand...
 
That's the same set of symptoms as my sequence generates so hopefully there is a common cause.

When the system starts up following the reboot, the Humax software starts and then pretty much immediately decides it needs to power off again. I have inhibited the power off command and can see the software trying to power off the hardware over and over again. It must be reading something from the micom on boot to make that decision - don't know what yet. Subsequent reboots from this state just repeat the pattern and if I send the power off command to the front panel myself then the box turns off and won't come out of standby again without being turned off and on at the back first.

My suspicion at the moment is that it is caused by the lack of any wake-up timer being present in the front panel at this point. The one that woke it up for the last recording has been used so it's expired or deleted. Usually one would be set when the Humax software puts the box into standby. I should be able to check for this and set one before triggering the reboot.
 
Oh, and with all this messing around and multiple reboots from the web interface, my auto-update event has returned to the schedule!
 
af123 said:
My suspicion at the moment is that it is caused by the lack of any wake-up timer being present in the front panel at this point. The one that woke it up for the last recording has been used so it's expired or deleted. Usually one would be set when the Humax software puts the box into standby. I should be able to check for this and set one before triggering the reboot.
Click to expand...
Sounds good. The best thing to do now is send out a trial patch which prevents exactly that, then soak test and see if any counter-examples show up. Some logging would be handy in case they do.
 
For those of use who leave our boxes on 24/7, I've been pondering whether it would be possible to automatically 'faster reboot' when there is something in the pending schedule (created either by webif or rs). This could happen at some point overnight and/or when it gets 'close' to when the next recording would be due.
This would save having to do it manually, which would be a nice thing.
Any thoughts?
 
webif 1.3.0-6 has the new improved reboot routine in it. I've left the warning text in place on the reboot screen until I'm more confident that it works properly for more than just my boxes.

The script that does the reboot is at /mod/webif/lib/bin/reboot and this is also what is run from the Jim {system reboot} command which things like rs use.
 
prpr said:
For those of use who leave our boxes on 24/7, I've been pondering whether it would be possible to automatically 'faster reboot' when there is something in the pending schedule (created either by webif or rs). This could happen at some point overnight and/or when it gets 'close' to when the next recording would be due.
This would save having to do it manually, which would be a nice thing.
Any thoughts?
Click to expand...
The problem is how does the system know if SWMBO is sitting in front of the telly awaiting the denouement in the show when the system starts to restart - it may be faster but it is not instantaneous.

I added quite a few checks for system in use before Chaseget decides to put the system back into standby but eventually decided a "Don't mute or return to standby between x and y" setting was a good idea
 
af123 said:
The script that does the reboot is at /mod/webif/lib/bin/reboot
Click to expand...
I'm not convinced duplicating 'reboot' executables is a good idea given there is already a /sbin/reboot. I called mine bootlite and stuck it in /mod/bin .
 
MymsMan said:
The problem is how does the system know if SWMBO is sitting in front of the telly awaiting the denouement in the show when the system starts to restart
Click to expand...
1. I don't care
2. I wasn't advocating make it compulsory
 
prpr said:
I'm not convinced duplicating 'reboot' executables is a good idea given there is already a /sbin/reboot. I called mine bootlite and stuck it in /mod/bin .
Click to expand...
The scripts/binaries in /mod/webif/lib/bin are private to the web interface and not in the general path. There's nothing to stop you running them from the CLI but you'd need to specify the full path - there's no confusion with the system reboot command.
At present, reboots from the web interface or via RS will use this. Those from the telnet menu or the shell won't.

I'd be interested to see if anyone else can confirm that this fix works on their box : hopeful :
 
af123 said:
I'd be interested to see if anyone else can confirm that this fix works on their box : hopeful :
Click to expand...

I'm sorry to report the opposite :(

Just added a series to record, hit the reboot chevron at the top; got taken to the reboot page, with the large pink warning.

Hit reboot, humax went off, then the clunk during reboot which indicates it's gone off again. Toggled the power, via remote, came back on fine.

So, for me, no difference at all from the usual "bad" behaviour.

Is there any extra info you would like collecting, when this happens?

Web interface version: 1.3.0-6
Custom firmware version: 3.03 (build 2368)
Humax Version: 1.03.12 (kernel HDR_CFW_3.03)
 
I too have not noticed any difference in the reboot behaviour on either of my HDRs since updating the WebIf.
 
After start for scheduled event, before reboot
Code: 
hwctl d
01 00 00 00 00
Reboot went into Standby
After reboot using remote
Code: 
 hwctl d
00 57 48 40 98
 
Last edited:
You must log in or register to reply here.
Back
Top