• 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.

hmt utility version 2.4 source files

P

pwd4361

New Member
Sorry if this is something which is frequently asked and answered. I have searched the forums, but haven't seen anything relevant: I might have missed something.

I'm trying to find the source code for version 2.4 of the hmt utility: I want to build it on my linux PC to enable me to analyse .hmt files there. I'd also like to find the .hmt file format which is used by this version. I've seen the entry for hmt 2.5.0 on the hummypkg.org.uk foxsat page (I'm not allowed to post the actual URL) - but I can't find any mention of the source files.

I've successfully built hmt 2.0.11 - but this version appears to expect hmt files in a completely different format from the ones created on my foxsat-hdr.

I would be most grateful for any help or pointers. Thanks in advance.
 
Be careful not to confuse (custom) utilities for Foxsat-HDR with utilities for HDR-FOX.

The code bases for either are proprietary, but there is far more sharing in HDR-FOXland than in Foxsatland.
 
Black Hole said:
Be careful not to confuse (custom) utilities for Foxsat-HDR with utilities for HDR-FOX.

The code bases for either are proprietary, but there is far more sharing in HDR-FOXland than in Foxsatland.
Click to expand...
On my foxsat-hdr, I'm using the custom software (version 4.0.8 - currently planning to upgrade to the latest version). Are the source files for the hmt utility in the custom firmware not generally available?
Click to expand...
 
Last edited:
pwd4361 said:
I'm trying to find the source code for version 2.4 of the hmt utility: I want to build it on my linux PC to enable me to analyse .hmt files there. I'd also like to find the .hmt file format which is used by this version. I've seen the entry for hmt 2.5.0 on the hummypkg.org.uk foxsat page (I'm not allowed to post the actual URL) - but I can't find any mention of the source files.
Click to expand...
2.5 is the latest version for the Foxsat.
The source is here: https://git.hpkg.tv/hummypkg/hmt in the "foxsat" branch.
I've successfully built hmt 2.0.11 - but this version appears to expect hmt files in a completely different format from the ones created on my foxsat-hdr.
Click to expand...
That's the HDR-Fox T2 version (2.0.12 is the latest) in the "master" branch.

So you need to do:
Code: 
git clone https://git.hpkg.tv/hummypkg/hmt
git checkout foxsat
The hassle is that the server is very unreliable and frequently times out, so you may need to be patient.
 
Last edited:
I've built the foxsat version of hmt successfully. However, in a few cases, I'm finding that it segfaults whilst trying to process an .hmt file. The point where it fails is display.c:169 - it appears that it's trying to use hmt->epgstart when it's set to NULL. I see that in some of the previous lines, there are tests to see if it's NULL, but not at line 169. (I've only just started looking at this, and as yet, I don't know what the underlying cause is, and whether it's a known issue. In the repository on which I'm trying the hmt utility, there are 1253 .hmt files, and the segfault is happening on only 9 of them.)

I tried to access the git repository to create an issue - but I keep hitting the dreaded nginx "504 - gateway time-out error" message. I'll keep trying. If it's a known issue and is being worked on already, let me know.
 
Last edited:
pwd4361 said:
The point where it fails is display.c:169 - it appears that it's trying to use hmt->epgstart when it's set to NULL. I see that in some of the previous lines, there are tests to see if it's NULL, but not at line 169.
Click to expand...
Nice.
I tried to access the git repository to create an issue
Click to expand...
I wouldn't bother as it's just frustrating my belief.

I've pushed a fix for it, in the style of the rest of the program. Not tested as I don't have any Foxsat .hmt files.
 
The new version seems to work fine: it successfully processed all the .hmt files in the repository, including the ones which caused the segfault earlier. Thanks for the fix.

Yes, I'm only building a version for use in an amd64 environment: I don't have an environment for building or testing a mips version.

One thing with which I've been wrestling. I changed the Makefile to enable the amd64 versions of gcc and strip. However, the build failed with messages like:

undefined reference to `read_uint16'

(similarly for read_uint32)

It seems to be something to do with the fact that the functions in util.c and the prototypes for them in lint.h both include "inline". I found that if I remove "inline" from the prototypes in lint.h, the build completes without errors (it does throw some warnings, but no errors: if you want to see the warnings, let me know). I've not personally used the "inline" directive: I've been having a look at the online gcc manual - it appears that the behaviour of it varies quite confusingly between different levels of C. I'll keep reading and trying to understand this issue - but given that the resulting amd64 executable seems to work fine for my purposes, and that presumably the mips build works with the existing lint.h and util.c files, this probably isn't a major problem.
 
pwd4361 said:
However, the build failed with messages like:
undefined reference to `read_uint16'
(similarly for read_uint32)

It seems to be something to do with the fact that the functions in util.c and the prototypes for them in lint.h both include "inline". I found that if I remove "inline" from the prototypes in lint.h,
Click to expand...
Yes, it does that on some compilers. I took out the inline directives on the T2 version because I couldn't get it to build on a contemporary Ubuntu.
the build completes without errors (it does throw some warnings, but no errors: if you want to see the warnings, let me know).
Click to expand...
I've seen them (if it's the ones about the printf format specifiers and the "if assignment" moan).
I've not personally used the "inline" directive: I've been having a look at the online gcc manual - it appears that the behaviour of it varies quite confusingly between different levels of C.
Click to expand...
It's a bit of an archaic thing from what I can tell. Any decent modern optimising compiler will do this stuff for you without it anyway.

I've pushed another fix and it builds cleanly on a native Ubuntu compiler as well as the Mips cross-compiler now.
Does anybody want to test an updated package on their Foxsat?
 
prpr said:
It's a bit of an archaic thing from what I can tell.
Click to expand...
Yes explicit inline is somewhat archaic.
prpr said:
Any decent modern optimising compiler will do this stuff for you without it anyway.
Click to expand...
Any decent modern optimising compiler is also a total pain in the arse for the low level embedded work I do in C, where we put the code in ROM and use hardware to patch in updates to fix bugs. When the compiler turns the code inside out and back to front you find what was one line of source code to fix now occurs in 5 places and takes 5 precious patch points to fix. Modern compilers lack a "just do the obvious damn you" switch. We deliberately use a compiler version that originated 20 years ago and was last bug fixed 10 years ago to get some optimisation without the compiler going nuts thinking it knows better what I want.
 
Owen Smith said:
Any decent modern optimising compiler
Click to expand...
Not just modern. Old optimising compilers (c1985) were a boon, most of the time. As you say they could be a pita, even for large number crunching work (FORTRAN77 rather than C). Just occasionally a variable or a loop could be optimised in the wrong way. Difficult to find. To use the debugger I needed to turn optimise off. But the ruddy optimiser might be causing the bug! :frantic:. Just what I wanted, wading through a machine code listing.
 
EEPhil said:
But the ruddy optimiser might be causing the bug! :frantic:. Just what I wanted, wading through a machine code listing.
Click to expand...
I ended up doing the same things, either with a listing or a debugger, maybe both. Micro$oft brought out a new version of their C compiler (version 4 I think, around 1986) and it got several new features. One was intrinsic functions and another was loop optimisations. Both seemed like a good idea so I added the /Oilt switch and my code suddenly stopped working. The loop optimiser had optimised away intrinsic functions such as memcpy() and memset() completely and other things didn't work properly. Either option by itself was fine. I can't remember whether they ever fixed it in a point release, but version 5 came along not too long afterwards and was a much better product (with a different, smaller, set of bugs).
Owen Smith said:
so I have to run the debugger on optimised code which can be very confusing unless I debug in assembler view.
Click to expand...
It can be very confusing in either view. The annoyance of when stuff works fine in the Debug build (unoptimised, with symbols), but doesn't in the Release build (optimised, no symbols) often results in trying to build a hybrid version of manual compile options so you can attempt to use a debugger on the Release build.
 
prpr said:
The loop optimiser had optimised away intrinsic functions such as memcpy() and memset() completely
Click to expand...
That's just bonkers! The only way these should have been optimised away is if the resulting memory (that you have copied to/set) is never used. How can the compiler be sure of that? With extreme difficulty.
 
prpr said:
The annoyance of when stuff works fine in the Debug build (unoptimised, with symbols), but doesn't in the Release build (optimised, no symbols) often results in trying to build a hybrid version of manual compile options so you can attempt to use a debugger on the Release build.
Click to expand...
Fortunately I can build optimised with full debug symbols, the C compilers for both platforms I work on give me independent control of both. Our release builds that go to customers can be fully debugged, though we don't give customers the elf files.
 
You must log in or register to reply here.
Back
Top