Steps for Resolving HDR-FOX Crash/Reboot Issues (and other hardware problems)

Black Hole

May contain traces of nut
Steps for Resolving HDR-FOX Crash/Reboot Issues (and other hardware problems)

NB: This post may be updated in the light of future developments. Subsequent relevant discussion in this topic will be rolled into this first post. Last updated April 2024.

A variety of factors can result in the HDR-FOX crashing (freezing with static video, front panel display not scrolling, but audio continuing), or crashing and rebooting, or various other symptoms which may not seem to the user like crashes but nonetheless result in the unit being unusable. This article provides a series of actions that can be used to diagnose and (hopefully) resolve the problem, and are in a sequence which begins with actions with the minimum unwanted side effects. If any terms used are unfamiliar, see the Glossary (click).

A further situation occurs where the HDR-FOX behaves normally when operating, but fails to power down properly (the HDD continues to spin) when put into standby. This is addressed in Things Every... (click) section 18, see 'Delinquent Half-Awake'.

Various other common malfunctions are manifesting as our units age, as reported by users in these forums, which are not crashes or reboots as such. If you are reading this because of (for example) unexplained loss of signal, skip to section 4.

Please note that it is not uncommon for the HDR-FOX to freeze for no apparent reason, particularly if left on for an extended period (see footnote * below). In this state it is unresponsive to handset or front panel controls, it will not make scheduled recordings, and the only recourse is to "turn it off and on again" using the switch on the rear panel. This will normally restore full functionality. In any case, whatever the problem, it would be foolish not to try the basic technique of "turn it off and on again" - and in the case of HDR-FOX that means with the switch on the back (if possible, it is advised to switch to standby first and allow it to shut down properly, but I have never had any problems from just powering off). From here on the article is dealing with crashes and reboots which occur frequently rather than occasionally, and are therefore systematic rather than random.

Before proceeding further, ensure the HDR-FOX is not crashing as a result of being "flooded" with infra-red control signals. To verify this, cover the front with a thick cloth or the like. If the crashes stop, search for a misbehaving remote control handset (not necessarily the Humax one) that may be transmitting continuously (eg button stuck down), and turn off all lights (some fluorescent lamps emit flickering IR). Some digital cameras (eg phone cameras) are sensitive to IR and will make signals visible in their viewfinders.

NB: The remedies offered in section 1 are general, non-destructive, and applicable regardless of whether crashes are immediate or not. Applying them offers little opportunity to diagnose the actual problem (if the fix works), but the user might not care about that.

1. Crashes occur within moments of start-up, no opportunity to intervene through the user interface or custom firmware web interface:
These might be the consequence of hardware failure (processor, memory, HDD, PSU), corrupted firmware, or corrupted data tables, but either way the possible interventions are limited by being unable to access the system menus. If the unit reboots before completing the boot process, skip to section 3.​
1A: isolate the unit from all external influences: disconnect the aerial, any network connection (Ethernet cable or WiFi dongle), and any USB drives (front or rear) - except mains power of course. If this stops the immediate reboots proceed as per section 2.​
1B: Download and install (or re-install) the latest Humax firmware via USB. Full details are on the wiki HERE (click). Although this step has possibly the least likelihood of success, it also has the least inconvenient consequences in that it will have no effect on existing recordings, recording schedule, or user preferences. It will require custom firmware users to re-install their custom firmware. (Note: users with custom-installed GPT disks - ie larger than 2TiB - should not install standard Humax firmware.)​
1C: Download and install the system flush via USB (see "System Flush Update File" HERE - click). This has the best chance, but it mimics the effect of a Restore Factory Defaults operation resulting in the user preferences having to be set up again, including retuning and the recording schedule. Custom firmware users can restore their recording schedule automatically. This has been reported to resurrect apparently "dead" (non-booting) HDR-FOXes on two occasions.
If neither 1B nor 1C are effective, the conclusion is that something is seriously wrong with the innards and without being able to break the reboot cycle there is no opportunity to investigate further - unless one is willing to open the lid. See below for Hardware Investigation.​

