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.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?
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.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.
Sorry for the late reply to this - I was away doing something else.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.
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]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.
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.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.
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.... 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.