• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Some Linux utilities to work with the Humax

escat said:
...
a) The file name field has moved from offset 017F 0180. Both variants may be found depending on the age of the recording...
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!)
Click to expand...

a) Well spotted - I wondered why I had to write a rather dodgy string processing routine to read it!
b) I've just looked at a few of the hmt files I've saved and I do see "eng" occasionally. (Family Guy, Police Interceptors). More often than not it's not there.
 
EEPhil said:
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.
Click to expand...
There is a limit on the number of copies you can make of an Enc recording. We don't come across it very often in HDR-FOX CF-land because we routinely un-Enc our recordings!
 
Black Hole said:
There is a limit on the number of copies you can make of an Enc recording. We don't come across it very often in HDR-FOX CF-land because we routinely un-Enc our recordings!
Click to expand...
I only pointed this out because I was poking around in an hmt file and found this as a consequence! I hadn't seen any mention of this icon anywhere else. Given your request for a foxy-max on another thread, I was never in any doubt that many people unEnc their recordings!
 
Unfortunately the source for the original hmt is not available. So, I have created my own, open source, version which I can update, and which can display local files or files accessed remotely using ftp. See www.cobb.uk.net/humax.html

It is written in perl and it runs on Linux. If someone wants to volunteer to make it run on Windows (code changes and/or installation and usage instructions) I am happy to incorporate them (contact me here or on github or just send me a pull request).

It is based on the ground-breaking and large amount of work by raydon -- many thanks for publishing that. I believe I have incorporated the changes mentioned here, although there are still several things I still do not understand. Corrections or comments are welcome. Note: I have only tested it with .hmt files from my HDR-2000T.
 
Well done Graham, a useful tool for 2000T and possibly other Humax users, it might he worth considering renaming your 'htm' though as there could be confusion with two packages of the same name, how about hmt2k ?
EDIT
Typo I did intend to write Humax rather than Human, damn you auto correct :)
 
Last edited:
GrahamCobb said:
It is based on the ground-breaking and large amount of work by raydon -- many thanks for publishing that. I believe I have incorporated the changes mentioned here, although there are still several things I still do not understand. Corrections or comments are welcome. Note: I have only tested it with .hmt files from my HDR-2000T.
Click to expand...

Very nice. I like the way it's structured too.

We've discovered some new things about the guidance flags recently that you might want to include:

Code: 
guidanceMedia => {
  0x00ff => "Guidance off",
  0x0100 => "General guidance on", # Suitable for pre-watershed
  0x0101 => "Guidance on",
  0xff00 => "Guidance on",
},

The hmt utility shows general guidance as the GGuidance flag. It's used by the broadcasters for things like programmes with strobe lighting. The web interface now shows general guidance as a blue icon and other (watershed) guidance in red.
 
Hmm.

Code: 
0x0100 => "General guidance on", # Suitable for pre-watershed

I think this is actually:

Code: 
0x0001 => "General guidance on", # Suitable for pre-watershed

I have one .hmt file with the value 1 in that 16-bit field (and text "Contains mild language").

I am guessing this is a little-endian/big-endian confusion. I unpack that field as "v" -- meaning little endian -- which is consistent with the other multibyte fields in the hmt. That means, for example, that "guidance off" is 0x00ff for my code (which seems to be right -- there is no guidance text in these cases). hmt may unpack that field as big-endian and so would be expecting to see 0x0100.

Or, do you have .hmt files with 00 in byte 3E0 and 01 in byte 3E1?
 
You're right - it's stored in the .hmt file as it appeared in the broadcast EPG data. It's actually two 8-bit fields according to the Freeview spec but if you're reading it as a LE 16-bit value it will be reversed.

Code: 
00003e0: 0100 1069 3743 6f6e 7461 696e 7320 6d69  ...i7Contains mi
00003f0: 6c64 206c 616e 6775 6167 6520 616e 6420  ld language and
0000400: 666c 6173 6869 6e67 2069 6d61 6765 7300  flashing images.
 
Last edited:
Thanks. It would be nice to be working with a copy of the D-Book to hand!

By the way, I assume the 10 69 37 at the start of the text is some sort of code page/encoding indicator for the following text (possibly specifying ISO/IEC 6937?). Does anyone know if that is right? And, if so, how to parse other indicators?
 
Nice work Graham. One very minor point. I noticed that you have credited the writing of the hmt utility to me. It was, in fact, written by af123, based on my original analysis of the hmt format.
 
Regarding the 10 69 37 prefix. It's not an ISO/IEC 693-2 language code, but is is used to precede text strings in the hmt. It is either this sequence, or the single byte 15, and have both been seen to be used in the same fields. However, the rules as to when or why each should be used is not known. I simply test for the first character and adjust the offset to the start of text accordingly.
 
Last edited:
Ah. I was prompted by raydon's reply to look into DVB text encodings further. This seems to be the format described in ETSI EN 300 468 Annex A.2 (http://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.14.01_60/en_300468v011401p.pdf) -- although that seems to be the latest version on the site it doesn't include the 69 37 value for the table id but it fits the structure.

I am not going to bother to try to handle the format conversions, but I will update my string handling to skip the header bytes as explained in that appendix (if the first byte is 0x20 or higher skip 0 bytes; if it is 0x10 skip 3 bytes; if it is 0x1f skip two bytes; otherwise skip 1 byte).
 
So 0x15 stands for UTF-8. Fits in nicely, but like you said, 0x6937 following the 0x10 remains a mystery since the 'character code table' value contained in these last two bytes never exceeds 0x000F. I can't imagine there being 26935 code tables so they must mean something else.
Edit: As a very wild guess could it mean ISO IEC 6937 ? :rolleyes:
 
Last edited:
I have been trying to see if I can relate any of the other information in EN 300 468 to hmt fields...
  1. Genre codes. The codes in section 6.2.9 seem similar to those we know about in the hmt (although all the codes we have seen have 0 in the level 2 nibble).
  2. ISO 639 language codes. The "eng" string which appears at 0x073D in some files is an ISO 639 language string, which get heavily used in the spec.
  3. Parental guidance. The parental guidance info in the hmt does not seem to be derived from the description in EN 300 468 6.2.28. My guess is that the D-Book defines a whole separate parental guidance scheme for Freeview -- that is the sort of thing governments and regulators spend a lot of time on.
 
No, that was ISO IEC 26935 (expressed as a 4-bit binary coded decimal), or was it ISO IEC i7 ?
 
Last edited:
You must log in or register to reply here.
Back
Top