Decrypt Failed - File In Use

Pardon me for butting in, but for the very first time last night I had a warning message stating that a recording had failed to decrypt. The file played OK, but was obviously still encrypted.

Has something changed recently or shall I put it down to 'one of those things'?

FWIW, nothing that I know of has changed on my box, auto update not withstanding.
 
I don't think its one of those things. Several other reports recently, and I too have had a few that have never happened before. Neither Hell's Kitchen from the last two nights would decrypt automatically. Managed to do them manually via webif, but then the auto decrypt started to try to work on the originals in the _original folder and started failing on those too before I deleted the folder manually.
 
I am also a member of Toppy.org as I am the owner of Topfield 5810 PVR. I have been reading problems with recordings being cut short. Of course it is primarily reported by Topfield users but there was one mention of it occurring on a Humax. Indeed, yesterday I did have several recordings fail or not even start! The ones that failed part way through have a banner that says something to the effect that 'recording failed due to power failure'. Not the exact words but you get the idea. The short recording play perfectly up to the point they were cut short. There were no power issues either.

This is the link to the thread over at Toppy.org: http://forum.toppy.org.uk/forum/viewtopic.php?t=20194

I realise I could be going off at a Tangent, but is it something that could/might be relevant?
 
Bugger. Just had notification that The Briefs and The Hotel Inspector have both failed to decrypt. Yet Britain's Favourite Supermarket Foods recorded earlier has
decrypted OK. Something is definitely going on here. No problems then this...
 
Something has changed somewhere.., with the broadcast streams I think. Do you have the latest stripts package installed?

If the latest stripts doesn't fix it then I could do with a decrypted copy of one of these files that failed to decrypt automatically - ideally a fairly small one - if someone's willing to upload one somewhere.


Posted on the move; please excuse any brevity.
 
Oh, any particular channels or muxes where this is happening?


Posted on the move; please excuse any brevity.
 
For me, BBC One, ITV, Channel 4 that I can confirm.

FWIW I had scripts v1.2.1 at the time these recordings where 'being decrypted'. Having read this thread back, I noticed that version 1.2.2 is now available. I have just updated to that version.

I have two programmes recording as I write this. Provided the box doesn't require a reboot for the new version to stick, then it could be a further test for you.
 
