No matching key for decryption

M

mightyoakbob

Member
Hi Guys,
Could do with some advice or maybe there's no solution to this.

Recording from a DVB-T modulator a 1080i or 1080p signal from a well known source of the "Q" variety is failing to auto decrypt with the error message : 'No matching key for decryption'.
The recording plays fine on the Humax but is labelled SD and not HD.
Transfering the ts file to a PC via samba confirms the file is still encrypted.
I've tried deleting and recreating sidecars - no effect till says SD not HD.

Tried a manual decrypt using the web interface. This runs smoothly to about 85% and then suddenly jumps to 100% but watching the files via samba I could see that the decryption file was still growing smoothly long after after the web interface said 100%.
When the decrypt file was the same size as the source original it stopped growing but the files did not swap in any way as I would have expected it left both as they were in the directory.
The decrypt file is indeed decrypted as proved when edited by video-redo after transfer to PC via samba.

When the edited file is returned to the Humax and new sidecars provided the recording is labelled HD.

What I would like to acheive is getting the auto decrypt to work if that is possible and understand why it thinks the file is SD and not HD.

I didn't have this issue before my wife wanted the "Q" version of source box.

Web interface version: 1.4.9-6
Custom firmware version: 3.13 (build 4028)
Humax Version: 1.03.12 (kernel HDR_CFW_3.13)
Loader Version: a7.34

Installed packages.
auto-unprotect 2.0.2
betaftpd 0.0.8pre17-5
boot-settings 1.0.4
disable-dso 0.3-1
disable-ota 1.0.3-4
dlna-filter 1.1.1
dlna-servername 1.0.3
dropbear-ssh 2020.79-3
fix-disk 0.5
newk 1.0.5-1
nicesplice-magic-folders 1.2
samba 3.6.25-1
sidecar 2.8
webif 1.4.9-6

Thanks for reading this and for any help you may give me.

Cheers,

Bob.
 
I may have mis-understood. You're having an issue trying to decrypt a HD recording from your HDR that uses the custom firmware.
The odd clues regarding the source - are you trying to say it's from one of the Quest or QVC channels or is it something else?
Does your decrypt method work for recent recordings from one the the main HD channels like ITV or BBC? The answer to this may give clues as to what the issue is. Eg if decrypt works for HD ITV/BBC then it's most likely the source channel (in which case which channel & programme is it). (I've previously recorded and decrypted short recordings from QuestHD and QVC HD without issue - plays back on VLC fine on laptop.)
 
Last edited:
bottletop said:
I may have mis-understood. You're having an issue trying to decrypt a HD recording from your HDR that uses the custom firmware.
The odd clues regarding the source - are you trying to say it's from one of the Quest or QVC channels or is it something else?
Does your decrypt method work for recent recordings from one the the main HD channels like ITV or BBC? The answer to this may give clues as to what the issue is. Eg if decrypt works for HD ITV/BBC then it's most likely the source channel (in which case which channel & programme is it). (I've previously recorded and decrypted short recordings from QuestHD and QVC HD without issue - plays back on VLC fine on laptop.)
Click to expand...
Thanks for the reply.
There is no problem decoding HD material which has been recorded from freeview.
Must admit I'm surprise that the "well known source of the "Q" variety" wasn't obvious and even more surprised that the later comment of "I didn't have this issue before my wife wanted the "Q" version of source box." didn't nail it.
Sorry about that.

SkyQ.

Thanks again.

Bob.
 
OK, as you placed this post in the Humax HDR Fox T2 area of the forum it is quite reasonable to presume that you was trying to decode a recording made on that product, I think it is also fair to assume that a recording made on a Sky Q box is not going to be decoded using the Humax Custom Firmware
 
Last edited:
Yes, I am most definately trying to decrypt a recording made on the HDR Fox T2 from UHF. I works manually but not automatically.

The Humax recording of SkyQ via the modulator is successful in that the recording appears in the list on the Humax like any other recording and it plays back from the hard drive on the Humax like any other recording with the Sky_Q switched off. Sound and picture are fine. So far so good.

The only obvious issue at this point is that the recording is marked as SD and not HD (by the Humax) and it is an HD recording. So whatever is deciding what sort of recording it has is being misled.

Look further and the custom firmware web interface shows the auto decryption has failed with the error 'No matching key for decryption'.

However. a manual decryption on the Humax via the web interface does decrypt the file which I'm them able to edit with video-redo.

So the combination of modulator and FoxT2 does record and decode SkyQ fully just not nicely. Looks to me like it gets a couple of flags wrong possibly because it's given confusing information by the SkyQ.

Before SkyQ we had Sky+HD and the Humax marked recordings as HD and auto decrypted them.

This cannot be a brick wall problem because I can get around it manually, it's an interpritation problem for want of a better word.

Thanks

