Proposed method of auto-decryption on HDR-2000T

EEPhil said:
This is exactly what I've allowed with my attempt at producing the "Foxy-max" utility you proposed. (Whether it ever gets released is another matter-still needs testing, documenting, etc.). As you say, little benefit. Whilst I use the utility all the time (and keep having to modify it), returning decrypted files to the Humax isn't a feature I make use of.


I'm tempted to say RTFM - but I wouldn't say that, would I? ;)
Click to expand...

It's not in the manual, but of course is well documented elsewhere, as it's not a Humax supported capability. Raydon invented Foxy for the HDR-T2 having analysed the structure of the .htm file. It was pure luck that the ftp capability and structure of the .hmt file were retained for the 1800 and 2000T models.
 
Black Hole said:
The recordings are not decrypted (in the sense that I think you mean). This process removes the protection from HiDef recordings so that they will stream just the same as StDef recordings - being decrypted in the process of streaming them, but remaining encrypted on the HDD.

The delay is because the Humax has to re-index a recording after it has been manipulated, before it is available for DLNA streaming.
Click to expand...

Ok but after running the script, I'm able to export my HiDef recordings directly (without any further external processing) to an external drive where they can be archived or edited. A massive improvement over having to bounce things back and forth through FileZilla and HumaxUnEnc. :thumbsup:
 
You are using decrypt-on-USB-copy. The decryption takes place (for StDef, or HiDef once the protection is removed) in the process of copying the data to a USB drive (but the data on the internal HDD remains encrypted).

As you are using wiredcharlie's utility to remove the protection via the network, you may find it more convenient to transfer the recordings directly by network as well. What you need is the Mac equivalent of this: http://hummy.tv/forum/threads/how-to-download-humax-files-to-pc-decrypted.436/
 
Update time... After using the utility for a while I've begun to notice problems. StDef recordings are fine but HiDef content is another matter entirely. The file structure of HiDef material is corrupted, which nearly always causes my editing software to crash and makes it nigh-on impossible to perform "top and tail" removal work, let alone anything more advanced, even if I throw the videos into VideoRedo's Quickstream Fix.

Through a process of elimination, I know it's not a problem with my recordings, the editing software, the T2000 or any other factors such as signal strength because HiDef content that's processed via my traditional route of FileZilla and HumaxUnEnc doesn't have this problem.

At the moment, the 3DC utility is great for performing batch USB copying of SD videos but unfortunately it damages HD stuff and makes them uneditable.
 
grahamlthompson said:
It's not in the manual, but of course is well documented elsewhere, as it's not a Humax supported capability. Raydon invented Foxy for the HDR-T2 having analysed the structure of the .htm file. It was pure luck that the ftp capability and structure of the .hmt file were retained for the 1800 and 2000T models.
Click to expand...
Sorry for the late reply to this - I was away doing something else.
The comment was meant as a dig at BH not the OP. If anyone else doesn't check to see if a question has been answered you often get a link posted by BH. It was a poor attempt at a joke telling BH to read the forum and check - but RTFF doesn't sound right. Ho hum!
Reason for not using emoticon - I normally use IE8 on an old XP system - they don't seem to work. Need to change to Firefox to add them - too lazy!
 
At the moment, the 3DC utility is great for performing batch USB copying of SD videos but unfortunately it damages HD stuff and makes them uneditable.
Click to expand...

It strikes me as extremely unlikely that the 3DC script is the cause. The only extra process that 3DC does is to rename the .hmt .nts .thm and .ts files by adding a "D" to the filenames. This is to force the Humax DLNA server to re-index the material on reboot. [eg Doctor Who_20151114_2015.ts becomes Doctor Who_20151114_2015D.ts and Doctor Who_20151114_2015.nts becomes Doctor Who_20151114_2015D.nts etc]

You could try removing the "D" from the filenames and see if that makes a difference; just in case the filename itself is referenced from within one of the files.
 
How about this for an idea?:

It should be possible to use one of those new RPi Zero modules (or something even smaller and lower power like an Arduino or whatever), power it from a USB port, and connect it to the 2000 by Ethernet - and it just sits there monitoring for new recordings and unlocking/decrypting, maybe even copying/moving decrypted content to a NAS.

As a pre-configured plug-and-play product, it could even be produced as a saleable accessory.
 
I don't think so. Once the protection has been removed, then the decrypted recording can be extracted via DLNA and saved to NAS - or even fed back in via FTP. It would take a bit of work to match up the DLNA index number with the recording title, and then the .hmt would need manipulating to ensure the recording was not tagged as encrypted when it isn't.
 
OK - Yes but even when the Protect Flag has gone the Humax has to be encouraged to re-index and that would require a reboot or file copy.
 
wiredcharlie said:
You could try removing the "D" from the filenames and see if that makes a difference; just in case the filename itself is referenced from within one of the files.
Click to expand...
From memory (so I could be wrong)- The .hmt file contains the filename. Whether the humax makes use of this, I'm not sure. Would make sense to update the filename in the .hmt file - just in case.
On the few occasions I've used my own software to update the 0x3dc flag for a HiDef file I have not found any problems downloading/editing.
 
Black Hole said:
... It would take a bit of work to match up the DLNA index number with the recording title, and then the .hmt would need manipulating to ensure the recording was not tagged as encrypted when it isn't.
Click to expand...
From memory (again) - the DLNA index number and the actual filename are (fairly) easy to match up [I'm just looking at some software I wrote in Java a while back and can't make sense of it!!!] - it looks like the DLNA data contains a "title" and a "value" - the "title" seems to match the Humax's I'm Sorry I Haven't a Clue_20151207_1828.ts format whilst the "value" is ...1234.ts. Knowing that, it should be easy (via the .hmt file) to obtain the actual programme information.
 
Hi guys

I originally posted this on the T2 thread but is also relavent to the 2000T

Made an observation yesterday. I went through my T2 drive and foxy'd every HD recording .hmt file.
I then moved a recording to a different folder to force the re-indexing of it. Streamed perfectly to my lappy, and to my 2000T.
Buy accident I forgot to move another video to a different folder to re-index it before playing it. It was visible in uPnP inspector and streamed straight away.
I tried streaming some of the other foxy'd but not moved recordings and they all stream straight away.
So it would appear that you only need to move one file to cause the whole lot to be re-indexed. That saved a lot of time. Foxy a batch, move one file on the T2 and all will be re-indexed.
This would indicate that the box will re-index all files every time any form of file operation, performed from the remote control (Move/Copy/Delete) etc. is carried out.
Has anyone else observed this behaviour?
 
Last edited:
New version if anyone is interested. I had to update it to work on High Sierra. (Previously using Snow Leopard!!!!!)
 

Attachments

  • 3DC-v4.zip
    590.5 KB · Views: 15
You must log in or register to reply here.
Back
Top