Auto-Decrpyt failure

jxp

Member
I have auto-decrypt enabled. This morning I happened to check one of last nights recordings.
The decrypted recording shows a message like "The channel is encrypted or unavailable" the whole way through.

I luckily have a [Deleted items] folder and in there I can play back the webif/auto_decrpyt file OK.

Are there any logs I can check to see what the problem is?
What should I do with the file so it doesn't get auto deleted?
 
Move it out of the recycle bin. Let this be a warning to anyone who considers undelete a waste of space.

Try the auto.log, accessible in the list on the WebIF Diagnostics page.
 
Umm, yeah. I have moved it out of the recycle bin, but auto-decrpyt will detect it, attempt decryption and delete it again.
I suppose I could disable auto-decrypt for the time being.
Is there any way to manually decrpyt the file? Could I copy the .ts off the Humax and then back on?

I will check the auto.log file this evening.
 
WebIF OPT+ "Decrypt"? Note that this won't work until the recording has been in place long enough for the indexer to find it. If the recording is SdDef you could copy it using the standard menus OPT+ (not "move") to a USB drive or a virtual drive, which should decrypt it without further ado. If it's HiDef the "Enc" icon needs to be not present (WebIF or standard menus).

Auto-decrypt uses the same mechanism as the WebIF OPT+ "Decrypt" option, it just invokes the decrypt automatically instead of manually. For it to be viable several ducks need to be in the row, and normally it will not attempt a decrypt unless they are all present and correct:
  1. For HiDef, autounprotect needs to have modified the database record for the recording (clearing the "Enc" flag is an indication, but not the same as the database mod);
  2. "Content Sharing" (the DLNA server) needs to be turned on;
  3. The DLNA indexer needs to have made the recording available (WebIF DLNA icon).
The WebIF decrypt process then sets up a streaming request to the native DLNA server, the server passes the recording through the hardware decrypter on the way out, and the WebIF process captures the streamed data into a file which (when complete) is used to replace the original encrypted file.

Unfortunately there is no way the stream capture can tell the incoming information is actually decrypted. It presumes the resulting file is decrypted and sets the flags accordingly, and the vast majority of the time it works. On this occasion it appears not to have done, and it is unlikely the log will tell you anything because if the process knew it had failed it would not have switched the files at the end.

We have had situations reported where it appears that the Humax "forgot" its encryption keys until they were restored at next reboot. If that was the case here, it would explain what you have reported. The test is that any recordings made between the keys being forgotten and being restored by a reboot will only play before the reboot, and any (encrypted) recordings made prior to the keys being forgotten will not play until after the keys are restored. The same would apply to streamed recordings and decrypt-copy operations.

*If* the above is the case here, a reboot should sort you out, and if you like belt-and-braces make it a full cold start.
 
Try the auto.log, accessible in the list on the WebIF Diagnostics page.

Yep, that's what we need to see to try and work out what went wrong. I'd also be interested in the checksums of the two versions of the files if you still have them to see if the DLNA server just served the encrypted content. That would be another sanity check that could be added.
 
So the log for the failed decryption doesn't seem to show anything interesting.
Code:
26/03/2013 08:00 - Media scan starting, DLNA server status: 1
26/03/2013 08:00 - dedup scan completed in 0.067 seconds.
26/03/2013 08:00 -  DECRYPT: /media/My Video/Broadchurch_20130325_2058
26/03/2013 08:00 -  DLNA: http://127.0.0.1:9000/web/media/374.TS
26/03/2013 08:07 - Done... 2.91 GiB in 466.634 seconds - 6.40 MiB/s
26/03/2013 08:07 - decrypt scan completed in 468.452 seconds.

The checksums of the two files were different;

Decrypted - not playable: checksum = 2873168089 3129384960
Original - encrypted: checksum = 3296089192 3129384960

(I guess the second number is the file size)

As per Black Hole's suggestion I completely turned off the Humax (back switch for 1 minute).
I then deleted the unwatchable files (via cli rm command), and moved the original recording out of [deleted]/webif_autodecrypt

After about 50 minutes the file was decrypted and is now watchable.
The decrypted and watchable file has a checksum of 2489896606 3129384960

It's a bit worrying that auto-decrypt failed. If I hadn't checked the recording, my recycle bin copy might have been gone before I noticed.
Is there any way to check the validity of the resulting stream and leave the encrypted original if there is a problem?
 
It's a bit worrying that auto-decrypt failed. If I hadn't checked the recording, my recycle bin copy might have been gone before I noticed.
Is there any way to check the validity of the resulting stream and leave the encrypted original if there is a problem?

Having got halfway through typing a message saying that there isn't, I think there is. The system downloads the 'decrypted' file from the DLNA server and compares the file size against the original, which is a start, but it could also do some rudimentary analysis of the resulting stream to check that it is a decrypted file.

Leave it with me.
 