2. Crashes occur, but the user interface is accessible between crashes:
2A: Change the channel the unit is tuned to when it starts up to BBC1. If the crashes stop, the likely cause is that services carrying an MHEG side channel are triggering a bug in the Humax firmware which results in a crash if there is also a networking error. Units with fully functioning networking do not crash this way, and units that are not connected to a network (and have not been since last reboot) also do not crash. Crashes of this nature are indicative that there is a network configuration problem to be resolved, external to the HDR-FOX. Note that a HDR-FOX running Custom Firmware might routinely produce network traffic (according to what you have set it up to do), and all such traffic is liable to produce a crash if your network/Internet is flaky.​
Crashes of this nature might also occur (even without a network connection) if the Humax is not correctly tuned - see Things Every... (click) section 2.​
2B: Change the channel the unit is tuned to when it starts up to a data service such as BBC Red Button (LCN 200). If the crashes stop, the likely cause is that the HDD is corrupt and writes to the time-shift buffer cause the crashes. Either:
  • If you are a custom firmware user (or are prepared to install custom firmware - do so now, see footnote ** below). Through the custom firmware Telnet interface, boot the unit into Maintenance Mode and run the disk check and repair utilities. See Quick Guide to Disk Recovery (click); or:
  • Reformat the HDD through the menus: Menu >> Settings >> System >> Data Storage >> Storage = Internal HDD; Format Storage. This is a last resort action, as it will result in all recordings being deleted - one might decide to copy them to backup storage first, or that the previous alternative is preferable; or:
  • If you really can't stomach the idea of installing custom firmware (the preferred option), and really don't want to reformat the HDD for some reason, there is a hardware solution which involves removing the HDD and connecting it to a PC. Using a Live Linux boot CD/DVD or a disk partition utility for Windows that makes Ext3 drives accessible, reformat (as Ext3) the third partition on the disk (approximately 10GB in size). See 3B below for details of how to hook up the drive to the PC.
2C: Disconnect the network connection (Ethernet cable or WiFi dongle). If the crashes stop, the likelihood is that the DLNA service is conflicting with another DLNA service on your home network. Some versions of Twonky are known to conflict in this way - have you added or updated a DLNA service on your network recently? See the wiki HERE (click) for a list of software known to conflict with the HDR-FOX DLNA server. This diagnosis can be confirmed if crashes remain absent when the network is reconnected after the HDR-FOX DLNA service is disabled (see 2D), but note that disabling the DLNA service alone is not necessarily diagnostic of an external DLNA conflict. The dlna-filter custom firmware package is able to isolate the HDR-FOX server from external servers. Alternatively, it could be that the Humax's IP address is conflicting with another device on your network - networking faults have been observed to crash the Humax.​
2D: Through the HDR-FOX menus, disable the DLNA service: Menu >> Settings >> System >> Internet Setting >> Content Share = Off. If the crashes stop, the likelihood is that the DLNA indexing database is corrupt and must be removed so that it can be rebuilt. Either:
  • If you are a custom firmware user (or are prepared to install custom firmware - do so now*), clear the DLNA database: WebIF >> Diagnostics >> DLNA Server >> Reset DLNA Database; or:
  • Reformat the HDD through the menus: Menu >> Settings >> System >> Data Storage >> Storage = Internal HDD; Format Storage. This is a last resort action, as it will result in all recordings being deleted - one might decide to copy them to backup storage first, or that the previous alternative is preferable; or:
  • If you really can't stomach the idea of installing custom firmware (the preferred option), and really don't want to reformat the HDD for some reason, there is a hardware solution which involves removing the HDD and connecting it to a PC. Using a Live Linux boot CD/DVD or a utility for Windows that makes Ext3 drives accessible, delete the file dms_cds.db from the root of the second partition on the disk. See 3B below for details of how to hook up the drive to the PC.
2E: Through the custom firmware Telnet interface, boot the unit into Maintenance Mode and run the disk check and repair utilities (see footnote *** below). See Quick Guide to Disk Recovery (click).​
2F: Through the HDR-FOX menus, perform the "factory reset" operation: Menu >> Settings >> Installation >> Factory Default. Do not tick the "Format HDD" option unless you are willing to lose existing recordings or as a last resort. The reset will result in a retune and loss of the existing schedule for future recordings, so make a note of them to reinstate the schedule afterwards [Guide >> Schedule (yellow), use the down cursor to access entries off the bottom of the screen]. Note that Custom Firmware can back up and restore recording schedules and tuning.​
3. Hardware Investigation:
Note that accessing the innards of the HDR-FOX will inevitably invalidate any warranty on the unit, and there is an anti-tamper seal which can (with care) be removed and replaced - although damage to screw heads etc will also be seen as evidence that the unit has been opened. The standard warranty is one year, extensible to two years for a brand new (not Grade A refurb) unit registered with Humax. All HDR-FOXes will be out of warranty by now.
For access and servicing procedures etc see HDR-FOX Commissioning, Disassembly, Repair (click).
3A: The unit may crash/freeze if it overheats. This would not be expected within a few tens of minutes of starting up from cold, so if the unit crashes sooner than this, despite having been turned off at the mains for a considerable period, this cause can be ruled out. If overheating is suspected, verify that the fan operates by observing over a few hours - a tell-tale can be used in the form of a slip of paper folded with a lip and balanced on the rear edge of the unit obstructing the fan vent. If the tell-tale is still there hours later, it would appear the fan is not working. If the fan is working, but overheating is still suspected from the crash pattern, open up and check for accumulated fluff and dust obstructing air flows or insulating components from ventilation.​
3B: Disconnect the HDD and operate the unit without it. The HDR-FOX will function as a receiver, and if the crashes stop it is a good indication that something is not well with the HDD or maybe the PSU.​
Disconnecting the HDD is not at all difficult, in fact it would be pretty difficult to get it wrong. Switch off the box. Remove the three screws holding the lid on and pull the flat red wire that goes from the main board to the HDD. Its easier to pull it at the main board end (it just pulls off, there is no 'catch' holding it in place). There is no need to remove the 4 way power cable (which does have a 'catch').
Black Hole said:
There is a chance that removing the power cable will be necessary to stop the crashes, if the problem is a power drain by a faulty HDD. Try just disconnecting the data first, and if that doesn't help try disconnecting the power cable as well (in which case suspect the PSU). [edited]

