Some Linux utilities to work with the Humax


New Member
I have only recently acquired a Humax PVR (HDR-2000T) so I am new to this community (I am a long-time Tivo hacker, and still am). In the week I have had it, I have found I needed to create a few utilities to run on my home systems to get the most out of the Humax.

The current tools are:

  • backup-humax -- take backups of the media directories, to protect against hard disk failures
  • humax-unenc-ftp -- clear the ENC flag from all recordings remotely, using FTP
  • hmt2k -- display contents of .hmt files remotely, using FTP
  • dlna-media-archive -- download and archive content from a media server (including the Humax)
  • ssdp-fake -- make DLNA servers visible on other LANs
These tools are intended for my own use, and are under development as I have time and learn more. However, I would welcome any testing and feedback. I do not, at this time, recommend them to people who are not willing to accept some risk and who are not comfortable using an FTP client to fix things if necessary. I only use them on Linux, and have no idea if they will work (or could be adapted) on Windows.

If anyone would find these tools useful, please go to

Comments are welcome in this thread, or as issues (or even pull requests!) in the GitHub repositories.

[Edited 25/1/15 to add hmt2k]
Last edited:
Sort of. I haven't replied to that thread (yet) because I wanted to get some more testing before encouraging people to start using it routinely. It works for me but I only have about 5 programmes on my Humax so far!

humax-unenc-ftp does do what that thread asks for (I think), except that it does not run on Windows. Actually, it probably does: I don't think it relies on anything that might be particularly hard on Windows (unlike the dlna-related tools, which need multicast access). But it needs someone experienced in using Perl (and CPAN modules) on Windows to work out how it would be installed and used -- I have never used perl on Windows. Also, it is not a graphical tool -- it is a command line tool.
If you turn off the Enc flag and then force the DLNA system to re-index the recording, HiDef becomes streamable. Previously we have suggested re-indexing by moving the recording to a different folder, but I guess clearing the database and re-indexing the whole structure would do the same thing.

I'm not sure whether turning the server off and on again would achieve this, I think in HDR-FOX land we have to use a custom firmware "clear database" option, although there may be a hidden-menu option to do it.
If you turn off the Enc flag and then force the DLNA system to re-index the recording, HiDef becomes streamable...

Thanks for the info. The question, as you go on to say, is how to force that re-index. I have been looking for a way which can be done remotely, just with FTP access.

I have found one reliable way: rename the files associated with the recording (not renaming the recording itself, just the files on the disk). This seems to work (the reindex doesn't happen immediately but happens overnight). However, it causes some problems if the Humax is using the files at the time. I haven't tried it during recording, but if you do the rename during playback, the playback finishes but then the Humax writes a new .hmt file under the old name (presumably to update some information about the recording having been played) and the media display shows the same recording twice. Similar problems occur even if playback has just been suspended (paused, and then go to look at something else). But it seems fine for things you haven't started to watch yet. This is the "-r" option on humax-unenc-ftp. I would be very keen to get more information from others on when this works and when it doesn't.

I have considered other options, such as changing the date on the .TS file -- unfortunately I can't find any way to do that with the quite limited FTP server (no REST support), without actually copying the file off and back again, which I want to avoid.

If anyone has any ideas for remotely triggering the re-index I would be very interested.
You can move a recording set to a different location using FTP, I think, but what happens if the recording is in use I don't know. Other than that, without a route in for customised firmware, you're stuck.

The re-indexing of a particular recording need not wait until overnight; rebooting will force the DLNA indexer to scan for changes - but only switching the state of the Enc flag does not count as a change,
Do we (the community) know what any of the other fields in the .hmt file are? All I have found when searching, so far, has been the Enc flag. And not even any description of the meanings of the other values of that field (I have seen 0 and 2). But I am hopeful that there is a list somewhere I haven't found :hungry:
Raydon, who did the work to determine what most of the fields are, has posted the known details on here before. A search should find it.
No Telnet or Custom Firmware as yet for the 2000T, the hmt package is part of the Custom Firmware suite written for the HDR-Fox T2
Oops. :oops:

@GC: with your skills, you are at least able to look at the hmt utility (granted it's for the HD/HDR-FOX) and see what it does to analyse a .hmt file.
Raydon posted info on the hmt and nts file formats here.
Raydon's information is certainly a very good starting place for the hmt files. What I'm not sure about is whether there is any difference between the format for the FOX-T2 (which I don't have) and a 2000T (which I do have). So far, in my poking around in hmt files I can't see any difference between Raydon's info and the 2000T apart from (possibly) the location of extra EPG information at the end of the file. Could someone with a FOX-T2 post an hmt file from a padded recording (ie. contains bits of 3 or more programmes) for comparison? It is possible that there is a little bit more info located between 0x0288 and 0x0290 than is listed in Raydon's info:

0x0288 4 bytes 81 23 00 00 Length of recording (Epoch format) 32-bit byte swapped
0x028C 1 byte 02 Recording 00=zero length, 01=loss of power, 02=valid, 03=scrambled, 04=failed 05,06,07,08=loss of power (Play?)
0x028E 1 byte 02 bit 0 00000001 On-Disk Encrypted flag. 1 = Encrypted. 0 = Decrypted
bit 1 00000010 Thumbnail exists flag. 1 = Yes. 0 = No
bit 2 00000100 Recording Failed - loss of power (Can't play)
bit 3 00001000 File Deleted by autodelete function - do you want to delete the ghost file

0x0290 1 byte 00 Failed recording code, 00=OK, 01=Disk Was Full, 02=Conflicted with another recording, 03=Maximum number of files per folder reached, 04=Recording (less than 30s) may not be stored, 05=loss of signal
Here's a suitable HMT file. It is quite old (from BBC HD) but it is from a padded recording that has parts of two programmes additional to the main one.


  • Rev__20111117_2058.hmt
    2 KB · Views: 7
The File Formats for the HDR-Fox T2 HMT and NTS files are now on the WiKi :-

A valuable addition to the wiki - many thanks.

There have been at least a couple of changes since Raydon published the hmt map:

a) The file name field has moved from offset 017F 0180. Both variants may be found depending on the age of the recording. Although the Humax software doesn't appear to use this field, other CF packages may do so. For example, af123 has already modified the hmt utility to accommodate this change. However, the Nicesplice package still appears to create hmt files with the old format, even when the original recording had the new format.
b) af123 also informs me that offset 073D is used to hold the character 'E' for recordings that have been stripped of their EPG frames. (Maybe, it's my choice of programmes, but I've almost never seen an htm file containing the reported 'eng' characters!)
Here's a suitable HMT file. It is quite old (from BBC HD) but it is from a padded recording that has parts of two programmes additional to the main one.
Many thanks!
I'll have a look at that and see if there is any difference.
[EDIT: Unfortunately, this file does not contain the EPG info beyond the "end marker" - thanks anyway.]

I have also noted an extra symbol that appears if 0x03dc is set to 03 (rather than the 0,2 & 4 we know about) - like a white circle with a grey (empty) box with an orange cross at the side. If this appears and you try to save the programme to USB you get a message about not being able to copy a protected file.
Last edited: