My Humax HDR-Fox T2 packed in

Just a comment that may help someone:

If you plug in a hard drive with a corrupt boot sector or the boot flag not set on a linux system it will often just hang.
Also a second USB drive with no system boot can cause linux to hang instead of booting (on some not all systems).
Another thing I've seen (not specifically humax) is if you use a HDMI switch box and switch away the display during the
boot - that can cause linux to just hang.

jack
 
An update; the new box has been running fine since all the shenanigans.

You may recall I mentioned a buggered PC. I used a PC and a drive caddy to move recordings around. I installed software to handle Ext2/3 drives in Windows.

h t t p s: // sourceforge.net/projects/ext2fsd

Left to do an overnight robocopy, the next morning the PC was stuck in a boot loop that no amount of PC wizardy (using very technical advice from Youtube and forums could fix). The system drive was safe the data was safe , and I could check the drive was physically performin perfectly. It just wouln't allow booting and no amount of bcdedit etc , safe mode, recovery sotware could rescue it. I even cloned the drive to a brand new one and that new one had the same issue.

I'm back up running now after reintalling windows and using a drive caddy to get back data and bits. I wanted to look at a drive that was a backup of the Humax and on my new Win10 installation I was going to reinstall the ext2fsd software. But I did think it might be implicated in my PC issues so I had a read of the software reviews and saw that other people had the same issues with working Windows intsallations being knackered. Caveat emptor and all that.

So my advice is not to use that sotware if ever wanting to handle Ext2 drives. Perhaps use the free Paragon software that is out there.

Is there somewhere on the forum that I could warn users more generally? Has anyone else run in to problems?
 
Last edited:
I think the OP said earlier the box won't boot with the hard drive connected but will work OK if the hard drive is connected subsequently. Sounds like the power supply would be the first thing to check.

Yup, came home to Humax rebooting constantly. A brief summary is that through the forums I realized that would boot fine if HDD removed. Work fine after that. Tried new HDD, still same issues. Tried connecting HDD after the box had booted and that worked. Doing that allowed me to export and decrypt all my recordings to an external HDD for transplanting in a newly sourced 2nd hand Humax where I had changed the original 500GB pipeline to 1TB pipeline.

(other steps involved also - custom firmware, changing encryption key etc but above is the main story)
 
My Humax HDR-Fox T2 packed in and wouldn't restart. However I found that the disc and recordings were okay, albeit encrypted. I'm now in the process of successfully restoring a few 100 recordings onto a new Humax box. It has taken me a little outside of my technical comfort zone for a while, but well explained and everything seems to be working. Many thanks!
Hi Jim I want to put the drive out of the faulty machine into another working one. How did you get around the encryption?

Vince
 
How did you get around the encryption?
Read this: Decryption Guide (click):
Further, through the WebIF settings it is possible to replace the encryption key for any particular HD- or HDR-FOX. The benefit of this is to make recordings encrypted by unit A decryptable by unit B (in any of the scenarios listed below), or by making all your units have the same encryption key, they can all share recordings even while encrypted. This is a temporary change, and requires the WebIF to reinstate it each boot.
So: either you can decrypt everything on the disk by external means, or you can give your new box the "identity" of the old box. If you then ensure everything gets decrypted, once complete you can turn off the key replacement and go back to the box's original key.
 
Last edited:
Read this: Decryption Guide (click):

So: either you can decrypt everything on the disk by external means, or you can give your new box the "identity" of the old box. If you then ensure everything gets decrypted, once complete you can turn off the key replacement and go back to the box's original key.

OR just leave the key the same as the old box, IF on the new box you have no recordings made under the new box's original key.
 
OR just leave the key the same as the old box
The disadvantage of that is it requires the Custom Firmware to set up the desired key every boot. If, for any reason, you lose the CF (or it is disabled), you also lose access to your recordings. I advise routinely decrypting recordings, and I strongly advise decrypting recordings that are not native or do not have the native decryption key.
 
FYI
just another tip that's worked for me 100% of the time
If you go into a reboot loop try catching it just as the channel starts and change channels
Certain channels seem to be prone to causing the loop - eg music channel being in use
(or the act of changing itself stops it)
It will either reboot just once more or more likely stop rebooting.
I disable all the software disabling on crash - I dont know why you would do that.
I've never had any issue getting out of a loop (maybe that disabling is making things harder?).
Also I dont have it connected to any networks so removing that may also be pertenant.
 
Mine never got that far - it rebooted as soon as it first tried to access the hard drive. It was a different kind of issue.

I did have what you described on the old Humax - certain channels or multiplexes caused the box to reboot, restart on the same channel and reboot after 30 seconds e.g. QVC and some other higher up channels.

Hasn't happened with the new box though - stable on all channels so far.
 
I disable all the software disabling on crash - I dont know why you would do that.
It's a backstop. Suppose it's actually something about the custom firmware that is causing the crash (maybe after an update or something). If it were, there's nothing to arrest a continuous boot-crash-boot cycle. By disabling the sections of custom firmware which might be implicated in a crash-on-boot scenario, the user can regain control. If re-enabling the disabled elements (diag fix-flash-packages) promptly results in another crash, you know there's a CF problem.

You can disable the disabling, and in truth it's far more often the Humax code causes a crash than any aspect of the CF, but never say never and you disable the disabling at your own risk. Without it, if you do get into a crash loop, how are you going to stop it?

Also I dont have it connected to any networks so removing that may also be pertenant.
Sure, it's networking communication errors which cause the most trouble... but if your CF isn't networked how do you access it? There will always be a network somewhere.
 
Without it, if you do get into a crash loop, how are you going to stop it?

By putting in the the thumb drive with the previous opk on it
that way you can work out what is causing it in the first place?
As far as I can see there is no list of what's been dissabled or why?
Relying on the internet for recovery seems a risky way to do things to me.
Especially with such an unsecure device.

But like I said - I've never seen a loop that cant be recovered from by a channel change
so I'm a bit confused as to why others repeatedly do given the length of time and high
numbers of these boxes I've used over the the years.

If I thought the custom firmware (which I've found highly reliable - all credit to you guys by the way)
- if I thought it would cause this I think some sort of backup of the entire suite
on disc with an auto revert when say - the box crashes 3 times in the space of a few minutes might be
a better way to go.

Silently dissabling stuff when the user may not even be in the building leaving him
wondering why his system isn't working days later could be a bit irritating. Doubly
so if the net was down.

- not criticising - just suggesting.
 
Here is my list of possible packages from the Wiki :-
4) fix-flash-packages will re-install :- crashdiag, dbupdate, fan, ir, multienv, poweron-channel, redring, rsvsync, tmenu, undelete, webif, webshell

Note : This may not be a full list
 
By putting in the the thumb drive with the previous opk on it
So you want potentially unsophisticated users to have to break a crash loop by technical intervention rather than have the crash loop prevent itself? Let me remind you: you didn't say "I don't know why I would want to do that", you said
I dont know why you would do that
I answered that specific question, not any other one you might have meant.

Anyway, interrupting with a firmware-update-on-a-stick is not guaranteed. The firmware has to start booting in order to check for a .hdf file on a USB.
 
Last edited:
So what is the remedial action? I have never done anything 'remedial' after a crash with the warning about disabling stuff. Have I been lucky?
 
Thanks. But what I don't understand then is why my box continues to work OK without ever using that command.
 
Back
Top