Bob.
 
Wow, so 'Q' meant 'SkyQ'.
mightyoakbob said:
..The Humax recording of SkyQ via the modulator is successful in that the recording appears in the list on the Humax like any other recording and it plays back from the hard drive on the Humax like any other recording with the Sky_Q switched off. Sound and picture are fine. So far so good.
Click to expand...
Can you elaborate on your setup - specifically the modulator (device model etc) and how it connects to the HDR.
mightyoakbob said:
...So the combination of modulator and FoxT2 does record and decode SkyQ fully just not nicely. Looks to me like it gets a couple of flags wrong possibly because it's given confusing information by the SkyQ.
Click to expand...
There is a chance, if this worked perfectly before, is that your modulator doesn't cope well with HD channels from your SkyQ box (this is only a guess).
 
MartinLiddle said:
Please excuse my ignorance of SkyQ but is the UHF output that you are capturing coming direct from the Sky box?
Click to expand...
Not a problem.

Sky Q only has an HDMI output. No analogue and certainly no modulator.

I take the HDMI output from the Sky box and pass it thru a two way spitter. One output goes to the HDMI input on the TV and the other into a modulator like this one though I didn't pay that much for it. :) It is a double modulator and I used a much cheaper single unit for years.


The modulator produces a DVB-T mux suitable to add into a tv aerial distribution system and adds two channels to the TV choice. It has two HDMI inputs to feed them.

Once tuned on your TVs, the modulator shows SkyQ or whatever in 1080P and stereo sound on every set in the house all be it with about 0.8 seconds delay.

And of course the humax recorder gets a feed which it can record...

Hope that helps.

Cheers,

Bob.
 
bottletop said:
Wow, so 'Q' meant 'SkyQ'.

Can you elaborate on your setup - specifically the modulator (device model etc) and how it connects to the HDR.

There is a chance, if this worked perfectly before, is that your modulator doesn't cope well with HD channels from your SkyQ box (this is only a guess).
Click to expand...
Well yes, I'm not aware of any other "source box" with Q in the name. :)

I have answered someone elses question on modulator detail I hope that answers your question if not, come back to me.

I don't see this as a failing of the modulator. The output is fine on all tvs and the Humax can record it and play it back just fine.

My personal guess and it's little more than a guess is that the Sky Q is innocently sending out something additional in its HDMI output stream which is causing the Humax to get a little confused about what the signal is in terms of resolution etc...

Cheers,

Bob.
 
Is this a single recording that is failing or multiple recordings taken from the SkyQ box that are failing to decrypt?
There are occasional recordings from normal broadcast that fail to decrypt for unknown reasons.

Under the covers auto decryption uses the wget command - you could attempt to run that in a command window to see whether that shows any errors
You could also try software decryption using the stripts command or the Queue for decryption (direct, slower) option a t bottom of Browse webif page
A third thing to try would be to watch the programme via VLC from a PC.

I presume you a using manual or timer recordings since you wont have the broadcast info accurate recording
How do the recordings appear in the recordings list (Title and description)
Did you perchance change channel on SkyQ before stopping recording?

I wouldn't worry about the HD/SD designation - that is usually determined for a channel during tuning.
 
The error message comes from a last-resort attempt at direct (software, stripts) decryption.

There may be some useful information in the auto-processing log as to why that file wasn't suitable to be decrypted using the hardware-assisted (DLNA) mode.

In this case the key lookup returned nothing, which means that none of the keys that it tested against the .ts file worked. That would normally indicate a corrupt file if the file was definitely known to have been written by the same Humax box.
 
Hi,

Thanks for the interesting and to me challeging post.

I would love to quote and answer your points one by one as I used to but I cannot fathom how to do that with this updated website.

We changed to SkyQ back in late June and not played with transfers during the summer. The first recording I transfer did fail as detailed and so did the second. Not one has worked automatically yet. I've not done many transfers but I think a pattern is emerging.
Interesting that some do fail anyway though.

wget. I thought that was a webpage item fetcher? You say try that in a command window. I assume I SSH into the Humax, I assume the command needs parameters, could you give an example please. What might I expect to get back from the command? Or point me at documentation?

I've tried "Queue for decryption (direct, slower)" failed with the usual "No matching key for decryption."

What is the stripts command?

I'm certain the information for this is available but --- and don't see this as criticism, I've spent hours trying to find documentation on this website and failed miserably. Only when someone posts a link do I find it but it doesn't help with the next search.

To record, what I do is start the SkyQ box playing and then press the record button on the Humax, then press it again and adjust the record time length. Seems to work ok.

The recordings list pretty much the same as a recording from 101 on freeview except there is no programme name instead it just lists the channel name, so two lines might look like this...

301 SkyQ Main
17:30 30/09 9min. 301 SkyQ Main

