Humax Freezing

AlanB

Member
My brand new Humax HDR-Fox T2 has started exhibiting the following symptoms:
1. Freezing up so that it fails to respond to commands from the remote or front panel buttons, so has to be power cycled.
2. Not recording some programmes or only recording part of them.
3. Showing 'no signal' on the attached TV during times when it is frozen.

The background is that I bought this new Humax from Electronic Bargain World via eBay and it arrived last Tuesday 4th November. Due to concerns on this forum about the automatic tuning of Humaxs, I manually tuned the channels from the Craigkelly transmitter. I installed custom firmware v. 1.03.12 and the packages: disable-dsa, disable-ota, poweron-channel, redring and rs, and ffmpeg and webif were installed for me. The Humax has successfully recorded a number of programmes with no problems, including some from Freeview 20 and 704.

But yesterday morning (Sat 8th) things started to go wrong. I had set up timers for 3 consecutive 60 mins programmes on Freeview 20 from 8.00 followed by 2 consecutive Freeview 704 programmes from 11.30. Due to problems recording from Freeview 20 on a recently returned Humax T2000 (reported to this forum), around 10.30 I checked progress. I found that I was getting 'no signal' on the TV, although the bright red ring on the front panel indicated that the Humax was recording. I got no response to signals from the handset. I tried again around 13.00, when recording should have completed, with the same result. I then powercycled the Humax and examined the recordings. The first Freeview 20 recording had terminated prematurely after 28 mins, although it displayed fine. The other two Freeview 20 recordings were showing 0 mins. The two Freeview 704 showed no sign of being recorded at all. I set up a timer on Freeview 20 for a few minutes later, and it recorded fine with no adverse symptoms.

This morning (Sun 9th), I tried again with an 8.00 Freeview 20 timer, with similar bad symptoms as yesterday morning. This time it took 3 powercycles to bring the Humax back to life. During the 2 unsuccessful attempts, the Humax appeared to start rebooting with "System starting" then "Custom FW 3.00" on the front panel and the initial Humax message on the TV, but immediately after this it switched to the time on the front panel but a blue ring, and 'no signal' on the TV. On the third attempt I was able to see the recording. It had terminated after only 16 mins this time, but what was recorded seemed to be fine.

Does anyone have any idea what could be wrong? Could it be the custom firmware or one of the packages, or is the Humax itself broken? Any suggestions of further experiments to try before I attempt to return it to the seller would be welcome.
 
I would start by examining the crash log, e.g. Web-If >> Diagnostics >> View Log Files >> crash.log to get a screen like this :-
Code:
>>> Contents of /mod/tmp/crash.log 1.27 KiB

Humax crashed at Sun Jul 20 23:35:17 UTC 2014 - Uptime: 213
Humax crashed at Sun Jul 20 23:47:13 UTC 2014 - Uptime: 694
Humax crashed at Sun Jul 20 23:54:51 UTC 2014 - Uptime: 435
Humax crashed at Tue Jul 22 23:23:46 UTC 2014 - Uptime: 23191
Humax crashed at Tue Jul 22 23:25:42 UTC 2014 - Uptime: 87
You may find the times that recordings are cut short corresponds to a 'crash time', if so there are a few reason that the Humax might crash :-
1) You may have something on your Intranet that is conflicting with the Humax (like a NAS running Twonky Ver 7)
2) You may have a corrupted recording that won't play (possibly with a 'lightening bolt' against it)
3) You may have a hard disk problem
 
Last edited:
I installed custom firmware v. 1.03.12...
1.03.12 is the latest Humax firmware version, I presume you mean custom firmware 3.00 for 1.03.12.

Does anyone have any idea what could be wrong? Could it be the custom firmware or one of the packages, or is the Humax itself broken? Any suggestions of further experiments to try before I attempt to return it to the seller would be welcome.
If you are commissioning a recent purchase, you should do so without modification. The options available to you are to: re-flash the firmware; factory reset; reformat the HDD. If you are dissatisfied at that point, then you should take it up with the seller.

