crashing and green screen

[Tik33]

thanks both, in general, it's the ones that are being moved (cut) are the ones that I'd want to delete - so hopefully that will work!
After 'cutting' they remain in the folder? is that normal?

 

[Black Hole]

Yes. You will see a list of files you have selected to be cut, the cut does not occur until a successful move.

 

[Tik33]

hi everyone,
apologies for silence, have been away and then had various problems with internet etc - so finally got that all sorted (for now!)

some of the movies seem to be working fine, and some are not.

not sure if the ones that are not are fixable though so would appreciate your thoughts!

here's an example - the movie would seem to be decrypted and ok:


however, under OPT+ and 'sidecar files' it says:

"WARNING: Could not find Program Map Table. Recording is encrypted or invalid type. Cannot extract any information from recording. "

when I run 'create new NTS file' it says
"WARNING: Recording encrypted. Cannot replace existing NTS file. Decrypt, then run 'sidecar' again to replace with a valid NTS file. "
and similarly for the HMT file
"Cannot update the existing HMT file. Decrypt, then run 'sidecar' again to update the HMT file. "

is this saveable?!

thanks!

 

[Black Hole]

the movie would seem to be decrypted and ok

What do you mean OK? That it shows the "dec" icon is just an indicator of the state of the flags in the .hmt sidecar file. If the flag says "treat as decrypted" but the .ts is actually still encrypted (or in some other way scrambled), there will be no success playing it and it is most definitely not "OK".

 

[Tik33]

What do you mean OK? That it shows the "dec" icon is just an indicator of the state of the flags in the .hmt sidecar file. If the flag says "treat as decrypted" but the .ts is actually still encrypted (or in some other way scrambled), there will be no success playing it and it is most definitely not "OK".

ah - i didn't know that - so is there any chance to decrypt it? or perhaps its corrupt? is there any way to find out whether the file is corrupt or whether I can salvage it?
thank you!

 

[Black Hole]

What, exactly, is the history of that particular file? The process of salvaging it requires reversing each step that got it to where it is now... precisely. The steps required cannot be determined by inspection, only by knowledge of the history.

So, for example, if an encrypted recording from HDR[1] (all recordings are encrypted in the process of recording) is transferred to HDR[2] and decrypted, it has been (effectively) scrambled twice. You would need to unapply DECRYPT[2], then apply DECRYPT[1] to obtain a recording in-the-clear.

Fortunately we now have PC tools capable of applying ENCRYPT and DECRYPT, so long as you can obtain the serial number and MAC for HDR[2] (from which KEY[2] is obtained, the necessary input parameter to make the generalised ENCRYPT and DECRYPT functions into ENCRYPT[2] and DECRYPT[2]). However, unless you know exactly what encrypt and decrypt operations to apply, with what keys, and in what sequence, you would be fishing in the dark (apply the wrong operation, or with the wrong key, or in the wrong order, and you would be making it worse not better).

For constant k:

DECRYPT[k]( ENCRYPT[k](file) ) = file

ENCRYPT[k]( DECRYPT[k](file) ) = file

DECRYPT[k](file) ≠ ENCRYPT[k](file)

The DECRYPT function scrambles a file just as effectively as the ENCRYPT function, unless the file was originally encrypted with the same key.

 

[Tik33]

What, exactly, is the history of that particular file? The process of salvaging it requires reversing each step that got it to where it is now... precisely. The steps required cannot be determined by inspection, only by knowledge of the history.

So, for example, if an encrypted recording from HDR[1] (all recordings are encrypted in the process of recording) is transferred to HDR[2] and decrypted, it has been (effectively) scrambled twice. You would need to unapply DECRYPT[2], then apply DECRYPT[1] to obtain a recording in-the-clear.

Fortunately we now have PC tools capable of applying ENCRYPT and DECRYPT, so long as you can obtain the serial number and MAC for HDR[2] (from which KEY[2] is obtained, the necessary input parameter to make the generalised ENCRYPT and DECRYPT functions into ENCRYPT[2] and DECRYPT[2]). However, unless you know exactly what encrypt and decrypt operations to apply, with what keys, and in what sequence, you would be fishing in the dark (apply the wrong operation, or with the wrong key, or in the wrong order, and you would be making it worse not better).

For constant k:

DECRYPT[k]( ENCRYPT[k](file) ) = file

ENCRYPT[k]( DECRYPT[k](file) ) = file

DECRYPT[k](file) ≠ ENCRYPT[k](file)

The DECRYPT function scrambles a file just as effectively as the ENCRYPT function, unless the file was originally encrypted with the same key.

thanks for that Black Hole, I think understanding what has happened to that file precisely might be hard. It might in fact be easier to delete and copy again from one of the back ups (which is either an external HDD or the original suspect Humax HDD) and start the decrypting process from scratch.

Also, I currently have 133 recordings - to make deleting/pasting/copying more time efficient - is there anyway to quickly ascertain which files are scrambled / encrypted and which aren't without having to open each file and trying it?

thanks!

 

[Black Hole]

I think there might be command line tools able to analyse a .ts - I defer to somebody with more knowledge.