I didn't change channel at all during the recording. it was playback from the SkyQ not live.

Thanks for your post, it has given me hope for finding the cause of this..

Cheers,

Bob.
 
/df said:
The error message comes from a last-resort attempt at direct (software, stripts) decryption.

There may be some useful information in the auto-processing log as to why that file wasn't suitable to be decrypted using the hardware-assisted (DLNA) mode.
Click to expand...

Right thanks. How do I get to that log? If I can find it I'll post some of it.

/df said:
In this case the key lookup returned nothing, which means that none of the keys that it tested against the .ts file worked. That would normally indicate a corrupt file if the file was definitely known to have been written by the same Humax box.
Click to expand...
Yes, I can see the logic of that statement. The recording was made by the same box.
What I don't understand more than anything is why a manual decrypt works and all else fails. Yes, there are issues with the gui saying 100% far too early and the files not swapping at the end the the .decryption file is decrypted?

Thanks for another informative post, learning all the time.

I've manged a quote I think. :)

Cheers,

Bob.
 
The Humax software indexes media of certain types and locations and makes them available via DLNA. Each file gets a URL, and encrypted media delivered by DLNA is decrypted by the hardware. By wgetting that URL we can invoke that h/w decryption which is otherwise inaccessible. Through extensive application of genius, @af123 created a software decoder, built into the stripts program, but it runs much more slowly.

The logs can be found in WebIf>Diagnostics.
 
Last edited:
mightyoakbob said:
Well yes, I'm not aware of any other "source box" with Q in the name. :)
Click to expand...
I see no reason you should expect readers to know you meant SkyQ. The context was not clear.

mightyoakbob said:
I'm certain the information for this is available but --- and don't see this as criticism, I've spent hours trying to find documentation on this website and failed miserably. Only when someone posts a link do I find it but it doesn't help with the next search.
Click to expand...
Hours trying to find documentation about what, exactly? There's plenty of documentation about how to use the custom firmware to do normal things, eg decrypt recordings from standard broadcast (just check out the links in the signature panel to this post), but we've never seen recordings from this modulator of yours so we have no idea of their characteristics nor have the tools been created with any specific ability to accommodate anything other than normal broadcast. You're not going to find any documentation for doing something we've never seen before.

We rely on information in the .hmt file to characterise the recordings. If the data stream from the modulator is a bit strange, there is no reason to expect the normal metadata to be correct: eg the StDef/HiDef flag. In the short term I suspect the tools are not going to work for you. In the longer term you might get some help if you can make some source material available to download somewhere, but as you are a unique case it will be a lot of effort for little return. In my view you need to lower your expectations.

mightyoakbob said:
wget. I thought that was a webpage item fetcher?
Click to expand...
Certainly. And that's what's used under the bonnet to perform the equivalent of a DLNA fetch to perform decryption - because the HDR-FOX hardware decrypts the recording when it streams it to a DLNA client. Learn to walk before you try to run. Using stripts to perform decryption is approaching the matter from a different direction: direct decryption by software instead of tricking the hardware. stripts is a tool for analysing the TS recording file, independent of what the .hmt says.
 
Last edited:
mightyoakbob said:
Recording from a DVB-T modulator a 1080i or 1080p signal from a well known source of the "Q" variety is failing to auto decrypt with the error message : 'No matching key for decryption'.
The recording plays fine on the Humax but is labelled SD and not HD.
Click to expand...
This is all the info needed.
The modulator is DVB-T - it encodes to MPEG2.
The Humax receives and records it, resolution transparent, doesn't care that the TS is HD or SD.
BUT because it's an MPEG2 stream it's labelled as SD - the HDR expects that only MPEG4 streams are HD.
(Some channels used MPEG4 for SD video - Film4+1 when it was squashed onto a "HD" mux - so are labelled HD even though they are SD).

BTW Qudos for finding a way to archive restricted HD content!
 
Last edited:
Very good, but I still can't work out what's going on.

If the HDR-FOX is marking it as StDef, then it ought to get treated like an StDef recording regardless. The codecs might get confused if they were set up to expect StDef resolution, but it plays OK so that doesn't seem to be an issue. From an encryption point of view, it's just anonymous data isn't it?

Being marked as StDef should mean the recording isn't protected, and doesn't require unprotecting. If for some reason the protection flag is set, maybe auto-unprotect isn't being invoked.

It shouldn't be difficult to decrypt the plain TS manually, whether on-box by stripts or on a PC using HFODU, but why isn't auto-decryption working, and why isn't WebIF manual decryption cleaning up? I can understand the progress indicator might be confused, because the MPEG2 HiDef file will be much bigger than it was expecting. Is the problem that everything else is getting confused by these "peculiar" recordings too?

How is the title of this thread relevant:
mightyoakbob said:

No matching key for decryption​

Click to expand...
?

