No matching key for decryption

Conceivably assumptions are being made in either the ts class, which uses the hmt program to instantiate a ts object from the filename, or in the stripts program, or both. For instance, stripts might not understand the specific format of .ts file being written.

It could be useful to show the output of hmt -p tsname for a tsname.ts that doesn't get decrypted.
Thanks for the suggestion.

I've tried to do this but failed. I have used putty and SSH into the machine ok. but then I'm faced with different directories to what I see with betaftpd or a restricted subset. Can't find a way to navigate to the media folder. So I wondered if there was something in the web interface that allows commands and gave diagnostics a good look but nothing stood out to do that.

If you would be kind enough to advice how I issue the command I will do it.

I've also now got a 40 second file that will not decrypt automatically. Just need to find somewhere to upload it to.


Thanks.

Bob.
 
In case somebody hasn't said this already: WebIF Auto-Decrypt relies on the DLNA server to decrypt and output the TS. If the DLNA server won't serve the file, then auto-decrypt won't work and your stuck with manual decryption by stripts (which IIRC can be invoked using sweeper). One way to prove whether the server is unhappy with those recordings is to use a DLNA client and see what happens trying to play it.

The DLNA server could be unhappy for several reasons, not exclusively the metadata.
I'm guessing you mean another box with a DLNA client?
I have several UPnP clients and servers on the network and an OPPO blueray player that lists network items as SMB UPnP NFS, it lists more than the PC but it only show SMB for the Humax. Having said that, I've not seen it show DLNA at all yet.

Is there a setting to make the DLNA server useable from the network? Just thinking perhaps something needs turning on.

Thanks.

Bob.
 
Can't find a way to navigate to the media folder.
Code:
cd "/media/My Video"
Is there a setting to make the DLNA server useable from the network? Just thinking perhaps something needs turning on.
Settings > System > Internet Setting > Content Share On
Would someone check out if they can download it please and then I'll give the box credentials to investigate it.
It can be downloaded but the encryption key would be required for it to be of any use.
 
Code:
cd "/media/My Video"
Oh wow. I had tried: cd /media/My Video
Wasn't surprised when it didn't work as there was no media folder from where SHH starts from.
All in the double quotes, the learning keeps coming.
Settings > System > Internet Setting > Content Share On
LOL. yes that's on, thought there might be something else.
It can be downloaded but the encryption key would be required for it to be of any use.
Excellent.
Serial Number: 63 7106030 00261
Encryption Key: 08eb7422b4aa36333731303630333030
Is that enough?

Thanks.

Bob.
 
Result of command : hmt -p "SkyQ Main 40secs_20211003_1034.ts
SkyQ Main 40secs SD 301 SkyQ Main 1633253677 1 633253714 SD,Unlimited Copies,ODEncrypted, 0 0 0 0 0 Valid/OK 0 0 0
 
In case somebody hasn't said this already: WebIF Auto-Decrypt relies on the DLNA server to decrypt and output the TS. If the DLNA server won't serve the file, then auto-decrypt won't work and your stuck with manual decryption by stripts (which IIRC can be invoked using sweeper). One way to prove whether the server is unhappy with those recordings is to use a DLNA client and see what happens trying to play it.

The DLNA server could be unhappy for several reasons, not exclusively the metadata.
Yes but in this case is ts getkey / stripts that is failing to detect the encryption key - it is isn't get as far as attempting to use the dlna server,
 
Code:
pvr# stripts -/ 08eb7422b4aa36333731303630333030 SkyQ\ Main\ 40secs_20211003_1034
Encryption key is INCORRECT for this recording.
Processed in: 0.50s
pvr# stripts -@ 08eb7422b4aa36333731303630333030 SkyQ\ Main\ 40secs_20211003_1034 xxx
Processed in: 145.42s
pvr#
As suspected stripts is reporting an incorrect encryption key but will successfully decrypt it.
 
As suspected stripts is reporting an incorrect encryption key but will successfully decrypt it.
I have reported this on the forum several times, here is the Wiki entry :-
Code:
-/ <key>    Check encryption key against recording. (* See NOTE Below)
    -d [level]  Increase debug level or set debug level.

* NOTE :- This option has been reported to return "Incorrect" when using the correct key

EDIT

 
Last edited:
Code:
pvr# stripts -/ 08eb7422b4aa36333731303630333030 SkyQ\ Main\ 40secs_20211003_1034
Encryption key is INCORRECT for this recording.
Processed in: 0.50s
pvr# stripts -@ 08eb7422b4aa36333731303630333030 SkyQ\ Main\ 40secs_20211003_1034 xxx
Processed in: 145.42s
pvr#
As suspected stripts is reporting an incorrect encryption key but will successfully decrypt it.
Would I be right in thinking that stripts must have used a correct key otherwise it could not possibly decrypt the file?
If so, then whatever test is done on the key prior to use is making an error.

If anyone wants the .hmt file for this it's here..

Thanks.

Bob.
 
I have reported this on the forum several times, here is the Wiki entry :-
Code:
-/ <key>    Check encryption key against recording. (* See NOTE Below)
    -d [level]  Increase debug level or set debug level.

* NOTE :- This option has been reported to return "Incorrect" when using the correct key
It worked when I tried it on a different recording prior to posting above.
 
I'm sure I have seen it working in the past, but it now consistently displays 'Incorrect' when using the correct key on the 3 HDR Fox T2s that I have
 
I just did a quick test recording using Bob's key:
Code:
pvr# nugget cryptokey -key
08eb7422b4aa36333731303630333030
pvr# stripts -/ 08eb7422b4aa36333731303630333030 ../Films/The\ Fifth\ Element_20211003_1448
Encryption key is correct for this recording.
Processed in: 0.01s
 
After setting my system decryption key I was able to view the downloaded recording in VLC via DLNA and also decrypt the file (using chaseget), but auto-decrypt fails

I don't have time at the moment to dig into why stripts key testing is failing for some recordings
 
After setting my system decryption key I was able to view the downloaded recording in VLC via DLNA and also decrypt the file (using chaseget), but auto-decrypt fails

I don't have time at the moment to dig into why stripts key testing is failing for some recordings
Thank you for that.

Bob.
 
It worked when I tried it on a different recording prior to posting above.
@xyz321, Sorry for the confusion, the problem is with the Windows stripts.exe version, I have sent the exact same line e.g. :- stripts -/ 000378bd11f336333731303434393630 "input file name" (copied from the screen), to both the Windows Version and the version on the Humax itself and I am getting:- "key is INCORRECT" and "key is correct", I will change the Wiki notes
 
Last edited:
I think stripts reports an incorrect key if the result of decryption doesn't look "normal". Do you want the parameters of what constitutes normal to be widened?
 
I don't believe that the source of stripts has been shared, or am I looking in the wrong place?
 
Back
Top