You could go further to try to establish what the problem is, but broadly speaking if a HDD format hasn't fixed it then the best you can hope for is that the fan is faulty and can be replaced; or the HDD is faulty and can be replaced; or the whole unit is junk. Custom firmware can help recover a flaky file system and avoid the reformat that would inevitably lose existing recordings, and help diagnose that the fan isn't working or the HDD has a hard fault, but cannot fix any more than a factory reset or a HDD reformat will under standard firmware.

You need to decide whether to reject the unit, or keep it in the hope you can fix it.

More info: Steps for Resolving HDR-FOX Crash/Reboot Issues (click)
 
I would start by examining the crash log, e.g. Web-If >> Diagnostics >> View Log Files >> crash.log to get a screen like this :-
Code:
>>> Contents of /mod/tmp/crash.log 1.27 KiB

Humax crashed at Sun Jul 20 23:35:17 UTC 2014 - Uptime: 213
Humax crashed at Sun Jul 20 23:47:13 UTC 2014 - Uptime: 694
Humax crashed at Sun Jul 20 23:54:51 UTC 2014 - Uptime: 435
Humax crashed at Tue Jul 22 23:23:46 UTC 2014 - Uptime: 23191
Humax crashed at Tue Jul 22 23:25:42 UTC 2014 - Uptime: 87
You may find the times that recordings are cut short corresponds to a 'crash time', if so there are a few reason that the Humax might crash :-
1) You may have something on your Intranet that is conflicting with the Humax (like a NAS running Twonky Ver 7)
2) You may have a corrupted recording that won't play (possibly with a 'lightening bolt' against it)
3) You may have a hard disk problem

Thanks for your analysis. Are there any experiments I can do to distinguish between these possibilities and what can I do to cure them?

Here are my thoughts so far. Please let me know if these are correct.

On 1) I assume that by "something on your Intranet" you mean some rogue code on some other machine connected to my broadband. I've disconnected the aerial that connects my Humax to the modem and the problem persists. Does this rule out option 1)?

On 2) I don't see any corrupt recordings. Everything looks fine, so I assume this is not the issue either.

On 3) I can copy all my recordings onto an external HDD, then reformat the Humax's HDD. I assume this should isolate any corrupt disk sectors. If the problem then goes away but recurs after I copy my recordings back, then it was 2) after all.

Does this sound reasonable?
 
On 1) The Humax can crash if it is connected to your intranet (the network inside your house), while something else on your intranet is running Twonky Ver 7, Twonky is a DLNA server that streams content to other items on your intranet, things that run twonky are Computers / Laptops / NAS (Network Attached Storage device) etc. If your Humax is crashing due to this problem then disconnecting your Humax from the intanet (LAN connector) should stop it craching

On 3) There is a limited Hard Disk checker built into the Humax (a much better 'fix-disk' is available if you load Custom Firmware)
 
On 1) The Humax can crash if it is connected to your intranet (the network inside your house), while something else on your intranet is running Twonky Ver 7, Twonky is a DLNA server that streams content to other items on your intranet, things that run twonky are Computers / Laptops / NAS (Network Attached Storage device) etc. If your Humax is crashing due to this problem then disconnecting your Humax from the intanet (LAN connector) should stop it craching

On 3) There is a limited Hard Disk checker built into the Humax (a much better 'fix-disk' is available if you load Custom Firmware)

On 1), after I had disconnected the aerial, I still had the same problem, so I think I can rule 1) out.

What I did do last night is to reinstall the official firmware, as a first step towards reinstating the Humax to its delivery state prior to returning it. I also set up a test: the problem seems to arise from recordings from 8am on Freeview 20. This recording ran perfectly this morning. If this continues, then it may have been some incompatibility with the custom firmware. If it reoccurs, however, my next step will be to copy all the recordings off onto an external drive, reformat the disk and do a factory reset, then test again. If that fails, I'll return it as broken.

Thanks again for your help.
 
