1. Were the other items films?
2. Very strange.
3. I recorded "Shadow of a Doubt" in the way you describe. But my previous posting refers to an instant recording. The ENC flag appeared when the item arrived in the media list. Then I cancelled the recoding, tried again & again until the next programme started.
4. Always the case for people who can't use CF!
5-7. Next time this happens I'll save the .hmt files and have a poke around and see.
Perhaps MontysEvilTwin can confirm whether the hmt file on his recording exhibits the same contents of this field (i.e. X'00' rather than X'04'.)
I can confirm Iron Man is recording with ENC flag setJust recording Iron Man 3 on BBC1 in SD and it has the 'Enc' icon. I've pasted a 'snapshot' of the hmt file below.
Humax# hmt "Iron Man 3_20160102_1959.ts"
Format:SD
Title:Iron Man 3
ITitle:Iron Man 3
Channel:1 (BBC ONE South)
Episode:0,0/0
Folder:/mnt/hd2/My Video/
Filename:Iron Man 3_20160102_1959
Genre:Film (16)
EPG:Robert Downey Jr rockets back into action as the steel-clad superhero when society comes under threat from a terrorist known as the Mandarin. Also in HD. [2013] [AD,S]
Raw file is encrypted on disk.
Recording Status: Loss of power (OK)
Flags: SD,New,Encrypted,ODEncrypted,
Copy count:0
Scheduled start:1451761800 (Sat Jan 2 19:10:00 2016)
Scheduled duration:7200
Recording start:1451764778 (Sat Jan 2 19:59:38 2016)
Recording end:1451768997 (Sat Jan 2 21:09:57 2016)
Duration:4219
Stored duration:269
Play resumes at:0 seconds in.
Timezone offset:0
Service ID (SID):4163
Event ID:40096
Transport Stream ID (TSID):4163
Originating Network ID (ONID):9018
Programme Map Table PID (PMTPID):100
Video PID:101
Audio PID:102
Bookmarks:0 =
I think the Wiki incorrectly shows the bits transposed for offset 0x3dc.The value at 0x03DC is '00'. I thought that this location is that of the 'Enc' flag. '01' at this location does not clear the 'Enc' flag, but changing it to '04' does. Does this match what is in the hmt format document in the wiki? I don't think I fully understand the hex address notation, so I am not sure.
7e 01 f1
do_not_scramble: This is a 1-bit field that indicates whether or not to apply scrambling of the content item for the purposes of content protection.
If do_not_scramble is set to "1" then scrambling shall not be applied for the purposes of content protection. If do_not_scramble is set to "0" then scrambling shall be applied where applicable for content protection.
It certainly looks that way, in as much as the EPG data is part of the broadcast stream.I had assumed the ENC flag is automatically set by the Humax on HiDef recordings, but I suppose it might be a broadcast property. If so, could it be that these instances are all examples of this property being attached to the broadcast?
But it is important to stress that the technology places no restrictions whatsoever on copying standard definition content
At the end of the recording, auto-unprotect removed the 'Enc' flag from the standard def. recording and it was decrypted automatically without any problems.I need to read back through this thread (been away!) but are people saying that these programmes aren't properly auto-decrypted etc?
I tried 'epg -D0x7e dumpraw' but it produces no output. It might be useful to be able to look at this descriptor.Unlike most events on BBC ONE, Iron Man 3 has descriptor 0x7e as part of its EPG data.
I agree and will update the epg tool later. It does already have the code in for this descriptor but it's commented out - don't remember why, I probably thought it wasn't used.I tried 'epg -D0x7e dumpraw' but it produces no output. It might be useful to be able to look at this descriptor.
I will try and reproduce this with tonight's The Road. I can't see any reason that auto-unprotect would not remove the flag automatically - do you have that package?I, at least, am saying that auto-decrypt is not properly functioning on the affected recordings.
Absolutely, it's Humax's terminology not ours. They call the 'protect/prevent decryption on copy/do_not_scramble=0' flag at 0x3dc 'Enc' and that is what they display in their on-TV interface. The web interface mirrors that but adds a second icon which shows whether the recording is actually encrypted on disk (based on 0x28e).There's clearly scope for some confusion between the hmt Enc flag and the displayed Enc icon, and between the terms 'encryption' and 'scrambled'.
af123's surmise that it's the setting in the EPG that's triggering the problem seems eminently plausible. But I don't think one needs to describe any Machiavellian motives to, or breach of faith by, the BBC to explain the situation. The BBC says 'do what you like' with SD recordings; it's the Humax that decides to apply HD restrictions to them, just cos the EPG says so. It doesn't need to.
I tried 'epg -D0x7e dumpraw' but it produces no output. It might be useful to be able to look at this descriptor.
humax# sqlite3 /mnt/hd1/epg.db
sqlite> select event_id,name from epg where service_id = 4170 and content_mgmt = 1;
40119|The Road
40363|You Again
42043|The Peacemaker
42044|Halloween: Resurrection
humax# epg -S4170 -E40119 -D126 dumpraw | grep 126
descriptor: 0x7e [126] (content mgmt)
content.d126.reserved: 15
content.d126.no_scramble: 0
content.d126.control_remote_access: 0
content.d126.no_revocation: 1
humax# epg -S4170 -p dump | egrep '1.$'
4170 40119 1451864100 6000 0 The Road In a post-apocalyptic world, a father and his son fight for survival. Contains very strong language and some violence. Also in HD. [2009] [AD,S] Contains very strong language and some violent scenes. 1 Film/Drama /4J62SH 1 1
4170 40363 1452297300 6000 0 You Again Romantic comedy. A successful public relations executive is forced to confront the past when her brother plans to marry a girl who bullied her at high school. Also in HD. [2010] [S] 1 Film/Drama /4J62I4 1
4170 42043 1452384000 6900 0 The Peacemaker A pair of mismatched government operatives set out to recover stolen nuclear warheads. Contains very strong language and some violence. Also in HD. [1997] [S] Contains very strong language and some violent scenes. 1 Film/Drama /4J3W35 1 1
4170 42044 1452390900 5100 0 Halloween: Resurrection Horror sequel. The original house from the first film is the set of a webcam reality show. Contains very strong language and prolonged violence. Also in HD. [2002] [AD,S] Contains very strong language and prolonged violent scenes. 1 Film/Drama /4J3YZY 1 1
I will try and reproduce this with tonight's The Road. I can't see any reason that auto-unprotect would not remove the flag automatically - do you have that package?
Absolutely, it's Humax's terminology not ours. They call the 'protect/prevent decryption on copy/do_not_scramble=0' flag at 0x3dc 'Enc' and that is what they display in their on-TV interface. The web interface mirrors that but adds a second icon which shows whether the recording is actually encrypted on disk (based on 0x28e).
We don't know what Humax had to sign in order to license the Huffman tables for decoding the EPG data on the HD channels. It could easily have said that they must encrypt (and keep encrypted) anything with this descriptor. I've looked at old EPG data and the appearance of this descriptor in the EPG data for non-HD channels is definitely new and appears to be selective.
I was just making the point, that the 'cock-up' explanation is also possible, especially given the apparently random appearance of the setting on SD EPG entries.
Would it be possible for auto-decrypt to turn the 'do not copy' flag off as well for non-HD recordings - please? But I'll understand if your response is simply to tell me to use auto-unprotect.