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

MAINTENANCE displayed on HDR-FOX T2 in standby

Brian

Brian

Administrator
Staff member
I got up this morning to find one of my HDR's in standby with MAINTENANCE on the front panel display. It was left in standby as usual last night, the LED ring is Amber as it should be.
 
My HDR-Fox T2 1tb was also left in standby & is as normal, i.e. not showing 'maintenance'...We're in the Crystal palace area.
 
The "maintenance" message is something the custom firmware might send to the front panel display, nothing to do with the broadcast chain. Brian is raising this as an observation of some weird behaviour related to the custom firmware.
 
Yes, I have never attempted to put this box into maintenance mode, so I am guessing that something may have happened during the early morning OTA wake up period.
 
I have just tried to bring the box out of standby, there is no response to the remote control, or front panel buttons. There is no access via webif, although I do have access via telnet.

Is there anything that I can do to get it out of this state via telnet, or do I need to switch off at the rear?
 
If you are running CF 2.14 then you may see the maintenance mode menu:
Code: 
    1 - Check and repair hard disk (fix-disk)"
    2 - Clear persistent EPG data.
    x - Leave maintenance mode (Humax will restart).
Type 'x' to restart in normal mode.

If an earlier version and you see the 'humax#' prompt then type 'reboot'.
 
I am running CF 2.14, and have telnet expert mode set, so just have the humax# prompt.
Do you have any ideas how my box managed to get into the maintenance mode without any user intervention?
Is there anything that I should try to do to help diagnose this issue before I try the reboot command?
 
I can't think of any reason why it would enter maintenance mode of its own accord. I notice that a few packages have been updated recently but it seems unlikely that these changes would have caused this problem.
 
I have no idea how that could happen! It only goes into maintenance mode if a particular file exists in flash at boot time. That file is created through a diagnostic, option 1 on the telnet menu or by running fix-disk.

There should be a maintenance log file in /tmp though - does it say anything interesting?
 
Via telnet (a reboot will clear the log)


cat /tmp/maintenance.boot.log

(IIRC)
 
Does this contain anything interesting?

Code: 
Humax HDR-Fox T2 (humax3) 1.02.29/2.14
 
humax3# cat /tmp/maintenance.boot.log
Starting humaxtv process...
  ... pid 168 ...
Waiting for hardware initialisation to complete...
  still waiting...
  still waiting...
  still waiting...
  still waiting...
route: SIOCADDRT: File exists
  still waiting...
  still waiting...
  still waiting...
killall: tinyftp: no process killed
  still waiting...
  still waiting...
DRV_DSC_Init_Begin
SIOCDELRT failed , ret->-1
  still waiting...
  still waiting...
  still waiting...
Stopping humaxtv process...
Stopping dnsmasq process...
Unloading BCM kernel module...
Killing run-and-gun
Killing modinit
killall: modinit: no process killed
Done.
humax3#
 
The uptime command will give an idea of when it happened. I can't think of anything else useful though.
 
Here is the output from uptime
Code: 
Humax HDR-Fox T2 (humax3) 1.02.29/2.14
 
humax3# uptime
15:47:16 up 11:18,  0 users,  load average: 0.00, 0.00, 0.00
humax3#
It looks like it happened at around 4:30 am, which would tie in with the Auto Update event.
 
If the flag were somehow set earlier in the evening without a following reboot, then maintenance mode would be entered when it booted for the auto update event..

We just don't know how the flag got created in the first place.
 
After doing a bit of reading on the WiKi, I think that I have found the answer.
I was looking at the webif diagnostics the day before, and tried some of the diagnostics on the drop down menu, general, epgrange, and diagmode.
I now know that diagmode was responsible for putting the box into maintenance mode at the 4:30 auto update event.
Perhaps diagmode could be renamed maintenancemode to make it clearer what it does.
 
I will just remove it from the drop down list. I think requiring telnet to enter diag mode makes sense since you'll need telnet once in it, and with the telnet menu it's easy enough now.
 
You must log in or register to reply here.
Back
Top