Ah, OK thanks.
Some Linux utilities to work with the Humax
- Thread starter GrahamCobb
- Start date
prpr
Well-Known Member
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.)
Last edited:
Black Hole
May contain traces of nut
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
Number 28
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)
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.
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
Number 28
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
May contain traces of nut
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 know the answer to this of course - it 's all about the limitations of teletypes and VDUs.
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:
Code:
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 ++++++++++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.
Last edited:
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
Number 28
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.Correction: No-one, except af123 took any interest in the bit at the end...
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.
EEPhil
Number 28
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
May contain traces of nut
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
Number 28
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
May contain traces of nut
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.
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.
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.
Last edited:
EEPhil
Number 28
I did notice you had qualified the statement. My reply wasn't meant as any critisism, just an observation.
EEPhil
Number 28
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
May contain traces of nut
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)??