I have updated stripts with an option to analyse a recording to determine if it is encrypted. It finds the first PAT packet in the file and parses it to check that it can find the PID for the PMT and that it matches the value stored in the corresponding HMT file. This should prove that the recording has been successfully decrypted and can be used by the automatic processing as a safety check.

So, could anyone willing with an HDR please update stripts to version 1.1.5 and run the encheck diagnostic? This will look at all of the recordings under My Video and for each compare whether it is marked as encrypted in the HMT file with whether the new stripts thinks it is encrypted. It will only print out recordings where there is a mismatch.

This will test whether stripts is getting it right but may also identify any recordings which have not decrypted properly in the past.

Code:
humax# diag encheck
Running: encheck
/media/My Video/The Big Bang Theory/S5/S5-19:_The_Weekend_Vortex.ts
   HMT marked encrypted:     1
   Stripts thinks encrypted: 0
 
I'm not sure this is what you wanted to see, it looks like it ran the old stripts (did it need a reboot?):

Oh bollox... Belay that, I just updated stripts on the wrong machine!
 
Ran diagnostic encheck on stripts version 1.1.5 and got this :-
Code:
>>> Beginning diagnostic encheck
Running: encheck
/media/My Video/archive/WW2 EDDIE CHAPMAN_20111119_2001.ts
  HMT marked encrypted:    0
  Stripts thinks encrypted:
 
>>> Ending diagnostic encheck
The highlighted file won't 'Play' e.g. Web-If >> Browse Media Files >> [Click on file] >> Play
eddie.jpg
 
@Ezra - can you run it again? It will produce more output for the file in question, thanks.
 
Re-Run of encheck
Code:
>>> Beginning diagnostic encheck
Running: encheck
/media/My Video/archive/WW2 EDDIE CHAPMAN_20111119_2001.ts
  HMT marked encrypted:    0
  Stripts thinks encrypted:
+ Input:  /media/My Video/archive/WW2 EDDIE CHAPMAN_20111119_2001
+ Output: NULL
+ Opening input HMT file.
 
>>> Ending diagnostic encheck
 
Looks like it has a full set of sidecar files
Code:
-rw-r--r--  1 root root      15296 Dec 17  2011 WW2 EDDIE  CHAPMAN_20111119_2001.hmt
-rw-r--r--  1 root root    5247200 Dec 17  2011 WW2 EDDIE  CHAPMAN_20111119_2001.nts
-rw-r--r--  1 root root      43680 Dec 17  2011 WW2 EDDIE  CHAPMAN_20111119_2001.thm
-rw-r--r--  1 root root 3423993856 Dec 17  2011 WW2 EDDIE  CHAPMAN_20111119_2001.ts
 
Could you run stripts -dE "WW2 EDDIE CHAPMAN_20111119_2001"
from that directory?

Looking encouraging so far though. No disparities on BH's system nor on mine.
 
I'm guessing the hmt is corrupted
Code:
humax# pwd
/media/My Video/archive

humax# stripts -dE "WW2 EDDIE CHAPMAN_20111119_2001"
+ Version: 1.1.5
+ Debugging level set to 1
+ Input:  WW2 EDDIE CHAPMAN_20111119_2001
+ Output: NULL
+ Opening input HMT file.
WW2 EDDIE CHAPMAN_20111119_2001.hmt: No such file or directory
Cannot open HMT file for 'WW2 EDDIE CHAPMAN_20111119_2001'.
humax#
 
More info
Code:
humax# hmt 'WW2 EDDIE  CHAPMAN_20111119_2001.hmt'
Format:SD
Title:EDDIE  CHAPMAN
Channel:2 (BBC TWO)
Folder:/mnt/hd2/My Video/archive/
Filename:WW2 EDDIE  CHAPMAN_20111119_2001
Genre:Entertainment (48)
EPG:4/6. The Miser's Hoard: Classic wartime sitcom. Mainwaring plots to get Frazer's hoard of gold sovereigns into his bank. [S]
 
Flags: SD,Unlimited Copies,
Copy count:0
 
Scheduled start:1321731000 (Sat Nov 19 19:30:00 2011)
Scheduled duration:1800
Recording start:1321732907 (Sat Nov 19 20:01:47 2011)
Recording end:1321739463 (Sat Nov 19 21:51:03 2011)
Duration:6556
Play resumes at: 1 seconds in.
 
Service ID (SID):4287
Transport Stream ID (TSID):4165
Originating Network ID (ONID):9018
Programme Map Table PID (PMTPID):200
Video PID:201
Audio PID:202
Bookmarks:0 =
 
EPG Blocks:5
  Block:1 Time:1 Offset:12480
    Block1_Title:i7Dad's Army
  Block:2 Time:1484 Offset:13184
    Block2_Title:i7Double Agent: The Eddie Chapman...
  Block:3 Time:5112 Offset:13888
    Block3_Title:i7QI XL
  Block:4 Time:7787 Offset:14592
    Block4_Title:i7Pan Am
  Block:5 Time:0 Offset:0
humax#
Last post until later Today
 
Back
Top