Help diagnosing boot issue please

N

nufan

New Member
Guys,

My HDR-Fox T2 spontaneously shutdown the other night - not going to standby - but some other unpowered fault mode.

I had to use the back switch to power cycle it.

Now, most of the time after switch-on, it renters the same fault mode a little after disk spin-up, after some clicking-seeks happen. I’d guess after around 5-10s of disk activity total.

It’s past the Cust FW startup + version messages at that point. It fails when showing the (wrong) time.

I have to wait ~15s before I try to use the power switch to restart again - otherwise it stays in the unpowered fault mode.

After doing this around a dozen times now - I’ve managed to get it back-up for WebIF access twice (there’s a fair amount of disk activity when it’s up - like fsck is running) and I just retrieved the SMART disk info. I’ve seen nothing in the crash reports section.

Can anyone help me work out if it is just the disk that is foobarred from the SMART info? I’m not versed in reading it. Or is there a quick CLI way of confirming?

Otherwise I’d suspect the fan (but the device is v.cold - is there a boot sequence fan spin-up check?), PSU (but device spins-up the disk okay, which I’d have thought would be the max power draw) or motherboard - and probably would just get a replacement unit off eBay to replace (it’s too useful to go without).

Thanks!

p.s It’s a 4TB Seagate Pipeline @ 92%

8F6EF1B6-B651-4710-9E7E-67A43306DC1F.jpeg
 
Thanks for the help BH. Earlier in the evening I’d pulled the cables as it advised (no change) - and baulked at the next steps as I’ve not flashed the firmware for a few years. I was worried about making things worse.

The System Flush Update File step looks next (I can’t see mileage in installing the Humax FW). Do I need to reinstall the CFW after that? i.e. is it destructive to the Custom FW install?

I haven’t seen the Humax user interface so far (Menu isn’t working at least) - so 2 is out - but 3B - de-powering the disk would be useful I think.

[ The only other useful information I have is that I pulled the aerial-input a month or two ago ]
 
Maybe there is a filesystem error. In which case use the latest version of CFW fix-disk in maintenance mode or remove the drive and run fsck (and SMART tests) in a Linux system. One significant item on the SMART stats is the elevated temperature in the past.
 
nufan said:
and baulked at the next steps as I’ve not flashed the firmware for a few years. I was worried about making things worse.
Click to expand...
The obvious thing is to skip to the bit where you disconnect the HDD. If your faults continue after that, you can (probably) discount the HDD as the cause.

Presuming the faults do continue, the inconsistent response suggests it is not firmware related, and in any case you would have difficulty applying any firmware updates.

nufan said:
is it destructive to the Custom FW install?
Click to expand...
No!
 
Black Hole said:
The obvious thing is to skip to the bit where you disconnect the HDD. If your faults continue after that, you can (probably) discount the HDD as the cause.
Click to expand...
My mistake. I missed that. If the issue is still there when the drive is disconnected, then it's unlikely to be a drive issue.
Ignore my earlier post,
 
Thanks both - I’ll use your help tonight (my next chance at doing diagnostics).

It’s roughly one in four reboots that have an extended runtime. I managed to get a couple of runs of ~15m last night (rather than a few seconds) before spontaneous shutdown.

Everything seemed normal then - I noticed humaxtv was the top process (4-5%) if I killed off the disk intensive housekeeping tasks (to extend runtime if needed) and that I could get no Humax user interface up (volume button didn’t trigger the display at all - so nothing non-CFW worked). Disk was working fine then.

I’m hopeful that disconnecting the aerial for ~a month has just screwed up the (non-CFW) Humax elements (time’s not right for a start - it’s Unix epoch start date etc) and the System Flush Update File step might fix.

Thanks BH for allaying my fears….
 
nufan said:
screwed up the (non-CFW) Humax elements (time’s not right for a start - it’s Unix epoch start date etc)
Click to expand...
The correct system time only affects TV Portal, and system time should be corrected as soon as it tunes to a service. If the system time is incorrect even with a tuned service, there is a fundamental problem somewhere.

Menu >> Settings >> Installation >> Factory Reset
 
Well that’s good, but feels embarrassing: I reran the aerial input to the box, and it booted first time. I’ve cycled it a few times since, and it’s acting reliably - now running fixdisk just in case.

As BH said - it acquired the time near-immediately over-the-air.

Although it appeared to have two modes (immediate shutdown + ~15m of runtime then shutdown) - the immediate fault mode didn’t seem to run long enough for it to acquire much data off the disk - so I’m speculating it was something to do with the clock being out (Invalid certs? File-system showing future dates?).

I first pulled the aerial October 15th - so it’s taken a while to break - and I’m pretty sure the display has shown the wrong time for weeks.

Thanks both for the help and apologies for wasting your time.
 
nufan said:
Well that’s good, but feels embarrassing... I first pulled the aerial October 15th - so it’s taken a while to break - and I’m pretty sure the display has shown the wrong time for weeks.
Click to expand...
Don't be, this is new information. I wasn't aware the system could fall over like that without an aerial, and I don't see why it should or why it should take so long to show up. The previous state of knowledge is here: Things Every... (click) section 6.

The lack of aerial as a time source can be plugged using the ntpclient package, which retrieves Internet time and sets the system clock each boot. This can also improve timekeeping, because the Humax firmware allows the system clock to drift by as much as 30s either way before it is corrected from the broadcast source.
 
Last edited:
Thanks BH. The only thing I can add to the collective knowledge-base is I tried to ‘date -s’ manually set the time twice during the ~15m windows. Didn’t stop the power-down in either case - the horse must have bolted by then (I noted it was still on BST on the front display if at all relevant). I’ll pull the aerial tonight and see if I can replicate any more, or whether it’s something that needs disconnect-time to manifest.
 
You must log in or register to reply here.
Back
Top