MontysEvilTwin
Well-Known Member
Just recording Iron Man 3 on BBC1 in SD and it has the 'Enc' icon. I've pasted a 'snapshot' of the hmt file below.
-
The forum software that supports hummy.tv has been upgraded to XenForo 2.3!
Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.
What does ENC mean on my SD recording?
- Thread starter Kirbett
- Start date
1) Yes. Specifically: a) Merry Madagascar BBC1 14: 40 20 December; b) Harry Hill in Professor Branestawm Returns BBC1 17:20 24 December; c) Shadow of a Doubt BBC2 00:30 2 January.
2) Indeed. We also need to be aware that this problem was first reported by Kirbett last July, but appears to have been dormant since then; that most other people don't appear to have encountered it (The post from MontysEvilTwin arrived as I typed that!) ; and that it did not recur when I re-recorded the the first two of the above programmes when they were re-broadcast.
3) It would appear that the actual mode of setting of the recording may not be one of the key determinants.
4) Yes, I'm aware of that. I just wanted to check that the - whether causal or not - the auto-decrypt had not actuallytaken place before the Enc icon was set.
5) I have the .hmt files from both the successful and unsuccessful recordings of the first two programmes (from different transmissions). Apart from the obvious variables (e.g. times) they are identical - apart from the copy-allowed field at X'03dc', as above. 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'.)
EEPhil
Number 28
I've found exactly the same with the .hmt files. Yet another film (Iron Man 3) on BBC One E Mid is showing ENC. The previous programme did not. In fact, the start of the film when run on from the previous programme didn't either. New recordings on this film show ENC. I can confirm that, apart from start/end times etc, the only change is at 0x03dc.
I wonder whether there is any difference caused by transmitter and software version on Humax. (As I am a 2000T user, CF isn't relevant and I have the most recent version of the 2000T software). I need to have a good poke in the data stream (.ts file) but I can't see anything obvious.
I wonder whether there is any difference caused by transmitter and software version on Humax. (As I am a 2000T user, CF isn't relevant and I have the most recent version of the 2000T software). I need to have a good poke in the data stream (.ts file) but I can't see anything obvious.
MymsMan
Ad detector
I can confirm Iron Man is recording with ENC flag set
Code:
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 =MontysEvilTwin
Well-Known Member
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.
I think the Wiki incorrectly shows the bits transposed for offset 0x3dc.
Bit 1 whex set enables copy limitation (number of copies at address 0x431).
Bit 2 when set disables the Enc icon (i.e. unprotects the data file)
The auto-unprotect package sets the value at 0x3dc to 4 for HD recordings. I am not sure if it also makes this change for SD recordings.
The hmt utility (and therefore the web interface) use location 0x3dc to determine if the recording has the Enc flag set. hmt -protect just sets 0x3dc to 4 and hmt +protect sets it to zero. The copy count is held at 0x431 and always seems to be zero on my SD recordings.
Unlike most events on BBC ONE, Iron Man 3 has descriptor 0x7e as part of its EPG data.
0x7e is "FTA_content_management" and the raw descriptor is:
The spec defines this as:
so it decodes as:
Do Not Scramble: 0
Control Remote Access: 0
Do not apply revocation: 1
I suspect that it is that do-not-scramble setting that's causing the Humax software to apply the Enc flag.
Most things on BBC1 do not have a FTA content management descriptor in the EPG data - actually there are only three things at present which have this and they are:
I've set "The Road" to record tomorrow to see if it gets the Enc flag. I need to read back through this thread (been away!) but are people saying that these programmes aren't properly auto-decrypted etc?
0x7e is "FTA_content_management" and the raw descriptor is:
Code:
7e 01 f1The spec defines this as:
so it decodes as:
Do Not Scramble: 0
Control Remote Access: 0
Do not apply revocation: 1
I suspect that it is that do-not-scramble setting that's causing the Humax software to apply the Enc flag.
Most things on BBC1 do not have a FTA content management descriptor in the EPG data - actually there are only three things at present which have this and they are:
- Iron Man 3
- The Road
- You Again
I've set "The Road" to record tomorrow to see if it gets the Enc flag. I need to read back through this thread (been away!) but are people saying that these programmes aren't properly auto-decrypted etc?
It certainly looks that way, in as much as the EPG data is part of the broadcast stream.
Last edited:
MontysEvilTwin
Well-Known Member
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 wonder what would happen on the FVP-4000T, or one of the YouView boxes? Presumably you would end up with encrypted copies that would only play on the original unit?
My local transmitter is Rowridge (BBC 1 South).
I, at least, am saying that auto-decrypt is not properly functioning on the affected recordings. However, note the possible difference between my usage and that which Montys EvilTwin appears to be reporting. In my case, the recording was not made directly into an auto-decrypt folder. It was only after the recording was subsequently copied into such a folder that the problem arose.
There's clearly scope for some confusion between the hmt Enc flag and the displayed Enc icon, and between the terms 'encryption' and 'scrambled'. The hmt 'Enc flag' at 0x28e appears to have nothing directly to do with the problem; it merely records whether the current file is encrypted or not. The presence or absence of the displayed 'Enc icon' appears to be an interpretation of the 'copy-allowed' flag at 0x3dc; toggling this between X'00' and X'04' causes the displayed Enc icon to be turned on or off - without affecting the state of the encryption at all. (I'm following Raydon's description of these fields.) It is this setting that seems to control whether decryption can actually be performed.
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. (And maybe the EPG setting is just an administrative glitch - remember, in my case, re-transmissions of the same programme were OK.)
(Skating on to thin ice) since MontysEvilTwin reports that, at the end of the recording the Enc icon disappears and auto-decrypt comes into play, whereas for me the problem only appears when I subsequently copy the recording to an auto-deccrypt folder, I wonder whether the problem is in any way related to how and when control is passed between the Humax and CF software?
I, at least, am saying that auto-decrypt is not properly functioning on the affected recordings. However, note the possible difference between my usage and that which Montys EvilTwin appears to be reporting. In my case, the recording was not made directly into an auto-decrypt folder. It was only after the recording was subsequently copied into such a folder that the problem arose.
There's clearly scope for some confusion between the hmt Enc flag and the displayed Enc icon, and between the terms 'encryption' and 'scrambled'. The hmt 'Enc flag' at 0x28e appears to have nothing directly to do with the problem; it merely records whether the current file is encrypted or not. The presence or absence of the displayed 'Enc icon' appears to be an interpretation of the 'copy-allowed' flag at 0x3dc; toggling this between X'00' and X'04' causes the displayed Enc icon to be turned on or off - without affecting the state of the encryption at all. (I'm following Raydon's description of these fields.) It is this setting that seems to control whether decryption can actually be performed.
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. (And maybe the EPG setting is just an administrative glitch - remember, in my case, re-transmissions of the same programme were OK.)
(Skating on to thin ice) since MontysEvilTwin reports that, at the end of the recording the Enc icon disappears and auto-decrypt comes into play, whereas for me the problem only appears when I subsequently copy the recording to an auto-deccrypt folder, I wonder whether the problem is in any way related to how and when control is passed between the Humax and CF software?
I tried 'epg -D0x7e dumpraw' but it produces no output. It might be useful to be able to look at this descriptor.
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.
You can view them with the existing utility by increasing the debug level to 4 or higher for now although only in hex during the decoding process. That's what I was using last night.
Last edited:
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.
Version 1.2.1 is on its way to the repository. It will also include a new content_mgmt column in the generated SQLite EPG database that is visible to the web interface - if this behaviour is confirmed then I could add an Enc icon to the affected EPG entries.
Code:
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(Service 4170 being my BBC ONE)
Last edited:
I will record it on all three machines, to see if there is any difference between them. Though, given your hypothesis, I suspect that it's just coincidence that the three failed recordings all appeared on the same machine.
I haven't felt the need for auto-unprotect (so far!) since I never record anything in HD.
Thanks for the helpful clarification. This would certainly appear to explain why auto-decrypt isn't working on these recordings (because the 'copy allowed' flag is set to off). And perhaps why others haven't encountered the problem if they have auto-unprotect specified. It would presumably also explain why MontysEvilTwin (and others?) report seeing the Enc icon displayed whilst the recording is taking place, and why it disappears after the recording has finished.
I agree. 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.
Thanks again for this - and everything else.
I'm not sure that it looks random - everything flagged now is a film premiere (as far as I can tell). This is definitely worth an email to the BBC!
auto-unprotect does more than unsetting that flag. It also updates the DLNA database to disable stream protection (DTCP) which is what then allows the decryption to work. I recommend just installing auto-unprotect and letting it do its thing. You'll see the Enc flag whilst recording but it should automatically disappear shortly afterwards and, as the DLNA database has also been patched up, decryption should succeed.