Some Linux utilities to work with the Humax

[raydon]

It's in the vim package.

Ah, OK thanks.

 

[prpr]

It's in the vim package.

How truly bizarre. I'm sure there's a good reason for it, but I have to say it completely eludes me. As it does for all the bloat in the rest of that package.

(As for vi, well, about 27 years ago I had the misfortune to be shunted on to some project involving Unix on a 68K box and that was the only editor available. I hated it so much and was so unproductive with it that I took to downloading the source code I was working on via the amodem/umodem/xmodem (I forget exactly, thankfully) facillity of the terminal software onto floppy disk, walking 100 yards down the corridor to my (MS-DOS) PC, editing it there, and doing the same in reverse to get it back on the machine before compiling it. Rinse and repeat ad infinitum in the process of development/debugging. It was actually quicker, but it didn't take a genius to work out that I was rather unhappy with this state of affairs. Thankfully I went on holiday and found another job while reading the paper on the way home in Faro airport.)

 

[Black Hole]

Yup. It would be hard to make a more unfriendly editor than vi, but I'm sure there must have been a good reason for it at the time!

 

[EEPhil]

Yup. It would be hard to make a more unfriendly editor than vi, but I'm sure there must have been a good reason for it at the time!

TECO (a line editor) for vax/vms is a very unfriendly editor.
According to Wikipedia (spit!) - vi was derived from ed (a line editor) which is supposed to be a bit cryptic.
Most visual editors derived from line editors that I've used have been less than friendly. (Although I remember a line editor called ECCE that was better than most and a chip that was installed in a BBC micro (a DECCE chip) that allowed visual editing via the line editor, to be rather good at the time - the BBC micro being used as a terminal to a mainframe)

 

[af123]

How truly bizarre. I'm sure there's a good reason for it, but I have to say it completely eludes me. As it does for all the bloat in the rest of that package.

xxd is part of vim. It was written by the vim authors as a helper application for converting binary buffers to and from hex for editing; it comes with the vim source code and is packaged with it. I tend to use it standalone from the command line in preference to od -x because I prefer the output.

Yup. It would be hard to make a more unfriendly editor than vi, but I'm sure there must have been a good reason for it at the time!

Ah, then you haven't used ed : )
In 1995 I remotely administered several IBM boxes which were in Japan. In those days, bandwidth was very limited and it wasn't uncommon for me to type a command, go and make a cup of coffee, and then come back to find that the characters I'd typed hadn't all been echoed back to me yet. ed was essential for editing as it uses very little extra bandwidth and the commands can be typed without waiting for the output to come back.
Let's not start another off topic discussion about vi*, at least not in this thread, but I love it and everything I've written for the Humax was with it. I am far less productive with any other editor. I do accept it has a steep learning curve!
One thing that irks me in my day job is people from a Linux background, where the default vi editor is actually elvis or vim, and don't know which bits of their vi knowledge are elvis/vim extensions. They then assume that real vi is broken in some way. Same for bash extensions over standard bourne shell. Use them if you want but understand that they are extensions! Ash, as used on the Humax, has its own set of differences from bash and standard bourne too.

* - I inadvertently seem to have continued it!

 

[EEPhil]

Edit: I have updated the central file format documentation on the wiki - http://wiki.hummy.tv/wiki/HMT_File_Format

Does anyone know whether this just applies to the Fox-T2 and/or whether it is accurate for the 2000T?
I ask because for the 2000T the first EPG item in the area above 0x3000 apears to be at 0x30c0 and the area 0x3050-0x308C could be a duplicate of 0x0488-0x04c4. 0x3020 is the channel number (4 byte LE ?) and 0x3024 the channel name.

 

[Black Hole]

Does anyone know whether this just applies to the Fox-T2 and/or whether it is accurate for the 2000T?

As you correctly suspect, the knowledge here is regarding the HDR-FOX and presumed to apply to the 1800T/2000T. Your feedback will be valuable in extending the knowledge to 1800T/2000T.

I'm sure there must have been a good reason for it at the time!

I know the answer to this of course - it 's all about the limitations of teletypes and VDUs.

 

[raydon]

Does anyone know whether this just applies to the Fox-T2 and/or whether it is accurate for the 2000T?
I ask because for the 2000T the first EPG item in the area above 0x3000 apears to be at 0x30c0 and the area 0x3050-0x308C could be a duplicate of 0x0488-0x04c4. 0x3020 is the channel number (4 byte LE ?) and 0x3024 the channel name.

The hmt format as published here applies solely to the HDR Fox T2. The majority of the information it contains was gleaned from a previous analysis I did on the Foxsat HDR hmt format. There is a lot of commonality, but the precise location of each field can differ from box to box. From what I can gather the 2000T hmt format is, in the main, identical to that of the HDR Fox T2. You are correct about the EPG anomolies starting at offset 0x3000. The published format got screwed up somewhere along the way and an entire block is missing from that section. It went unnoticed and was never corrected, since no-one took any interest in the bit at the end (until now, that is). It should look like this:

0x1000    4 byte    0x44332211        Number of EPG Blocks following
 
------  -----   ---------------------------------- EPG Header List Block, Size 8188 bytes (starts at 0x1004) ---------------------
0x0000    32 byte    blocks            Copy of 32 byte header from EPG blocks following. One entry for each EPG block.
0x0020
0x0040                    Next EPG block header (if any)
 
------  -----   ---------------------------------- EPG Block type 01, Size 192 bytes (starts at 0x3000)---------------------------
0x0000   1 byte   0x01          Constant
0x0009   1 byte   0x30          Constant
0x000C   1 byte   0xA0          Constant
0x0020   4 bytes                Channel Number
0x0024   1 byte 0x15            String header.
0x0025   43 bytes               Channel name.
0x0050   2 bytes                Program ID (SID).
0x0052   2 bytes                Transport Stream ID (TSID)
0X0054   2 bytes                Originating Network ID (ONID).
0x0056   2 bytes                Program Map Table (PMT).
0x0058   2 bytes                Video PID.
0x005A   2 bytes   0x0020       Constant.
0x005C   2 bytes                Video PID
0x0060   1 byte                 Video Type MPEG2=0x01,  H264=0x02.
0x0064   2 bytes                Audio PID.
0x0068   1 byte                 Audio Type MPEG=0x01 AC3=0x03 AAC=0x07.
0x006D   1 byte   0x20          Constant
0x0075   1 byte   0x20          Constant
0x0080   1 byte   0x01          Constant
0x0084   1 byte                 Video type flag for Media list. 0x01 = SD. 0x02 = HD.
0x0088   1 byte   0x01          Constant
0x008C   1 byte   0xFF          Constant
------  -----   ------------ EPG Block type 02, (event) Size 704 bytes,including 32 byte header (first block starts at 0x30C0) -----------
++++++ Start of 32 byte header +++++++++
0x0000   4 byte   0x02000000
0x0004   4 byte   0x00000000     Time in seconds from start of recording to change the iPlate info to this EPG block
0x0008   4 byte   0x00300000     12288. Byte Offset to start to EPG block.(increments by 704 for each EPG entry.
0x000C   4 byte   0xA0020000
0x0010 16 byte         Unused
++++++ End of 32 byte header ++++++++++

I named these blocks type 1 and type 2 simply because of the first byte in the blocks. The last 160 bytes of this block mirrors that in 0x458 to 0x4F7 of the main block.
Hmt files for recordings without padding normally don't have any EPG blocks and so end immediately after the data block with a size of 2072 bytes.

 

[af123]

It went unnoticed and was never corrected, since no-one took any interest in the bit at the end (until now, that is)

I did but must have used the format you originally sent me. The hmt utility will display summary information for each EPG block and the epgpatch package fixes it up as necessary.

 

[raydon]

I did but must have used the format you originally sent me. The hmt utility will display summary information for each EPG block and the epgpatch package fixes it up as necessary.

Correction: No-one, except af123 took any interest in the bit at the end...

 

[EEPhil]

Correction: No-one, except af123 took any interest in the bit at the end...

Thanks for the above info (which confirms that I was on the right track when I worked it out!). The reason I flagged up the differences here is because this thread is listed under the 1800T/2000T banner.
af123 isn't the only one interested in the end of the .hmt file. As I've pointed out on the other thread , (Idea: "Foxy-max" PC Utility (developer needed) ) I'm looking into the possiblility of a network-only pc interface to the 2000T - and as such, I (even if nobody else is) was interested in what is at the end of the .hmt file. I always use a padded AR setting and sometimes I like to know what bits of programme I've got! Even more useful when there are 2 or 3 episodes back-to-back.

 

[Trev]

I always use a padded AR setting

Does not setting padding nullify AR. How can you start recording, say 5 mins, before the AR signal has been transmitted?

 

[EEPhil]

Does not setting padding nullify AR. How can you start recording, say 5 mins, before the AR signal has been transmitted?

Probably.
Perhaps my terminology is wrong. But I'm sure the wording in the manual leads me in this direction.
You could start up 5 mins before the transmission is due to start. If the EPG changes you might just be able to track this. Anyway, that's how I've set up my 2000T and rarely does it miss a programme or chop off the beginning/end.

 

[Black Hole]

AR (Accurate Recording) is enabled by configuring the auto-padding pre- and post-padding settings to zero. We (on this forum) tend to refer to AR and padding as opposites and mutually exclusive because they have a completely different set of implications, but they are actually two sides of the same coin. So, padding is not an AR setting, AR is a padding setting!

 

[EEPhil]

We ... tend to refer to AR and padding as opposites and mutually exclusive because they have a completely different set of implications, .... So, padding is not an AR setting, AR is a padding setting!

I probably should have used the phrase "automatic padding" then?
One implication seems to be - auto padding gives you the correct EPG item for the programme you want. I suppose that might be why I mistakenly confused it with AR. Manual padding (to an earlier time) gives you the EPG of the previous programme. (My 9150T doesn't do that).

 

[Black Hole]

That's still confused! AR is not auto-padding. There is no padding with AR - it responds to the programme flags. Auto-padding is when the Humax automatically adds pre-and post-padding to the EPG programme schedule (according to the amounts of padding you have chosen in the menus). Manual padding would be when you go into the recording schedule and manually adjust the start and finish times - that causes the recording to start and end at those specified times, and it will not track any changes to the EPG schedule.

With auto-padding, the recording spans three sets of EPG data - a few minutes of the previous programme, the programme itself, and a few minutes of the subsequent programme. With AR, the recording only starts at the flagged start of the programme, and ends at the flagged start of the next programme, so of course the .hmt only contains EPG data for one programme.

 

[raydon]

.... as such, I (even if nobody else is) was interested in what is at the end of the .hmt file.

I did qualify my statement by saying "until now, that is". (when the hmt analysis was first published the 2000T didn't even exist). I'm happy that you are now finding it useful in your endeavours on the 2000T. If nothing else, it has highlighted a long unnoticed, but unintentional, omission in the published hmt format. Many thanks.
Edit: I have since corrected this omission, and also included some additional guidance notes to reflect more recent information regarding string header and failed recording codes.

 

[EEPhil]

I did qualify my statement by saying "until now, that is". (when the hmt analysis was first published the 2000T didn't even exist). I'm happy that you are now finding it useful in your endeavours on the 2000T. .

I did notice you had qualified the statement. My reply wasn't meant as any critisism, just an observation.

 

[EEPhil]

That's still confused! AR is not auto-padding.

And I'm sure in the last reply I didn't say it was. Forget AR, I now get what it is, and see that my original description was confusing.
However, I was also trying to point out the 2000T seems to store EPG/programme title data differently depending on whether you auto-pad or manually-pad. This is not a difference I've seen on a 9150T.

 

[Black Hole]

However, I was also trying to point out the 2000T seems to store EPG/programme title data differently depending on whether you auto-pad or manually-pad.

To clarify: by auto-pad you mean padding added to the recording start/stop times by the padding settings in the menus under Menu >> Settings >> Preferences >> Recording, and manually-pad you mean adjusting the recording schedule directly in Guide >> Schedule (yellow) >> (select entry) >> (edit settings)??