What does ENC mean on my SD recording?

I will try and reproduce this with tonight's The Road.
Shrek The Third on BBC THREE at 21:05 is also a candidate.

Edit: Sorry that should be 21:00
Code:
Sun Jan  3 21:00:00 GMT 2016 BBC THREE Shrek the Third
Sun Jan  3 23:35:00 GMT 2016 BBC ONE   The Road
Fri Jan  8 23:55:00 GMT 2016 BBC ONE   You Again
Sat Jan  9 21:05:00 GMT 2016 BBC THREE Shrek the Third
Sun Jan 10 00:00:00 GMT 2016 BBC ONE   The Peacemaker
Sun Jan 10 01:55:00 GMT 2016 BBC ONE   Halloween: Resurrection
Sun Jan 10 21:00:00 GMT 2016 BBC THREE Puss in Boots
 
Last edited:
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!.

Not for me, my Iron Man 3 was not flagged and Finding Nemo (1st shown in 2013) was flagged. However, it does appear that most of my flagged recordings could be classed as premieres if you include film shorts (e.g. The Farmer's Llamas, Stick Man).
 
My recordings marked with ENC in Webif do not show in other DLNA clients, if that's what you mean.
Maybe, but what I was really talking about is that recordings with protected status (hitherto confined to HiDef recordings) only stream to clients that can negotiate protected delivery. I can't remember whether that also means clients without DTCP can't see protected recordings in the media list presented to them (it's a long time since I had to contend with such things).

The CF auto-decryption mechanisms rely on being able to use the DLNA server to provide the decryption, effectively streaming the recording to a new decrypted file. This can't be done if the recording is not in the DLNA database, or cannot be accessed because of DTCP protection.

When we are sure what the consequences of all this are, I will have to update my primary sources to include the fact that some StDef transmissions are also protected and require similar handling to HiDef.
 
The D-book says there is no requirement to protect SD broadcasts and also states that unlimited SD copies (without encryption) are allowed to be made to other devices or media.
Taking these together, it effectively means that SD must be marked as "do not scramble", so the current EPG tags as detailed up-thread are 'illegal'.
 
Last edited:
I think the Wiki incorrectly shows the bits transposed for offset 0x3dc.
They were indeed, well spotted xyz321. Surprised it went unnoticed for so long. Fixed now.
And my apologies to BH, events have proved you were correct in your suspicion that the broadcast stream was the culprit. My faith in the BBC is now gone.
 
Last edited:
The BBC says 'do what you like' with SD recordings
As you say, the BBC FAQs here :-
http://faq.external.bbc.co.uk/resources/bbcfaqs/bbc_online/freeviewHD

has this :-
"All new Freeview HD-branded equipment (set-top boxes, integrated television sets and digital TV recorders) has the required content management technology built in. There are absolutely no restrictions on SD (standard definition) recordings, and all existing SD Freeview recorders are unaffected."
 
My ongoing recording of The Road on BBC 1SD does not have the 'Enc' flag. Out of interest, I started a recording manually on another unit and this does have the 'Enc' flag. As a protection mechanism it seems a bit hit and miss. Naughty of the BBC to do this without consultation though: mission creep is everywhere.
 
My ongoing recording of The Road on BBC 1SD does not have the 'Enc' flag. Out of interest, I started a recording manually on another unit and this does have the 'Enc' flag. As a protection mechanism it seems a bit hit and miss.
Mine has the Enc flag. Strange that it wouldn't be consistent. As far as we know the protection mechanism works well on the HD channels but there could be an extra 'definition' check in the code.
Is it confirmed that these recordings are also protected in the DLNA database?
Yes, they are protected.

Code:
sqlite> select localurl, protection from tblresource join tblmedia using (mediaid) where tblmedia.mediaid = 10158;
/mnt/hd2/My Video/The Road_20160103_2335.ts|DTCP
 
Since it now looks fairly likely that the mechanism is the EPG descriptor, I've updated the web interface to display the 'Enc' icon against these protected recordings in the EPG screens.
 
Will do. Thanks again.

I hate to be the skunk at the tea party, but.....

So diligent was I to follow af123's advice that I stupidly set all my three recorders to install auto-protect before last night's transmissions of Shrek the Third and The Road. As a result rather than the house full of Enc icons that I was expecting, I got none at all. Even the ones that were still on the three original 'faulty' recordings had disappeared - hence removing any evidence that might have been useful. I can also report that there were no Enc icons on any of the machine whilst they actually recording - contrary to what others have apparently seen.

But there's worse. One of the three machines failed to carry out the auto-protect installation (for reasons that I'm still investigating). If our suppositions have been correct - and assuming that these programmes were indeed transmitted with the 'scramble/do not copy' indicator set - then recordings on this machine should presumably have been marked with the Enc icon, both during recording and afterwards. Not so.

I await other people's reports with some interest.
 
Since it now looks fairly likely that the mechanism is the EPG descriptor, I've updated the web interface to display the 'Enc' icon against these protected recordings in the EPG screens.

With apologies for my ignorance, it seems to me that, in principle, there might be at least four different places where one might encounter information that might be pertinent to any 'scramble/do not copy' indicator:
a) in the EPG information transmitted ahead of the time of the programme in question;
b) in the EPG information transmitted whilst the programme is actually being transmitted
c) within the transmission data stream, but outside the EPG information (if the mechanism is to be effective, would they really just rely on the EPG to carry it? Or maybe the fact that the transmission (for HD) is scrambled anyway is sufficient?)
d) in the EPG information held within the hmt file (which presumably derives from one of the above?)

If so, do we have any confidence that they will all carry the same value? And do we know which of these sources the Humax itself uses? As far as I can tell, the Humax itself doesn't show the information ahead of time in the displayed EPG (at least for SD).

Just a thought - but based on ignorance.
 
My ongoing recording of The Road on BBC 1SD does not have the 'Enc' flag. Out of interest, I started a recording manually on another unit and this does have the 'Enc' flag. As a protection mechanism it seems a bit hit and miss. Naughty of the BBC to do this without consultation though: mission creep is everywhere.
My timed padded recording of this and "Howl" on BBC2 SD (it was listed as a film...) do not seem to have the Enc flag.

With apologies for my ignorance, it seems to me that, in principle, there might be at least four different places where one might encounter information that might be pertinent to any 'scramble/do not copy' indicator:
I could be just as ignorant but -
b) could be the "Now and Next" EPG which could be/may be/is not necessarily the same as a) - but should be.
d) I'm not sure whether the EPG info in the .hmt file contains these flags -would need to investigate.
I don't have any confidence that the "Now & Next" data is the same as the "proper" EPG.
It is possible the Humax might use both versions - there appears to be 2 copies of the EPG for the currently recording programme in my .hmt files (2000T) - The text has always been the same in these, but the guidance has been different (Could be because I use padding and therefore there are often three competing EPG items???)
 
Back
Top