Black Hole
May contain traces of nut
If you know how to implement the decryption, that is! I suppose it might be possible to reprogram another HDR to do it.
I suppose it might be possible to reprogram another HDR to do it.
You think the two events are connected?
Your evidence for this is what exactly? A sample of 1?
Agreed, but in the WebIf you can specify times when the auto-processing (including decryption) does and does not run. I have mine set not to run between 5pm and midnight, which is the time when (a) I watch TV the most and (b) it is most likely to be dual-recording.
Avoiding encryption, and subsequent decryption, entirely would be nice, though...
I used to find that decryption while recording resulted in unwatchable recordings (the discussions are on these forums). We never got to the bottom of why I had problems when other didn't, so I just continue to avoid doing the two together.
Yes, that's the eventual aim but given the 1,373,453 lines of assembly language here, I'm starting by trying to get a better understanding of anything I can...
It might be nice to have a package to allow reprogramming - at least I could give all of my boxes the same key for example (or my HD unit the same key as my HDR
It's fine om mine. Just a little pixelation at the crop point on the auto ad crop points. Haven't noticed any particular slow down when detectads is running doing its magic.
It is already there in WebIF. Go to Settings then Advanced Settings. This is how I have done it on my two machines:is there a 'package' we can/could add in the webif (similar to adding the 'Auto-Unprotect' package for example) that completely automates the whole "...changing the encryption/serial number" thing,
I'm wondering if it does, I had assumed that any recordings encrypted with the original key would not get decrypted if you 'set' the custom key to something different, I have not tried it but thought that you needed to decrypt all existing recordings before changing the keyThis setup allows recordings in the original key or the custom key to be viewed.
I'm wondering if it does
Hopefully I don't have the wrong end of the stick...The decryption de-queue process now tries a number of encryption keys in direct mode - it will try whatever is in/mod/boot/cryptokey
, the current key as reported bynugget
and the box native key. This allows changing the key but still allowing old files to decrypt properly (and other scenarios..)
...i was wondering if you've made any progress on your "side project" ?? - I'm sure i'm not alone in wanting future recordings to bypass the automatic encryption process completely.
No, I'm afraid not, but it is still on my list (just below making disks > 4TB work)
...The task should be to identify whether there is a configuration flag which determines whether received video data is fed through the encryption engine at all
I think the object of the exercise is to bypass the whole encryption process as was done by nowster on the Foxsat.
How about decrypt all then put the same encryption keys on all three boxes. Or put the key bof the 'main one' on the other two after decrypting what's on them already.
Be a bit of a pain to start with, but once done, the material will run on any of them.
As per post #51
I suspect that most of us know that anyway, but the very clever people here have not yet been able to create the 'Nowster's patch' equivalent.so bypassing automatic encryption process alltogether completely makes sense.
Because we do! It doesn't matter how much you would like it to be otherwise – it isn't, and until somebody comes up with a solution such as the equivalent of Nowster's Patch, that's the way it is. It is entirely possible there is no way to do this at all.Why should we have to decrypt at all?