On 1), after I had disconnected the aerial, I still had the same problem, so I think I can rule 1) out.
Not sure why you disconnected the aerial? The suggestion was to disconnect any network cable (or a WiFi dongle) linking the Humax to the rest of your network.
 
my next step will be to copy all the recordings off onto an external drive, reformat the disk and do a factory reset, then test again. If that fails, I'll return it as broken.
O.K. as far as backing up your recordings goes, you need to consider that ALL recordings on the Humax are encrypted, the decryption "password" is different for every Humax and is held on the main board (not on the hard disk), so if you were to copy encrypted recordings to a USB HDD and then format the original hard disk (or even replace it), the Humax will still decrypt the recordings, However, it you replace the Humax with a new one, the new unit will not decrypt the old recordings. This is not a problem for Standard Definition recordings because recordings copied to a USB HDD using the remote control OPT+ button are decrypted when they are copied, High Definition recordings remain encrypted although there is a way to get around this using FOXY (Notes HERE).
BTW
As pointed out above the (On 1) suggestion was to disconnect anything connected to the LAN connector rather than the Aerial connector
 
On 1)I've disconnected the aerial that connects my Humax to the modem and the problem persists.
Not sure why you disconnected the aerial? The suggestion was to disconnect any network cable (or a WiFi dongle) linking the Humax to the rest of your network.
I think that's what the OP has done only has called it an aerial not a network cable. Unless of course he thinks that the Hummy connects to his network via the (real) aerial.
Either way, clarification on what exactly he means would be an advantage to fault finding.
 
O.K. as far as backing up your recordings goes, you need to consider that ALL recordings on the Humax are encrypted, the decryption "password" is different for every Humax and is held on the main board (not on the hard disk), so if you were to copy encrypted recordings to a USB HDD and then format the original hard disk (or even replace it), the Humax will still decrypt the recordings, However, it you replace the Humax with a new one, the new unit will not decrypt the old recordings. This is not a problem for Standard Definition recordings because recordings copied to a USB HDD using the remote control OPT+ button are decrypted when they are copied, High Definition recordings remain encrypted although there is a way to get around this using FOXY (Notes HERE).

I only have SD TV and radio recordings on the Humax. I also have another, older Humax HDR-Fox T2. I've copied recordings between them several times and successfully played them. I even copied off all the recordings on the T2000 I returned and put them on the old HDR-Fox before I sent the T2000 back. As Black Hole says, I haven't yet accumulated many unwatched recordings, so although copying is a slow process, it shouldn't take too long. But I'll use a 500 GB HDD because I'm not sure I own a USB stick with enough memory for all of them.

Thanks for the information re encrypted HD recordings. I tend not to record in HD because (a) they use up so much space on the HDD and (b) I honestly don't notice much difference on the small TVs I tend to watch them on. I expect some of you think that is heresy. :)
 
I tend not to record in HD because (a) they use up so much space on the HDD and (b) I honestly don't notice much difference on the small TVs I tend to watch them on. I expect some of you think that is heresy. :)
I agree with you, but at least one forum member only has the HiDef services tuned! My supported user has no HiDef services tuned - she says she can't tell the difference, but that's an eyesight issue!
 
I tend not to record in HD because (a) they use up so much space on the HDD and (b) I honestly don't notice much difference on the small TVs I tend to watch them on. I expect some of you think that is heresy. :)

We have a 50" TV and I can certainly tell the difference, but my wife says she can't. So I make all her recordings in SD :)
(My own or joint ones I use HD if available.)
 
I had an experience the other day that I thought might shed some light into 'mystery' lock ups when some failed recordings are attempted to be played. I've had a search for a suitable thread to add to but can't actually find one, so I'll put it here and if someone knows a better place can a mod move it or I'll repost it.

I have a series recording for Longmire on 5USA and noticed last week it had decided to record a mid-week repeat as well as the usual weekly slot. Usual Ch5 ID cockup I assume. I let it go as often they sort these out a day or two before and it's OK on the day, or I'll just delete the extra recording.
So after the event I found it had (attempted to) record it and I went to play it and check that it was just a repeat. I got the less than 30 secs message and the box froze. Had to power off at the back to get it to restart. Hmph! Fortunately it wasn't doing anything else at the time.

