Auto-Decrpyt failure

[af123]

That's encouraging then. It looks like stripts -E can properly detect whether a recording is encrypted by analysing it. I'll add that to the automatic decryption as a final check before swapping the decrypted version into place.

It's a shame we don't still have access to the failed decrypted recording as that would prove that this would pick it up but the decryption works on a block basis so if decryption has failed then it should not be possible to parse the PAT.

 

[Black Hole]

It looks like stripts -E can properly detect whether a recording is encrypted by analysing it.

To be picky, you mean stripts -E can detect whether a recording is decrypted (which is all that matters). It can't tell whether the data is an encrypted (decryptable) recording or garbage. It would be useful to know when an autodecrypt is rejected, no doubt this will be logged somewhere.

Looks like time for me to ditch unencrypt.

 

[af123]

To be picky, you mean stripts -E can detect whether a recording is decrypted (which is all that matters).

Picky is good, yes you're right. I think this is a robust check as every block in the file should have been subject to the same key during decryption so if the PAT is sound then the AV data should be too.

If decryption fails, it will be logged in auto.log - that may not be enough.
If you routinely decrypt everything, the encsummary and encheck diagnostics are ones that it would be useful to run occasionally.

 

[Lefteris]

I upgraded to rs version 1.0.0 the other day as the banner suggested when I opened it, and since then Auto-Decrypt has stopped working - is this thread to do with that problem, or am I looking in the wrong place ?

 

[Ezra Pound]

That seems to have a double space unlike the listing from 'encheck'.

I think the double space was part of the problem, but there were other naming issues, I have 3 recordings that I re-named with WW2 on the front, also the problem EDDIE file was completely re-named (not sure if I used TV/Remote or Web-if for re-naming) after re-name the on screen name didn't show the WW2 that is visible via web-if / telnet as:-

WW2 Code-Breakers_ Bletchley Park's____20111025_2101.ts
WW2 EDDIE CHAPMAN_20111119_2001.ts
WW2 Operation Mincemeat_20120517_1300.ts

As the file was re-named almost 18 Months ago, it's probably a problem that has gone away and not worth investigating

 

[Lefteris]

To clarify the above post, it appears that auto-decrypt is working on newly created folders, but not on folders existing before the upgrade.

 

[4ndy]

>>> Beginning diagnostic encheck
Running: encheck
/media/My Video/[Deleted Items]/usb-drive2/Carry On Films/Carry On Camping_20130324_1213_shrunk.ts
  HMT marked encrypted:    0
  Stripts thinks encrypted:
+ Version: 1.1.5
+ Debugging level set to 1
/media/My Video/[Deleted Items]/usb-drive2/Carry On Films/Carry On Camping_20130324_1213_shrunk.hmt: No such file or directory
Cannot open HMT file for '/media/My Video/[Deleted Items]/usb-drive2/Carry On Films/Carry On Camping_20130324_1213_shrunk'.
+ Input:  /media/My Video/[Deleted Items]/usb-drive2/Carry On Films/Carry On Camping_20130324_1213_shrunk
+ Output: NULL
+ Opening input HMT file.
/media/My Video/[Deleted Items]/! Shrink/Carry On Camping_20130324_1213_shrunk.ts
  HMT marked encrypted:    0
  Stripts thinks encrypted:
+ Version: 1.1.5
+ Debugging level set to 1
/media/My Video/[Deleted Items]/! Shrink/Carry On Camping_20130324_1213_shrunk.hmt: No such file or directory
Cannot open HMT file for '/media/My Video/[Deleted Items]/! Shrink/Carry On Camping_20130324_1213_shrunk'.
+ Input:  /media/My Video/[Deleted Items]/! Shrink/Carry On Camping_20130324_1213_shrunk
+ Output: NULL
+ Opening input HMT file.
 
>>> Ending diagnostic encheck

Not sure what this means. The recording refered to was one I copied to a folder called "! Shrink" which has auto shrink enabled. I then copied the shrunk file to an external drive and deleted the version in "! Shrink". As yo can see I have undelete installed.

The final file plays OK.