crashing and green screen

[Tik33]

Once you have stopped all current work in the queue you can start preparing to start testing with individual files.

• Check Queue display and there is nothing queued for decryption
• Install the Undelete package
• Uninstall Chasedecrypt and Chaseget packages - they are unnecessary for basic decryption and a distraction
• Check Custom encryption key in advanced settings Exactly matches the Native encryption key of the old Humax
• Check Create backup files in dustbin for decrypt and shrink? is YES in Auto processing setting

thanks very much for this very helpful idiot-proof guide!
I have done all the above.
I will move on to next section now and will report back

 

[Tik33]

• For recordings that already have DEC flag - can you view them on TV?
• In Browse choose a smallish, unimportant recording that doesn't yet have the DEC flag
  • Select it by clicking on the check box in Browse
  • Click on Queue for decryption at bottom of page
  • Wait for it to process
  • Check Queue display to ensure it completed successfully
  • In Browse check that it now has DEC icon
  • Check you can watch recording on TV
  • Repeat for a few more recordings

Can view DEC flagged recordings on TV
however, just to note - I do seem to be able to view all recordings (not just ones with DEC) - have tested on about 10 without DEC flag and all have worked on the TV
will do a few decryptions of files anyway

 

[MymsMan]

have tested on about 10 without DEC flag and all have worked on the TV
will do a few decryptions of files anyway

That is good news and shows the decryption key set up is now correct - the Humax has to be able to decrypt on-the-fly to let you view encrypted recordings

 

[Tik33]

• Check you can watch recording on TV
• Repeat for a few more recordings

all seemed fine (although as I said - they were working before the decryption too).
for completeness - I did find an HD movie (which also worked) - and am decrypting that to see if that works

 

[Tik33]

Once you are comfortable that individual recording are decrypting OK

• Record a programme on the new box, decrypt as above
• Set auto-decrypt flag for a single folder with not too many recordings in it
• Check all recording decrypt OK and and are viewable

ok - have recorded 3 small programmes. 2 SD and 1 HD - all recorded and viewed back fine.
have decrypted all 3 and all viewed fine too

in terms of single folder in the next step - would you like me to set up a new folder with new recordings? or use an existing folder where files haven't decrypted already?

 

[Tik33]

• Set Create backup files in dustbin for decrypt and shrink? is NO in Auto processing setting
• Set Recursive Auto decrypt on for the My Video folder
• Leave box on overnight to process the backlog
• If all is OK then you can turn autoshrink and other options as needed

the first bullet is done.
Wasn't sure how to do the second one - I did this by using the opt+ button next to 'my video' folder - the auto-recursive icon has appeared - but there's been no changes in the queue - is that correct?
in order to leave box on overnight - I'm assuming I turn off the automatic power down

 

[Tik33]

Wasn't sure how to do the second one - I did this by using the opt+ button next to 'my video' folder - the auto-recursive icon has appeared - but there's been no changes in the queue - is that correct?

scrub that - they've now appeared in the queue - will leave box on overnight and report back

 

[Black Hole]

Take baby steps not big leaps

Wise words.

 

[EEPhil]

It is possible, but will not be straightforward, to unscramble the resulting mess

"Someone" could create a utility that would encrypt using box2's key. That does need thinking about because not all of each packet is encrypted. Where a packet has been encrypted on box1 and decrypted (wrongly) on box2 it is possible some of the information required is not readily available. It's an interesting problem. Not sure I want to look at it or offer any hope of recovery!