This box isn't used a lot and may well have been in s'by for 48 hours before this recording was due. So I wondered if the box had woken up expecting to record ID X but as the ID was changed since it was last on it got confused. My thinking is that if the box is awake at some time before the recording slot (and it's 15 min preamble) and the ID has changed it will alter it's schedule correctly, but if it wakes and finds it's different it hits a bug. Of course, the flaw in that idea is that if the ID has changed then how did it know when to do an AR start at all?

Anyway, just chucking it into the experience pool if it's not there already.
 
I thought reinstalling the official firmware might have fixed my crashing problems, but on Friday it crashed while playing back a recording (it wasn't recording at this time). I power-cycled the Humax and then played the recording again from just before it crashed the first time. The recording was fine. There wasn't even a hiccup when it passed the previous crash point.

So, I bit the bullet, copied off all my recordings and reformatted the HDD and did a factory reset, as recommended by Black Hole and others. Since then I've had no problems, despite extensive testing. So, fingers crossed, I've fixed it. If that proves not to be the case, I'll return it.

While copying, I did notice a bug in the copying process. If you have a folder containing a series, say, i.e., with several programmes of the same name, but different dates, then the copying program fails to distinguish them and just overwrites each earlier one with next one, so you end up with a folder with just one episode. To copy over all the episodes you have to copy each one individually to a different folder. Even if you then try to copy all the episodes into one folder on the USB device, it still overwrites. This is a pain and meant a lot of manual interaction was required to ensure everything was copied. Fortunately, there had not been time for me to accumulate any folder of more than 3 episodes.
 
While copying, I did notice a bug in the copying process. If you have a folder containing a series, say, i.e., with several programmes of the same name, but different dates, then the copying program fails to distinguish them and just overwrites each earlier one with next one, so you end up with a folder with just one episode. To copy over all the episodes you have to copy each one individually to a different folder. Even if you then try to copy all the episodes into one folder on the USB device, it still overwrites. This is a pain and meant a lot of manual interaction was required to ensure everything was copied. Fortunately, there had not been time for me to accumulate any folder of more than 3 episodes.
This should not happen, and does not accord with past experience.
 
I copied a folder successfully to my NAS (Sherlock - Series 3 - 3 files) earlier this morning, via the web-if.
 
Each recording has a date and time appended to the file name, but you only see this using a file explorer or FTP client (e.g. Filezilla) or in Web-If. There is a separate media list title you see in the Humax media explorer and these are usually the same for different episodes of the same series, but the underlying file name is different. During copying you should not get one episode overwriting another unless the filename has been changed to be the same, so you seem to be getting some sort of misoperation. If you have two separate USB storage devices connected to the Humax and try and copy from one to the other you can get odd behaviour, but this usually leads to a failure to copy. Copying from the internal HDD to the USB, and from the USB to the HDD, should be fine. However if the USB drive is powered from the USB port and the Humax is struggling to supply sufficient power to the drive this can cause problems and odd copying behaviour. In theory this shouldn't happen as even USB 3.0 drives should be backwards compatible (including with respect to power requirements) with USB 2.0 ports, but I have a Touro drive that needs extra power (supplied using a 5V power adapter and a USB cable with an extra power connector) to work properly. Without the extra power, copying to the USB drive leads to file name truncation and corruption, but I have not seen the overwriting phenomenon mentioned above.
 
Without the extra power, copying to the USB drive leads to file name truncation and corruption, but I have not seen the overwriting phenomenon mentioned above.

I did also notice that folder names were truncated to 6 characters, but not the file names within the folders. So, maybe that is corroborative evidence that the USB sticks are underpowered. I'm not sure how I could supply them with more power though.

The USB sticks I used were also quite old. I bought them circa 2007, but used them because they had the most capacity (8GB). Could age be a factor?
 
Back
Top