What led you to that conclusion? The title coloured my thinking right from the off (and seems to have confused other people as well). If the HDR-FOX encrypted the recording in the first place (which it did, as it does with every recording) then of course it has the matching key for decryption (unless you've done something to change the key in the mean time, or if has forgotten its key until the next reboot).

You can provide more info to help. The list of installed packages, while trying to be helpful, isn't. What would be more useful is the WebIF logs. Go to WebIF >> Settings >> Auto-Processing Settings and bump the Auto-processing log level up to "Debugging information". I'm not sure whether a reboot is required to action it, so you might as well. Then you can make another SkyQ transcription recording and see what the auto-decrypt makes of it in WebIF >> Diagnostics >> View Log Files >> auto.log (and maybe other log files will be revealing also).

Ultimately, as I said before, an upload of an example (unmolested) recording file set will be the gold standard for analysis.
 
/df said:
The Humax software indexes media of certain types and locations and makes them available via DLNA. Each file gets a URL, and encrypted media delivered by DLNA is decrypted by the hardware. By wgetting that URL we can invoke that h/w decryption which is otherwise inaccessible. Through extensive application of genius, @af123 created a software decoder, built into the stripts program, but it runs much more slowly.

The logs can be found in WebIf>Diagnostics.
Click to expand...
Thank you for the information.

I've looked at the logs and found that the two logs auto.xxx had no entries since march. the auto log without a "." shows objects being queued for decryption but no other inormation.

Worth a try though thanks.

Cheers,

Bob.
 
Black Hole said:
I see no reason you should expect readers to know you meant SkyQ. The context was not clear.
Click to expand...
" A well known source of the Q variety"
"didn't have this issue before my wife wanted the "Q" version of source box."
Really?

Black Hole said:
Hours trying to find documentation about what, exactly? There's plenty of documentation about how to use the custom firmware to do normal things, eg decrypt recordings from standard broadcast (just check out the links in the signature panel to this post), but we've never seen recordings from this modulator of yours so we have no idea of their characteristics nor have the tools been created with any specific ability to accommodate anything other than normal broadcast. You're not going to find any documentation for doing something we've never seen before.
Click to expand...

Of course I did not expect to see information on problems recording from SkyQ. I thought I might be able to find more information on why HD recordings were marked as SD and possibly finding more understanding of decryption, specdifically differences between a manual decrypt which works in the most part and the auto decrypt that doesn't, in this case. Or even if there was anything written about manual decrypt terminating oddly.

Black Hole said:
We rely on information in the .hmt file to characterise the recordings. If the data stream from the modulator is a bit strange, there is no reason to expect the normal metadata to be correct: eg the StDef/HiDef flag.
Click to expand...
So might it be possible for me to correct the metadata / flags manually prior to adding the item to the decrypy queue?

Black Hole said:
In the short term I suspect the tools are not going to work for you. In the longer term you might get some help if you can make some source material available to download somewhere, but as you are a unique case it will be a lot of effort for little return.
Click to expand...
I would be more than happy to make material available but could do with info on how to do this especially baring in mind the size of the files. I can make a 10 minute long file that fails as described but even so, it's still very large. So please tell me how to do this.
Black Hole said:
In my view you need to lower your expectations.
Click to expand...
In complete honesty, the one and only expetation I had when I made the initial post was a barrage of critism from you as it is clear to me that you enjoy doing so. That's why I went chapter and verse on information about what versions I'm using and detailed the problem very precisely. I knew you would still find fault after fault with me but I accepted that in the hope that you or someone else might just say something that finds a better work around and that i might learn something.

Black Hole said:
Certainly. And that's what's used under the bonnet to perform the equivalent of a DLNA fetch to perform decryption - because the HDR-FOX hardware decrypts the recording when it streams it to a DLNA client.
Click to expand...
Interesting, thank you for that.

Black Hole said:
Learn to walk before you try to run.
Click to expand...
Apart being another snipe, what exactly do you mean by that?
Should I not ask a question here until I've studied every aspect of the project for months possibly years?

Black Hole said:
Using stripts to perform decryption is approaching the matter from a different direction: direct decryption by software instead of tricking the hardware. stripts is a tool for analysing the TS recording file, independent of what the .hmt says.
Click to expand...
Thank you.
 
nvingo said:
This is all the info needed.
The modulator is DVB-T - it encodes to MPEG2.
The Humax receives and records it, resolution transparent, doesn't care that the TS is HD or SD.
BUT because it's an MPEG2 stream it's labelled as SD - the HDR expects that only MPEG4 streams are HD.
Click to expand...
That makes a lot of sense. I can see that.
I'm probably wrong but I was under the impression that SD recordings on the Humax were not encrypted by the Humax but this recording is encrypted.

Thanks
Bob.
 
You must log in or register to reply here.
Back
Top