3Ba: We have become aware of a common fault developing on ageing HDR-FOXes where the unit won't boot with the HDD connected but will boot without it. While this might seem to indicate a faulty HDD, in some instances it has been shown to be a deeper problem on the main board (not the PSU). The main diagnostic symptom is that the boot process continually restarts the moment "start system" (or the custom firmware announcement, if installed) disappears from the VFD (front-panel display), which is when the HDD gets powered up (but before it has had chance to be accessed). If the restart occurs later than this, it is more likely to be a HDD fault (see 3Bb). Diagnosis is confirmed if the problem remains when a different (known working) HDD is fitted, or the original HDD is shown to work in a different HDR-FOX (or when tested on a PC). Repair might be effected by the relatively simple replacement of a capacitor on the main board. For more information see​
3Bb: Presuming the restarts are later in the boot process than in 3Ba, given that at this stage of the investigation the HDR-FOX is inoperable with the HDD connected (otherwise the custom firmware disk fixing utility is the best option - see 2E), the options are either to try fitting a new HDD, or to try recovering the old one by connecting it to a PC (eg through a USB to SATA adapter, easily obtainable and useful in the tool kit - get one that comes with a power supply, eBay is probably the cheapest source). Instructions for recovering the drive on a PC are beyond the scope of this guide, but it is probably best to boot with a Linux live CD/DVD and use Linux tools - there are tips on this forum for using Linux commands on the HDR-FOX and they will also apply to Linux on a PC (but take extreme care not to do anything to the PC's HDD!).​
If there is nothing on the disk you can't do without, the simple option is to just use Windows (or whatever) to reformat the drive as NTFS, then put it back into the Humax and (assuming it then works) use the Humax menus to format the drive to its own requirements. Note that Humax firmware 1.03.xx is more capable at formatting than previous firmware, so it is worth installing 1.03.xx for the formatting process even if you then return to a previous firmware according to your preference.​
3C: If disconnecting the HDD did not stabilise the unit, the problem may be unstable power supply voltages. Taking care to ensure the unit is disconnected from the mains, inspect the PSU module. Electrolytic capacitors (the small cylindrical cans) have a reputation for going "dry" with age and failing to perform their function - a failed capacitor may have a bulged appearance. If that is the problem, PSUs can be restored to function by obtaining a replacement set of capacitors and swapping them in (kits are available for popular consumer items). At this point it would be very handy to have a second (working) HDR-FOX to swap PSUs and see if the problem moves with the PSU or stays with the faulty unit. Replacement PSUs are available.​
3D: It is possible that the front panel module (which handles timer events and the remote control input) can fail and have a deleterious effect on the unit. As the module is necessary to get the unit to turn on at all, I can't think of a method to diagnose it positively at the moment (other than to have a second HDR-FOX and do a swap). Replacement front panel modules are available.​
4. Other Hardware Problems:
It is routine in electronics restoration to replace any and all "wet" (ie electrolytic) capacitors. These are well known to "dry out" over a long period of time (according to storage conditions) and no longer have their specified performance (which the correct functioning of the circuit might rely on). Two such examples are the faults in sections 3Ba and 3C above. A restorer will then go through resistors checking they still have their proper values, but that is less of an issue with equipment less that 40 years old – modern resistors are much more stable.​
Typically, otherwise, the least reliable part of any electronics assembly (not including moving parts, and "wet" capacitors) are the interconnections. These include the connectors linking different sub-units or on cables linking sub-units, the cables themselves (particularly if they have to flex as a normal part of operation – which is not the case in a HDR-FOX), and the solder joints which form the electrical and mechanical connections between components and the PCB [printed circuit board].​
Corrosion or dirt ingress can cause contact through a connector to lose electrical continuity, which is why unplugging and replugging sometimes restores function. If the connection actually becomes high resistance rather than a circuit break, this can lead to all manner of confusing symptoms. When faced with a fault, of almost any nature, it is a simple and cheap thing to try simply disconnecting and reconnecting any plug-in item you can find, internally or externally. Don't be surprised if that doesn't help, but if it does... great!​
Apart from the firmware and software, the thing which makes a design unique is the PCB. The components themselves are bought-ins, available to anyone (in principle). The job of an electronics designer is to decide how they are to be connected together into a circuit, and the result is a PCB into which is embedded copper tracks (wires) linking the components in the prescribed way. Heavy components might need securing to the PCB, but mostly the components are light enough that they can be held on by their soldered electrical connections to the PCB tracks.​
Do not over-estimate the reliability of these soldered joints. If the assembly is subjected to cycles of warming up and cooling down, or if any particular component gets hot, the PCB and the components expand and contract at different rates (because they are made of different materials, and won't be at the same temperature at the same time anyway), which imposes recurrent strain on the solder joint. As with any piece of metal, if you keep bending it back and fore, eventually it gives way, resulting in a crack which might make circuit sometimes and not others.​
If your unit doesn't work until it has had a chance to warm up, or works when it's cold but not after it has warmed up, this might be a symptom of a component drifting in and out of specification, but could also be a symptom of a cracked solder joint which still makes contact in the right conditions as things expand or contract. Sometimes a sharp blow can make it (or break it!). Loss of contact between valves and their connectors in early TVs is why thumping it became routine practice!
What's more, due to environmental concerns over electronics waste, industry has been obliged to use lead-free solder for the last several decades, which is more difficult to solder in the first place and more brittle than tin-lead solder. It is also more subject to "tin whiskers", which is a curious process in which atoms of tin (in the solder) very gradually migrate into thin spikes emanating from the solder surface and can create short-circuits between the closely-spaced contacts on miniaturised components.​
A potential cure for either cracks or whiskers is heat (to remelt the solder joints), but this requires hot air at around 300ºC and is highly skilled, so the average hobbyist is unlikely to have to tools or know-how. Just sticking it in a domestic oven won't reach the required temperature, and would apply the heat for far too long (so cook the board) even if it did. On the other hand, if there's nothing to lose...​
Something we are seeing is problems with reception or tuning. First, of course, the user should rule out problems with the signal external to the HDR-FOX, but if absolutely convinced there is nothing wrong in that department then the circuitry within the HDR-FOX may well be to blame. There are decoder chips on the PCB between the processor and the tuning can (or cans), and the tuning cans themselves contain a PCB with delicate RF circuits on it (which is why they are shielded inside a metal can). Attempts have been made to transplant the tuners, but none successful so far as I know. The cans themselves are very difficult to get into.​
To improve the longevity of electronics (including the HDR-FOX), the best thing to do is not let it keep warming up and cooling down – in other words: don't switch it off. This imposes additional wear on moving parts (HDD and fan), but those are replaceable (and the HDD will also benefit from not being temperature-cycled). There is a cost in electricity, but you have to balance that against cost/inconvenience of replacing the unit when it fails.​


* Random freezes of the type described in paragraph 4 appear to be due to network communication errors. In my personal experience: one HDR-FOX that is not normally connected to a network does not suffer these crashes very often if at all. Meanwhile, three others connected to the home network (and the Internet) via power line networking adapters froze regularly (at least once a week) until the reliability of the power line adapters was significantly improved by a firmware update. Occasional freezes are still observed, but the incidence is greatly reduced. The explanation may be that there are bugs in the areas of the Humax code which handle network communications faults - the development testing may well not have covered these areas adequately on a limited budget, the primary emphasis being to ensure the "normal" functioning of the unit is correct and reliable (which, by and large, it is). This will also explain why different users experience differing frequencies of incidents - the more reliable your network, the fewer comms faults and fewer crashes.

** The custom firmware for HD-FOX and HDR-FOX is in continuous development by the enthusiast community and has become a very slick and low-risk installation. The custom firmware does not affect the normal day-to-day operation of the HD-/HDR-FOX through the on-screen menus, instead it provides additional ways to manage the recordings etc on disk through a web browser interface ("WebIF") and direct access to the Humax operating system (including diagnostic and maintenance commands added by the CF) through a Telnet console. For more information see Quick Guide to Custom Firmware (click).

*** Note that if the HDD is failing, it may only be brought back to life temporarily using the custom firmware disk check and repair utilities (or not at all). Consider sourcing and fitting a replacement, and then existing recordings can be accessed on the old drive by connecting it to the HDR-FOX's USB port - see 3B, and also Things Every... (click) section 12.
Last edited: