HMT File has wrong recording length

LittleErn

New Member
Here's an interesting one - don't know if anyone's seen this before.

I've just recorded - and watched - the 1986 World Cup film of BBC2HD this morning and, although the recording completed OK (the .ts file is all there), something has caused the .hmt file to log that the recording finished after 45 minutes. The upshot is that as long as it's playing at the 45 minute point and you don't use any transport control (pause/rewind/skip etc.) then it will continue to play until the end.

Now, I've had this happen once before and didn't really worry about it - it was a throwaway recording, I watched it and deleted it - but this one is a 'keeper' and so I want to first crop the ends off and then archive to an external drive. I haven't yet tried to see what would happen if I try the copy, but I obviously can't set the final bookmark to enable the crop.

Somehow, I need to change the .hmt file to include the full length of the recording. I've had a look at the notes for the hmt utility and there doesn't appear to be an option to change the length/end time - so I think I might need some assistance.

Can anybody help, please?
 
I've had this problem before. Put a bookmark at the start of the recording and at the end: once you get to the end of the green line (45 mins in this case), you should still be able to skip forward. Go to the end of the programme and bookmark: it will put the end bookmark in the right place. Then if you use the Web-If crop function the hmt file will be fixed in the cropped version and show the correct file length.
 
No, that doesn't work, I'm afraid - whenever I try to skip (using either the skip button or the right arrow) beyond the 45 minute point it just keeps returning to that point. The only way it will go past there is in normal playback, and if I hit the bookmark button at any point after that, it sets the bookmark at one second before the end of the logged (45 min) duration.
 
Thanks both, but I've already tried that - the bar is only 45 minutes long. And it won't accept a value typed in that is longer than the duration in seconds that the hmt file holds.
 
Incidentally, the copy to the external drive succeeded in copying - and decrypting - the full recording, but it just took the .hmt file across as was and so the copy has the same problem as the original.
 
Strange! It would be possible to fix the hmt but there isn't a utility for that. It's actually quite simple to write one in Jim but not from here.
The command line hmt tool will allow you to set a bookmark past the end of the recording. You could try that and then the nicesplice trick already mentioned.
 
Cunning plan, but no luck. The crop screen said it was going to keep 190.85% (!) and happily went about it, but then actually cropped the recording at the 45 minute point...
 
Thanks both, but I've already tried that - the bar is only 45 minutes long. And it won't accept a value typed in that is longer than the duration in seconds that the hmt file holds.
Interesting, when something similar happened to me the box locked up while recording. I could still open Web-If and could see the file was growing. I had to do a cold restart to get the box working properly after the recording had completed. The programme then appeared to be too short, but played OK after the end of the timer bar, with transport controls and I fixed it as I described above.
Another thing to try. Make sure the file is decrypted. Find or create another recording on the same channel of approx. the correct length and decrypt. Use FTP or another tool to move the wonky hmt file to a different folder. Copy in the hmt from the other recording and rename to match. Play the recording, bookmark, crop and edit the media list name and guidance text. This might work as long as both are all decrypted and the second recording was made on the same channel.
Alternatively, If the programme was on the Beeb, you could download the mp4 from iPlayer.
 
Ta - I might give that a go when I've got a bit of time. When all's said and done though, I do at least have a decrypted copy which is complete - it just can't use any 'trick play' or resume after the 45 min. point; which is not a disaster.

Thanks to all for the ideas.
 
As decryption was successful, my last suggestion may well work. You could always try deleting all the sidecar files (move to another location at first, to be safe). The TS file will still play: the Humax will create a matching HMI file and you will get skip forward and back and resume functions. I'm not sure if REW and FF functions still work though. EDIT: they won't work, but the skip buttons do.
 
I've just recorded - and watched - the 1986 World Cup film of BBC2HD this morning and, although the recording completed OK (the .ts file is all there), something has caused the .hmt file to log that the recording finished after 45 minutes. The upshot is that as long as it's playing at the 45 minute point and you don't use any transport control (pause/rewind/skip etc.) then it will continue to play until the end.
I've had this happen about eight times. Sometimes nothing will fix it, despite trying every permutation of process I can think of.

However sometimes putting one bookmark only at the beginning of the original file, and running it through nicesplice, will result in an output file showing a corrected recording length. Then it can be cropped again with more bookmarks if necessary.

So its always worth a try with just one bookmark at the beginning.

Also, as a different kind of solution, put the title of the programme into remote scheduling, then if it is shown again (as so many programmes are!) it'll be automatically recorded for you. A set and forget option to get an error-free version eventually.
 
I have recorded Top Gear from Dave today and ended up with a failed "loss of power" recording that claims to be 176 minutes long. That's on a HDR-FOX using 1.02.20.

I will investigate and provide more details later, but maybe something in the auto-processing is corrupting .hmt files? My auto log is going to be huge since I last cleared it (I thought we were going to start a new log file each day?).
 
If you upgrade hmt then you can use it to patch the recording length in your broken HMT file. Example:

Code:
humax# hmt 1_6_New\:_In_The_Flesh. | grep -i duration
Scheduled duration:3600
Duration:3532
Stored duration: 3529
 
humax# hmt +patch16=648:1234 1_6_New\:_In_The_Flesh.
Patching width 16 - 648 = 1234

humax# hmt 1_6_New\:_In_The_Flesh. | grep -i duration
Scheduled duration:3600
Duration:3532
Stored duration: 1234

You need to know the offsets that Raydon worked out (which he's published at http://hummy.tv/forum/threads/software-to-generate-nts-files.4031/#post-50829) but the 16-bit value at offset 648 is the stored recording duration. That will still leave the stored end time wrong. If you want to patch that then it's the 32-bit value at offset 644.

Code:
humax# hmt 1_6_New\:_In_The_Flesh. | grep -i end
Recording end:1399240797 (Sun May  4 22:59:57 2014)
humax# hmt +patch32=644:1399240737 1_6_New\:_In_The_Flesh.
Patching width 32 - 644 = 1399240737
humax# hmt 1_6_New\:_In_The_Flesh. | grep -i end
Recording end:1399240737 (Sun May  4 22:58:57 2014)
 
The answer to my 179-minute recording is that it really was! Cock-up on the AR front. No clues in auto.log.
 
Back
Top