af123 said:
@prpr - could you try stripts 1.2.2 on that decrypted file and see if it's any better? Thanks.
Click to expand...
Both encrypted and decrypted files print "1" using this latest version (I still don't understand how to use the debug level param).
The decrypted version generates reams of output in debug mode (do you want that?) but the last few lines read:
Code: 
Doesn't look encrypted - checking PAT structure.
  PROG: 0 - 16
  PROG: 8264 - 1700
  PROG: 8325 - 1800
  PROG: 8362 - 1900
  PROG: 8384 - 1100
  PROG: 8442 - 1400
  PROG: 8448 - 1300
  PROG: 8452 - 1200
  PROG: 8500 - 1600
  PROG: 1616 - 2728
No matching PAT found.
1

PAT is found in all the previous sections of debug though, just not in the last one. Don't know if that is significant.

I am now at the location of the previously remote box and can tell you the 'decrypted' file really is decrypted and plays fine in VLC.
I could also dump the file on Dropbox if you want. Away tomorrow and most of Sat. though...
 
af123 said:
Oh, any particular channels or muxes where this is happening?
Click to expand...
Channel 5 Waltham is causing most of the problems. Same programme recorded on my box from Mendip decrypts OK.
I think I've seen decode failures/multiple attempts as posted up-thread from the BBC SD mux. though, but I haven't really been keeping accurate records.
 
I routinely play content by network share, so I would certainly notice if my usual recordings were regularly failing to decrypt. The HDRs in question are on auto-update of course.

This problem seems to be different from the one I reported in the first place.
 
Black Hole said:
This problem seems to be different from the one I reported in the first place.
Click to expand...
Er, yes.. it does seem to have moved on to a different decryption issue which has recently started and seems to be affecting a range of people.

The decryption itself is working but the automatic decryption process needs to be convinced that the decryption has succeeded before it swaps in the new file for the old. It does this by scanning the decrypted recording for a Programme Allocation Table (PAT) then checking that the service for the decrypted programme is listed in there and maps to the right Programme Map Table as recorded in the HMT file. This check has always worked before so I can only assume there has been some change at the broadcaster's end.

From the details prpr has posted for a problematic recording:

Code: 
Service ID (SID):8500
Event ID:46472
Transport Stream ID (TSID):8200
Originating Network ID (ONID):9018
Programme Map Table PID (PMTPID):289
Video PID:1601
Audio PID:1602

Service ID 8500 identifies which service on the MUX was recorded so stripts looks through the first PAT it finds for that entry and sees in this case:

Code: 
PROG: 8500 - 1600

which shows that, according to the PAT, the PID for the PMT is 1600 rather than the 289 recorded in the HMT file. Hence the fact that stripts remains unconvinced that the decryption has succeeded.

The next thing I'd look at is whether either of 1600 or 289 represents a PMT in the decrypted stream. Here's an example for a programme I've just decrypted:

Code: 
humax# hmt Magnum\ P_I__20130724_1601. | grep PMT
Programme Map Table PID (PMTPID):1037

humax# dvbsnoop -s ts -N 1 -if 'Magnum P_I__20130724_1601.ts' 1037 | grep -v '^!'
dvbsnoop V1.4.50 -- http://dvbsnoop.sourceforge.net/

------------------------------------------------------------
TS-Packet: 00000001   PID: 1037 (0x040d), Length: 188 (0x00bc)
from file: Magnum P_I__20130724_1601.ts
------------------------------------------------------------
  0000:  47 44 0d 11 00 02 b0 7b  6d 80 c3 00 00 e2 59 f0   GD.....{m.....Y.
  0010:  00 02 e2 59 f0 03 52 01  01 04 e2 5a f0 09 52 01   ...Y..R....Z..R.
  0020:  02 0a 04 65 6e 67 00 04  e2 5c f0 09 52 01 03 0a   ...eng...\..R...
  0030:  04 65 6e 67 03 06 e2 5b  f0 0d 52 01 04 59 08 65   .eng...[..R..Y.e
  0040:  6e 67 10 00 02 00 02 0b  ff 40 f0 33 52 01 f0 13   ng.......@.3R...
  0050:  05 00 23 3a f0 00 5f 04  00 00 23 3a 26 21 01 01   ..#:.._...#:&!..
  0060:  3f ff 1f 01 2f 0d 0c 64  6d 6f 6c 2e 63 6f 2e 75   ?.../..dmol.co.u
  0070:  6b 2f 31 0a 64 6d 6f 6c  2e 63 6f 2e 75 6b 03 37   k/1.dmol.co.uk.7
  0080:  5f da f1 ff ff ff ff ff  ff ff ff ff ff ff ff ff   _...............
  0090:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
  00a0:  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff   ................
  00b0:  ff ff ff ff ff ff ff ff  ff ff ff ff               ............

Sync-Byte 0x47: 71 (0x47)
Transport_error_indicator: 0 (0x00)  [= packet ok]
Payload_unit_start_indicator: 1 (0x01)  [= Packet data starts]
transport_priority: 0 (0x00)
PID: 1037 (0x040d)  [= ]
transport_scrambling_control: 0 (0x00)  [= No scrambling of TS packet payload]
adaptation_field_control: 1 (0x01)  [= no adaptation_field, payload only]
continuity_counter: 1 (0x01)  [= (sequence ok)]
    Payload: (len: 184)
        ==> pointer_field: 0 (0x00)
        ==> Section table: 2 (0x02)  [= Program Map Table (PMT)]

This one is fine. PID 1037 is the PMT which is what the HMT says and also the value recorded in the PAT:

Code: 
humax# stripts -dE Magnum\ P_I__20130724_1601
+ Version: 1.2.2
+ Debugging level set to 1
+ Input:  Magnum P_I__20130724_1601
+ Output: NULL
+ Opening input HMT file.
SD recording.
Encrypted: 0
Shrunk: 0
Video PID: 601, Audio PID: 602, PMTPID: 1037, SID: 28032
Event ID: 22365
+ Opening Magnum P_I__20130724_1601.ts
+ Total size: 1231941632
Found PAT at offset 0xcf00
00000000: 14 d3 86 fb 47 40 00 11 00 00 b0 8d 60 40 cd 00  ....G@......`@..
00000010: 00 00 00 e0 10 64 40 e3 e9 64 80 e3 ea 65 40 e3  .....d@..d...e@.
00000020: ed 6a 40 e3 f6 6a c0 e3 f4 6a e0 e3 f5 6b 80 e3  .j@..j...j...k..
00000030: f9 6c c0 e4 0b 6d 00 e4 0c 6d 80 e4 0d 6a 00 e3  .l...m...m...j..
00000040: f0 6b 40 e3 f8 68 00 e4 04 67 c0 e4 03 66 c0 e3  .k@..h...g...f..
00000050: ff 66 80 e3 fe 66 40 e3 fd 67 00 e4 00 64 c0 e3  .f...f@..g...d..
00000060: eb 6b c0 e3 fa 69 a0 e4 06 6e 00 e4 10 6e 80 e4  .k...i...n...n..
00000070: 12 6e a0 e4 13 6e c0 e4 14 6e e0 e4 15 6f 00 e4  .n...n...n...o..
00000080: 16 6a 20 e3 f1 6c 40 e4 09 68 80 e4 01 6a 60 e3  .j ..l@..h...j`.
00000090: f2 6a a0 e3 f3 7e 52 9f a2 ff ff ff ff ff ff ff  .j...~R.........
000000a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
000000b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff  ................
Doesn't look encrypted - checking PAT structure.
  PROG: 0 - 16
  PROG: 25664 - 1001
  PROG: 25728 - 1002
  PROG: 25920 - 1005
  PROG: 27200 - 1014
  PROG: 27328 - 1012
  PROG: 27360 - 1013
  PROG: 27520 - 1017
  PROG: 27840 - 1035
  PROG: 27904 - 1036
  PROG: 28032 - 1037
    Matched HMT
  PROG: 27136 - 1008
  PROG: 27456 - 1016
  PROG: 26624 - 1028
  PROG: 26560 - 1027
  PROG: 26304 - 1023
  PROG: 26240 - 1022
  PROG: 26176 - 1021
  PROG: 26368 - 1024
  PROG: 25792 - 1003
  PROG: 27584 - 1018
  PROG: 27040 - 1030
  PROG: 28160 - 1040
  PROG: 28288 - 1042
  PROG: 28320 - 1043
  PROG: 28352 - 1044
  PROG: 28384 - 1045
  PROG: 28416 - 1046
  PROG: 27168 - 1009
  PROG: 27712 - 1033
  PROG: 26752 - 1025
  PROG: 27232 - 1010
  PROG: 27296 - 1011
  PROG: 32338 - 8098
0
Processed in: 0.00s

I'd like to get to the bottom of this but there are different heuristics that stripts could use if necessary.
 
Hi Guys.....started to get the following errors on all new recordings.
Has anyone seen this and do we know what the cause/fix is. Thanks, Brian
29/07/2013 12:10 - /media/My Video/Channel 4 News Summary/Channel 4 News Summary_20130729_1159.ts - auto-decrypt failed.
29/07/2013 12:20 - /media/My Video/Channel 4 News Summary/Channel 4 News Summary_20130729_1159.ts - auto-decrypt failed.
29/07/2013 12:30 - /media/My Video/Channel 4 News Summary/Channel 4 News Summary_20130729_1159.ts - auto-decrypt failed.
29/07/2013 12:41 - /media/My Video/Channel 4 News Summary/Channel 4 News Summary_20130729_1159.ts - auto-decrypt failed.
29/07/2013 12:50 - /media/My Video/Channel 4 News Summary/Channel 4 News Summary_20130729_1159.ts - auto-decrypt
 
If you upgrade your web interface (or just stripts package) then that should sort it for you.
 
The PMT/Video/Audio PIDs on C5 on my (Mendip) box are 1600/1601/1602 respectively. On the remote (Waltham) box they are 289/2850/2851.
The only services that match PIDs (according to the channel database on the T2) on that mux. between the two boxes are ITV and Channel 4. All the rest are different. I'm not sure whether this helps any or just serves to confuse more.
 
I've been getting this a lot too.

NCIS on pick TV seems to always have this problem so far.

Manual decrypt works fine.
 
Thanks!

I think there's another NCIS on this afternoon. Going to record that, see if the problem occurs and then upgrade stripts.

Will let you know.
 
As af123 says the problem is fixed in v1.2.3 (should be), why not upgrade to that BEFORE you record NCIS?

I am not sure if I understand your logic. Unless, of course, you are unable to at the moment!
 
Everyone on the ball as usual. Will kick off upgrade of that package now -- Home and Away recorded from Five has been unable to auto-decrypt for the last week or so, possibly aligned with the changes to the Mux setup of the D3&4 mux?
 
In fact the encrypted files have already auto-decrypted themselves and the "upgrade all" I triggered earlier to pickup the new web-if package must have been at just the right time to pickup the new stripts.

So confirmed working for me anyway, thanks!
 
You must log in or register to reply here.
Back
Top