Well you're wrong there to start with. Everything is encrypted on recording.
You are indeed wrong, as you would know if you read anything about what you're trying to do instead of diving in head first. Do you not recognise what I meant by "learn to walk before you try to run"? Things Every HDR-FOX Owner Should Know (click), section 5.
Yes. Many of us are not Sky fanboys, this isn't a Sky forum, and not even a Sky section... so why would we automatically know and why would you want readers to scratch their heads? Why couldn't you have simply said something like "Auto-decrypt doesn't seem to be working for recordings made by broadcasting the HDMI output from a SkyQ box via a DVB-T modulator" – clear, concise, and to the point. It's not SkyQ at issue – that's just obfuscation, the modulator is the key point. However, see next item...
Doesn't that sound alarm bells? Can't you work out that if there is no auto-processing activity, nothing will get auto-decrypted (whatever the source)? Fix it, then your "problem" goes away (probably).
Bollox. I'm just continually frustrated that the hundreds or thousands of hours I have put into documenting this stuff gets totally ignored by the likes of you, who then post a load of crap, are cocky about it, and can't take the resulting criticism. You're insulting the people most likely to be able to help. Primary rules: be clear, use language everyone can understand, don't make unwarranted assumptions. And your spelling could improve too. Newbies' Guide to the Forum (click - but you can't take advice so you won't take that advice either... go on, prove me wrong).
Yes. As above, I think that's the root of the problem and where the recording actually originated is just a blind.
Thanks BH, that's a much bigger(!) clue.
There have also been timeout issues with the manual webif processes if the host doesn;t respond within the deadline set by the web page
From
/mod/webif/lib/auto/plugin/decrypt/queue.hook: } else {
log " Direct decryption" 0
set key [$ts getkey $mode]
if {$key eq ""} {
return {"FAILED" "No matching key for decryption"}
}
::auto::log "Using key ($key)" 2
if {[catch {exec /mod/bin/stripts -@ $key $rfile "$tmp/[\
file rootname $bfile]" } msg opts]} {
::auto::log "Decrypt error - $msg - $opts"
system endop decrypt
return {"FAILED" "Decryption failed"}
}
}
Did you look for info. In the Wiki ?, here is the Strips entry :-
To satisfy my idle curiosity, could you please go back to the HDR and report the size of file that fails to auto-decrypt and the amount of available hard drive space.
Yes, really. It took me a while to work out what you were probably blathering on about. I didn't bother after that.
So make a 30s recording, that being the minimum the device will do, and upload it (.ts and .hmt) to a file-sharing site of your choice e.g. Dropbox, and tell people where to find it. You will also need to state your encryption key (MAC address and serial number of the box will do, or you can read it off the WebIf).
Yes, that is indeed what I thought.
Under those circumstances what if any, errors would I see?
Yes, I'm with you on the thinking there.
In all other situations where I've reported issues with using software, or asking advice one of the key items requested is the error message I get.
What conclusion? I've not concluded anything.
It's the error message I get! Error messages are often used as titles when asking for advice.
I've not done anything along those lines that I know of.
I realised some time ago that nothing I do will ever be right, you clearly enjoy having a go.
Thanks for the instructions, I'll have a try at doing that shortly.
More than willing to do that, would you advise how I should go about it please? I wouldn't expect to attach a video file to post here.
Before trying that make a short recording from a normal terrestrial channel and check whether auto-decrypt works for that.
Yes of course thank you.To satisfy my idle curiosity, could you please go back to the HDR and report the size of file that fails to auto-decrypt and the amount of available hard drive space.
Then I'll back away knowing which tree I was barking up. Cheers
The inaccurate progress completion report is caused by a bug in the WebIf where the progress monitoring JS function is timed out by the web server (IIRC default is s/t like 6 or 10 minutes). It affects any long-running command launched by the WebIf client code (eg, media conversion/extraction). As far as the script logic is concerned the operation was aborted, and the output file doesn't get renamed, but it's actually still running.
The modulator breaks the protected HDMI chain, at the cost of re-encoding the digital AV stream in MPEG2. A DVB-T USB receiver would allow the Q content to be saved to disk with no encryption.
The manual decryption makes you select either DLNA or direct decryption, whereas the queue-based decryption has different logic and tries to select the best method automatically.
As I previously pointed out, this means that no key known to the
getkey() method matched the encrypted .ts. If the file isn't corrupt, the testing method must be wrong, but I ran some examples and I still believe it. It does this sort of thing (-q\ just reports 1 or 0 for match or 0, -/ prints a detailed report):# stripts -q/ 00000000000000000000000000000000 The\ Taming\ Of\ The\ Shrew_20210718_0909
1
# echo $?
0
#1, for all the keys tested.
I want to do this I really do but I have two issues I need to get past first.
Ten minutes of DVB-T MPEG2 HD 1.3GB
.Start an instant record, monitor a clock with seconds display and press stop - needs to be followed with choosing the recording to stop and confirm via onscreen display.
That explains a lot, to me anyway.
Yes, that was my understanding.
Really? That hadn't dawned on me if I'm honest but it follows from the previous statement.
I just use the web interface and the opt+ button on the file to decrypt manually. I unaware of making a choice as to DLNA or direct decryption. Which option does my method use?
Interesting thanks.
Just been doing these tests..
But the SkyQ box is outputting both via HDMI at the same resolution regardless of the source channel - they're both HD via the DVB-T modulator.