• 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

It was meant to highlight the subtle difference between the actual 2 byte value contained in the text header and a binary coded decimal representation of a number which may be the number defining an IEC standard. That same value can be interpreted as either 0x6937 in hex, 26,935 in decimal, "i7" in ASCII, or 6397 in 4-bit BCD. Maybe I should have added a diagram.
 
Last edited:
I have been trying to see if I can relate any of the other information in EN 300 468 to hmt fields...
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).
The genre codes on the T2 match up fairly well with the main groups defined in that section without the additional refinement of the sub groups defined by the level 2 nybble.
FYI, the T2's genre list I originally published may not be 100% correct but this one is.
0x00 = Unclassified
0x10 = Movie
0x20 = News and Factual
0x30 = Entertainment
0x40 = Sport
0x50 = Children's
0x60 = Entertainment
0x70 = News and Factual
0x80 = News and Factual
0x90 = Education
0xA0 = Lifestyle
0xB0 = Unsupported
0xC0 = Unsupported
0xD0 = Unsupported
0xE0 = Unsupported
0xF0 = Drama
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.
The 639-2 codes you see in the hmt are those which are included in descriptors with tag 0x4D (short_event_descriptor) and tag 0x89 (guidance_descriptor) as defined in section 6.1
and are part of the Event Information Table as defined in section 5.2.4 from which all EPG information is extracted.
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.
Correct, they don't use the parental_rating_descriptor (tag 0x55). Instead it's at the start of the D-book defined 0x89 guidance_descriptor, as outlined earlier by af123, and precedes the ISO 639-2 language code.
 
Last edited:
It was meant to highlight the subtle difference between the actual 2 byte value contained in the text header and a binary coded decimal representation of a number which may be the number defining an IEC standard. That same value can be interpreted as either 0x6937 in hex, 26,935 in decimal, "i7" in ASCII, or 6397 in 4-bit BCD. Maybe I should have added a diagram.
Hence the need for emoticons to express the unwritten aspects of our language.
 
Hence the need for emoticons to express the unwritten aspects of our language.
I thought you would have "got it" after post #38 but I'll add a smilie to the original post if it keeps you happy. Your contribution to the thread is duly noted.
 
Last edited:
Code:
0x0710, 'v', "eventID",
0x0712, 'V', undef,
0x0716, 'v', "unknown1", # != raydon

The event ID field should be at 0x716. At least, it is on the HDR Fox T2.

Code:
humax# sqlite3 /var/lib/humaxtv/rsv.db
sqlite> select usevtid, szevtname from TBL_RESERVATION where szevtname like '%brown%';
38303|Father Brown

humax# epg -E38303 dump
----------------------------------------------------------
  Service ID: 17540
  Event ID: 38303
  start_date: 0xdeda 14:15:00 (Wed Jan 28 14:15:00 2015)
  duration: 0:45:00
  encrypted: 0
  Name: Father Brown
  Text: 3/10. The Pride of the Prydes: Series based on GK Chesterton's novels. A guide is attacked at the grand opening of Pryde Castle and Father Brown believes the motive lies with the family. [HD] [AD,S]
  Content Type: Undefined (15)
  Event CRID: /1FHP06
  Series CRID: /UAA7AC


humax# dc 16 o 38303 p
959f

humax# xxd < /mod/video/Father\ Brown/Father\ Brown_20150128_1414.hmt | grep 710
0000710: 0000 0000 0000 9f95 0000 0000 0000 0000  ................


Edit: I have updated the central file format documentation on the wiki - http://wiki.hummy.tv/wiki/HMT_File_Format
 
Last edited:
How's that now?
Thanks af123, but something still not quite right. I think there should be an 0xff value in the first byte when Guidance is Off. Endianness ?
Code:
On
3E0  00 FF 15 43 6F 6E 74 61 69 6E 73 20 73 6F 6D 65  .ÿ.Contains some
3F0  20 73 74 72 6F 6E 67 20 6C 61 6E 67 75 61 67 65   strong language

Off
3E0  FF 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ÿ...............
 
Last edited:
failureReason => {
0 => "OK",
1 => "Disk was full",
2 => "Conflicted with another recording",
3 => "Maximum number of files per folder",
4 => "Recording less than 30 seconds",
},
Today I ended up with a recording having status 2 and reason 17. On trying to play it on screen I get 'the programme may not have been broadcast' although it was and plays fine.
I wonder what all of the intervening numbers mean!

Code:
humax# xxd < test.hmt | grep 00002[89]0
0000280: 5ec6 cb54 43d4 cb54 dd0d 0000 0200 0000  ^..TC..T........
0000290: 1100 0000 0000 0000 0000 4e65 773a 2053  ..........New: S
 
Today I ended up with a recording having status 2 and reason 17. On trying to play it on screen I get 'the programme may not have been broadcast' although it was and plays fine.
I wonder what all of the intervening numbers mean!
Status of 2 means recording is "valid". I believe 5 is "Loss of signal". I'll try and find out if there's more and what they mean.
 
Last edited:
You're probably doing the same as me... here's my list and I've given up at 27

Code:
1: failed: Disk was full
2: failed: Conflicted with another recording
3: failed: Maximum number of files per folder was reached
4: Recording (less than 30 secs)
5: failed: lack of signal
8: failed: conflicted with another recording
13: incomplete: Disk was full
15: failed: no storage device detected
16: incomplete: the USB storage device was removed
17: failed: programme not broadcast
18: failed: loss of power
19: failed: conflicted with higher priority recording
20: failed: unable to track programme

Strings from the binary

Code:
humax# strings /usr/bin/humaxtv | egrep '(Recording (failed|incomp)|less than 30
)' | sort | uniq
Recording (less than 30 secs) may not be stored.
Recording failed: conflicted with a higher priority recording.
Recording failed: conflicted with another recording.
Recording failed: lack of signal.
Recording failed: loss of power.
Recording failed: no storage device was detected.
Recording failed: the disk was full.
Recording failed: the maximum number of files per folder was reached.
Recording failed: the programme appears not to have been broadcast.
Recording failed: unable to track programme.
Recording failed: unknown error.
Recording incomplete: the USB storage device was removed.
Recording incomplete: the disk was full.
 
Last edited:
You're probably doing the same as me... here's my list and I've given up at 27

1: failed: Disk was full ...20: failed: unable to track programme

I can confirm that I found the same on my 2000T .

If by status you mean the byte at 0x028c. I've noticed that as you start to record a programme status=0, after 30 seconds - status=1 and if the recording completes - status=2. If the power fails whilst recording you will be left with status=0 or 1 but never 2. However, if you are playing back whist still recording, these values appear to be ignored.

As for the programme not being broadcast. I think I got that error once on a part-time channel. The recording started before the channel came on air and the Humax didn't like the mheg only data stream (maybe).
 
Today I ended up with a recording having status 2 and reason 17. On trying to play it on screen I get 'the programme may not have been broadcast' although it was and plays fine.
I wonder what all of the intervening numbers mean!

If recording the first program of the day from a channel like BBC3 or BBC4 which doesn't broadcast program content all day then I get the 'failed recording' black lightning flash symbol on grey background because I am using padding instead of A/R. From something Black Hole said many moons ago when I mentioned this he said that at that point it is a data channel, not a program channel. The program starts with the 'This is BBC3(4) logo for the padded time and then the program plays normally.

You weren't attempting to record such a program perchance?
 
OT for this forum section... but as it's referred to above, which package is "xxd" in please?
 
It's in the vim package.

Code:
humax# opkg search /mod/bin/xxd
vim - 7.3
 
Last edited:
Back
Top