Programme scrambled after autodecrypt

MontysEvilTwin

Well-Known Member
Link to this thread in case they are related.
Interesting one this. I doubt it matters, but the HDR-FOX was already tuned to a standard definition channel when I came in a few minutes late, so I rewound to the start and hit record, then watched half of it on chase play. Came back later to watch the rest from the media list, after the recording had finished but got the 'signal is scrambled' message. Looked in auto.log: the file had been decrypted automatically, with nothing untoward logged. In Web-If though there was no 'Dec' symbol. I moved this programme to a folder with square brackets to prevent any more processing. Looked in 'deleted items' and the original was there and plays fine. I moved the original back to 'My Video' and rebooted. The file decrypted again, but this time successfully and is flagged as decrypted.
So now I have three versions, the original and decrypted files (as expected) plus a version which is not flagged as decrypted, and won't play on the machine it was recorded on. This file appears to have been scrambled during the autodecryption process
It gets weirder though. I accessed the Hummy's hard drive (Samba) from my Android tablet, and the 'scrambled' programme plays fine! So the programme is decrypted, but it is not flagged as such and it won't play on the HDR-FOX it was recorded on. As expected the 'regular' decrypted file plays but the encrypted one doesn't. I also tried playing on my tablet via a DLNA client (Skifta): it refuses to play. The 'proper' decrypted file and the original, encrypted file play fine by this method.
I presume that there was some sort of DLNA-related error during the decryption process, but it is odd that it will play on a tablet (Samba) but not on the machine itself. Is it corruption of a sidecar file that is the problem? I have not checked if the 'scrambled' TS file will play after sidecar deletion. I have kept the files in case they are any use.
 
OP
MontysEvilTwin

MontysEvilTwin

Well-Known Member
Not sure how to do that, but I can post them: Bad HMT
 

Attachments

  • Keiser%20Report_20140701_1729.hmt
    13.6 KB · Views: 6

Black Hole

May contain traces of nut
I have often found there is a decryption problem if I happen to view a programme shortly after recorded, so that the file is busy when the auto-decrypt kicks in. What you have reported in post 1 is interesting, I will check if I get the same.
 

Ezra Pound

Well-Known Member
Monty, here are your two files :-
Code:
humax# hmt BAD.hmt
Format:SD
Title:Keiser Report
ITitle:i7Headline News
Channel:85 (RT)
Folder:/media/HDR2/[Dec]/
Filename:
Genre:News & Factual (32)
EPG:Latest news update. For more information go to www.rt.com
Raw file is encrypted on disk.
 
Flags: SD,Unlimited Copies,ODEncrypted,
Copy count:0
 
Scheduled start:1404230400 (Tue Jul  1 17:00:00 2014)
Scheduled duration:1800
Recording start:1404232196 (Tue Jul  1 17:29:56 2014)
Recording end:1404233998 (Tue Jul  1 17:59:58 2014)
Duration:1802
Stored duration: 1799
Play resumes at: 0 seconds in.
 
Service ID (SID):27456
Event ID:18903
Transport Stream ID (TSID):24640
Originating Network ID (ONID):9018
Programme Map Table PID (PMTPID):1016
Video PID:2101
Audio PID:2102
Bookmarks:0 =
 
EPG Blocks:3
  Block:1 Time:0 Offset:0x30c0
    Block1_Title:i7Headline News
  Block:2 Time:695 Offset:0x3380
    Block2_Title:i7Keiser Report
  Block:3 Time:0 Offset:0
humax#

Code:
humax# hmt GOOD.hmt
Format:SD
Title:Keiser Report
ITitle:i7Headline News
Channel:85 (RT)
Folder:/media/HDR2/
Filename:
Genre:News & Factual (32)
EPG:Latest news update. For more information go to www.rt.com
 
Flags: SD,Unlimited Copies,
Copy count:0
 
Scheduled start:1404230400 (Tue Jul  1 17:00:00 2014)
Scheduled duration:1800
Recording start:1404232196 (Tue Jul  1 17:29:56 2014)
Recording end:1404233998 (Tue Jul  1 17:59:58 2014)
Duration:1802
Stored duration: 1799
Play resumes at: 3 seconds in.
 
Service ID (SID):27456
Event ID:18903
Transport Stream ID (TSID):24640
Originating Network ID (ONID):9018
Programme Map Table PID (PMTPID):1016
Video PID:2101
Audio PID:2102
Bookmarks:0 =
 
EPG Blocks:3
  Block:1 Time:0 Offset:0x30c0
    Block1_Title:i7Headline News
  Block:2 Time:695 Offset:0x3380
    Block2_Title:i7Keiser Report
  Block:3 Time:0 Offset:0
humax#
 

prpr

Well-Known Member
MET, If you turn off the encrypted flag on the bad .hmt (using the hmt util) I expect it will play. Could you confirm?
This sort of thing usually generates a warning message from the WebIf - the .ts file is in one state and the .hmt file the other.
 
OP
MontysEvilTwin

MontysEvilTwin

Well-Known Member
It looks like the bad hmt file has an extra 'ODEncrypted' flag. This flag does not show up in Web-If. So the file is decrypted but the hmt says it isn't. Presumably this mismatch causes the playback problem.
 
OP
MontysEvilTwin

MontysEvilTwin

Well-Known Member
MET, If you turn off the encrypted flag on the bad .hmt (using the hmt util) I expect it will play. Could you confirm?
This sort of thing usually generates a warning message from the WebIf - the .ts file is in one state and the .hmt file the other.
There was no error message; the auto.log file was normal. Earlier I got it to play on the Humax by swapping in the hmt from the proper decrypted version. I think Chris Daniels had a similar problem, but in his case the recording had both 'Enc' and 'Dec' flags showing in Web-If.
 
Top