[badnts] Package To Clean Up Faulty BBC3HD/BBC4HD Recordings

Presumably, if you wanted to indicate it on the box itself, the only options available are either a prefix added to the programme name (e.g. [fixed] ) or a custom thumbnail.
 
HarveyB said:
Innocent question ...
So on that basis, if you got into that situation, presumably you could copy any old .hmt file, from another unencrypted file, and rename it to match .ts file.
Would that then enable the unencrypt/decrypt process?
Click to expand...
I was having a look at this last night (I don't have a failed recording so I used a regular one). I took an unprotected, encrypted recording and deleted the HMT. I replaced the HMT with similar and renamed it to match. This gave a 'channel is scrambled' message on playback and the programme could not be decrypted. I then replaced the HMT file with one from an already decrypted programme and renamed: this also gave a 'channel is scrambled' message when played. However, this file is now flagged as 'Dec' and I have not been able to remove the flag. I know about the HMT utility which can be run using Telnet, but I can't work out how to use this tool within a specific directory. I tried 'cd' followed by the path, but this did not work: my syntax was probably wrong. I am also unsure which command I need to clear the 'Dec' flag.

On another HMT related matter, has the content of these files changed? I noticed that all the HMT files on one of my HDRs for programmes recorded within the last 6-9 months have a file size of 2.02KB. Before this time, the size varies and can be up to 15KB or so. I was wondering if one of the standard firmware updates changed what was written to this file?
 
MontysEvilTwin said:
This gave a 'channel is scrambled' message on playback and the programme could not be decrypted.
Click to expand...

That's what I would expect. The HMT file includes information on how to find the audio and video streams in the TS file. It isn't hard to recreate but one from a different recording will not work.

On another HMT related matter, has the content of these files changed? I noticed that all the HMT files on one of my HDRs for programmes recorded within the last 6-9 months have a file size of 2.02KB. Before this time, the size varies and can be up to 15KB or so. I was wondering if one of the standard firmware updates changed what was written to this file?
Click to expand...

Have you switched from padding to AR? When a recording spans multiple EPG events the HMT file gets extra EPG data appended.
 
MontysEvilTwin said:
On another HMT related matter, has the content of these files changed? I noticed that all the HMT files on one of my HDRs for programmes recorded within the last 6-9 months have a file size of 2.02KB. Before this time, the size varies and can be up to 15KB or so. I was wondering if one of the standard firmware updates changed what was written to this file?
Click to expand...
All the same on 3 different versions using Sudbury transmitter and this morning's Arthur on CBBC HD. All were 1 minute repeat timers. The 1.03.06 has a different name because I set it up on the day when Just Kidding was in the next 7 o'clock slot.

1.02.20 Encrypted/Protected
•Arthur_20140110_0702.ts (49.65 MiB)
•Arthur_20140110_0702.nts (115.94 KiB)
•Arthur_20140110_0702.hmt (12.88 KiB)
•Arthur_20140110_0702.thm (42.66 KiB)

1.02.32 Encrypted/Protected
•Arthur_20140110_0702.ts (53.08 MiB)
•Arthur_20140110_0702.nts (110.75 KiB)
•Arthur_20140110_0702.hmt (12.88 KiB)
•Arthur_20140110_0702.thm (42.66 KiB)

1.03.06 Encrypted
•Just Kidding_20140110_0702.ts (53.16 MiB)
•Just Kidding_20140110_0702.nts (113.56 KiB)
•Just Kidding_20140110_0702.hmt (12.88 KiB)
•Just Kidding_20140110_0702.thm (42.66 KiB)

The 1.02.20 has a 30 second clock drift which probably accounts for the ts file being a different length due to only half its contents matching the other 2 recordings.
 
af123 said:
That's what I would expect. The HMT file includes information on how to find the audio and video streams in the TS file. It isn't hard to recreate but one from a different recording will not work.

Have you switched from padding to AR? When a recording spans multiple EPG events the HMT file gets extra EPG data appended.
Click to expand...
I wasn't expecting that swapping the HMT file would give a playable file, but it was discussed briefly in an exchange between Black Hole and HarveyB and I thought I'd have a quick play.

Re. the HMT file length, on both my HDRs, all recent files seem to be 2.02KB. HD or SD, encrypted or decrypted, cropped or not-cropped they are the same length. My standard set up is padding (2 mins before, 5 mins after), but I did do a couple of recordings recently with AR (Web-If, padding still as the default setting): 2.02KB. I am on 1.03.06/ CFW 2.20: I tend to keep up to date with versions. On my older HDR, if I go back more than 6 months, the HMT file length is larger and variable. I don't know why this is, but it does not seem to be causing problems: I had 2 failed recordings recently (not related to the ongoing HD issue) but this is probably not the cause (generally recording failures are very rare for me).

Edit: Luke's HMT files are also a consistent size, just 6x larger than mine at 12.88KB. I guess the difference is due to the way our systems are configured.
 
You can use the hmt utility to see if there is any EPG data in them. I use AR so most of mine are 2K but some are bigger:

Code: 
humax# ls -l *.hmt | tr -s ' ' | cut -d\  -f5-
2.0K Nov 30 2012 Iron Man_20121102_1838.hmt
2.0K Dec 24 15:49 It's a Wonderful Life_20131224_1313.hmt
2.0K Aug 10 22:30 Jesse Stone_ Innocents Lost_20130810_1728.hmt
2.0K Mar 9 2013 Skyline_20130309_2103.hmt
2.0K Dec 28 01:14 Spiderman 3_20131227_2101.hmt
2.0K Dec 28 01:14 Spiderman 3_20131227_2211.hmt
2.0K Jan 3 20:57 The Dam Busters_20140101_1829.hmt
13.6K Jun 18 2012 The Sixth Sense_20111007_2102.hmt

Code: 
humax# hmt The\ Sixth\ Sense_20111007_2102.
...
EPG Blocks:3
  Block:1 Time:0 Offset:0x30c0
    Block1_Title:i7The Sixth Sense
  Block:2 Time:7511 Offset:0x3380
    Block2_Title:i7Raising Arizona
  Block:3 Time:0 Offset:0
 
MontysEvilTwin said:
I was having a look at this last night (I don't have a failed recording so I used a regular one). I took an unprotected, encrypted recording and deleted the HMT. I replaced the HMT with similar and renamed it to match. This gave a 'channel is scrambled' message on playback and the programme could not be decrypted. I then replaced the HMT file with one from an already decrypted programme and renamed: this also gave a 'channel is scrambled' message when played.
Click to expand...
For it to be playable you would have to copy the hmt file from another recording made on the same channel (or hack the PIDs within the hmt file). This assumes that both recordings have the same encryption state.
I know about the HMT utility which can be run using Telnet, but I can't work out how to use this tool within a specific directory. I tried 'cd' followed by the path, but this did not work: my syntax was probably wrong. I am also unsure which command I need to clear the 'Dec' flag.
Click to expand...
Code: 
cd "/media/My Video"
hmt "Some Recording.hmt"
hmt -encrypted "Some Recording.hmt"
 
I said:
I know about the HMT utility which can be run using Telnet, but I can't work out how to use this tool within a specific directory. I tried 'cd' followed by the path, but this did not work: my syntax was probably wrong. I am also unsure which command I need to clear the 'Dec' flag.
Click to expand...
xyz321 said:
Code: 
cd "/media/My Video"
hmt "Some Recording.hmt"
hmt -encrypted "Some Recording.hmt"
Click to expand...
Thanks xyz321, my syntax was wrong, I missed out the quotes.

Ezra Pound: could you put this example in the Wiki? In three lines it explains how to actually use the tool.

Edit: for clarification and context.
 
MontysEvilTwin said:
Thanks xyz321, my syntax was wrong, I missed out the quotes.
Click to expand...
You only need the quotes if the path contains spaces. Otherwise, the separate elements of the path (separated by spaces) will get treated as separate parameters for the command (in this case, the "cd" command).
 
To be fair, the majority of recordings probably contain spaces and quotes won't harm those that don't. It's a reasonable default.

Another useful trick at the command line is to type the first few letters of the path name then press tab. The shell will automatically complete the name as far as it can, adding backslashes as necessary to escape the white space and then show you the remaining matches if there are multiple. Then you can type a few more characters and press tab again.
 
MikeSh said:
If you do recreate the HMT can I suggest that it include something to .…....Maybe even a bespoke icon for it (both webif and on the box if possible).
This would help us keep track of failures and allow some certainty of when the problem has been fixed .... if ever :rolleyes:
Click to expand...
Tonight webif highlighted that there was a Onts recording (badnts installed). The file played o.k. on the HdR but as expected no 'trick play functions' .
 
Based on my experience, a channel retune on a HDR-FOX T2 running 1.02.32 recreates the "0 sec" issue on BBC3 HD and BBC 4 HD. BADNTS makes the files playable. Watching and then recording live TV on each channel ensures future recordings are correct........although quite probably only until the next retune (I'll be prepared next time).

I referred to this in another thread, but now post here as it may help others.
 
I have installed badnts and I have set a folder (containing a 1.1GB recording that is showing zero on the TV UI) to auto-decrypt.

When does auto-decrypt run?
 
You must log in or register to reply here.
Back
Top