Just a follow up to this:
I've taken an encrypted Fox-T2 file (af123's Pointless) and tried to decrypt it using the wrong key (my 2000T's MAC and serial number). (Used the HFODU2 with decryption checking turned off). Obviously, the output is unusable. I tried taking the HFODU2 utility and just replacing "decrypt" with "encrypt" on one line and leaving all the rest of the program the same, and running it on the wrongly decrypted output. The resulting output is identical to the original encrypted file. Hence it is now possible to decrypt using the correct key.
If wrong box decryption really is the cause of OP's problem then recovery might be very easy!

 

[Black Hole]

If wrong box decryption really is the cause of OP's problem then recovery might be very easy!

Not "easy" as in "we already have the tools to do this" though - just that you would be able to provide a modified version of your off-box off-line decryption tool that might be able to reverse the damage.

 

[EEPhil]

"Easy" as in there is not a lot of complicated reworking of the program logic. But I take the point. Under normal circumstances who would want to encrypt a file? Therefore why would "we" provide a tool to do this? If really needed, it could be provided without too much effort (but probably not enough rigorous testing).

 

[Black Hole]

It might be useful (or may have been useful in the past) to be able to encrypt a file to test decryption...

 

[prpr]

It might be useful (or may have been useful in the past) to be able to encrypt a file to test decryption...

I agree...

 

[EEPhil]

I'll give it a bit more thought. If I decide to provide it (no changes in logic required but some cosmetic changes and modifications to the help file) I'll stick it on the HFODU thread.

 

[MymsMan]

So is it the case that decryption with the wrong key can go undetected, resulting in effectively a double-enncrypted
file,

1. with the T2 hardware-assisted decryption invoked through the DLNA server?
2. with the T2 hardware-assisted decryption invoked through USB copy?
3. with the software-based decryption using stripts (eg v1.4.3)?

In the third case the program is capable of checking the key against the recording, so I expect that answer to be no.

I don't think so,

1. I changed the encryption key on my machine after recording the news and then submitted it for decryption it failed

   decrypt: /mnt/hd2/My Video/BBC News/BBC News_20190210_2300.ts - File did not decrypt properly.

   , from the time taken it did do a full decryption before detecting the failure but the important point is it was detected and the corrupt output was not saved.
2. I copied the recording to a USB stick and in didn't report an error but flagged the file a Decrypted and I couldn't decrypt it again using stripts
3. Using the software decryption it attempted to use both the custom key and native key and reported a failure if neither matched the key used for encryption
4. I also tried the Browse Opt+ while you wait Decryption (hardware assisted) and that did not report a key error which would appear to be a bug since the Queued methods do/

I think the predictions of unrecoverable corruption are only partially warranted - both Queued methods supported by the webif do correctly detect an invalid decryption keys as does the Humax when playing a video.

It is only if you use the Humax copy to USB method or Opt+ Decryption that an incorrect key is not detected at the time resulting in an unusable recording, whether it could be recovered I don't know

NB I didn't try @EEPhil's tool.

Editted to add Opt+ problem

 

[EEPhil]

I don't know enough about the on-box decryption utilities, but I thought that MymsMan's observation in "Code:" is how it ought to be. HFODU2 follows af123's idea of checking whether a file is decrypting by checking a stored and calculated CRC.
I'm not sure how the OP has corrupted the recording.

I also tried the Browse Opt+ while you wait Decryption (hardware assisted) and that did not report a key error which would appear to be a bug since the Queued methods do

Perhaps I am now!

If it really has been decrypted with the wrong key - it should be possible to recover the original (but encrypted) file providing we know the key used to wrongly decrypt. (Are you still following?).

NB I didn't try @EEPhil's tool.

The existing tool would only try to decrypt. If the key is wrong it should spot it after a few frames as the CRC check fails. I'm going to post another tool, snappily titled HFOEU (not a reference to Brexit, but Encryption Utility) on the HFODU thread as all the installation detail and most of the help are the same for both tools. Find tool here

 

[MymsMan]

I'm not sure how the OP has corrupted the recording.

I am not sure the OP actually has corrupted any recordings, now that he has the custom key set up correctly it appears that all recordings are viewable and decryptable.

 

[Tik33]

I am not sure the OP actually has corrupted any recordings, now that he has the custom key set up correctly it appears that all recordings are viewable and decryptable.

Yes, I can confirm that all the files in the queue are now decrypted and every recording that I have tried to access has been viewable and every recording on the webif browser has 'DEC' marked against it (including the HD recordings).
So we are making great progress and thanks to all for contributions thus far!

the next thing I'd like to do is to rename the files so that i know what the movie actually is (see snippet here):



does anyone know how to do this simply? or have the original file names been overwritten somehow and lost forever?

Finally, (if/when) I can rename those files - I'd like to transfer them to my new 2TB drive so that I can start recording new movies. Can anyone kindly do another idiot-proof guide to the best way to do this?

thanks again!

 

[MymsMan]

does anyone know how to do this simply? or have the original file names been overwritten somehow and lost forever?

I think this is because you had the auto-dedup option set on the My Video folder, this is great on Some series folders - especially kid series allowing me to find the correct episode of Bitz and Bob from my granddaughters description, but much less helpful for one off programmes as you have discovered.
It is an option that it well worth experimenting with the manual version via the Opt+ option to see if works sensibly for a series before using the auto version.

AFAIK the original names are lost forever and the only option is tedious renaming of each recording (opt+ menu) unless someone could think a way of using the recording date/time and channel to search some archive to find the original recording title - perhaps activity.log has enough information

I'd like to transfer them to my new 2TB drive so that I can start recording new movies

There is nothing stopping you from starting new recordings now!
But it would probably be best to install your 2TB drive into the Humax, resinstall the webif and all of your other packages (using your list posted earlier) and get that working first.

To move files between drives you need a USB disk cable or disk caddy so that you can connect the second drive to the Humax as an external USB drive.
But unless you have another use planned for the old drive why bother to copy the files (it will take quite a time), just leave the disk plugged in and play the old programmes directly from the USB disk - Effectively you will a Humax with 3TB capacity, or do the copies over a few weeks,

 

[EEPhil]

I am not sure the OP actually has corrupted any recordings, now that he has the custom key set up correctly it appears that all recordings are viewable and decryptable.

I wasn't sure either. And now the problem is resolved I won't bother with my other 2p worth of suggestions.