What does ENC mean on my SD recording?
- Thread starter Kirbett
- Start date
bugrain
New Member
I'm recording a lot of stuff over the Christmas period and am getting ENC recordings almost daily at the moment - all are on BBC1 but not all BBC1 recordings have the ENC flag. Think all are from scheduled recordings. My current 'workaround is'
This creates an "_original folder" with the recording in there with ENC flag but cannot be decrypted.
Then, after some time and/or re-boot it can be decrypted.
Code:
[telnet] hmt -protect
[webif] opt+ decryptThen, after some time and/or re-boot it can be decrypted.
EEPhil
Number 28
As an intruder on this topic ( I have a 2000T and obviously no CF) - I have spotted the ENC icon on a BBC SD recording - I can't remember which one and I was too quick to delete it after I watched it. Only seen it once so far. It wasn't caused by rewinding and pressing record. It might have been a chased recording. I did wonder whether the BBC were trying clamp down on copying 
Last edited:
Black Hole
May contain traces of nut
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?
It isn't.
Black Hole
May contain traces of nut
If it's not a broadcast property, what explains the errant setting of the ENC flag for a non-HiDef recording? The alternative is a software fault of some kind.
I think you've just answered your own question. If it was a broadcast property we would all suffer the same result at the same time, not just some users, on odd occasions.
Last edited:
I agree, but the broadcast format, including metadata, is known, well documented, and open for analysis, whereas the Humax software is a closed book.
Last edited:
Black Hole
May contain traces of nut
Even a software bug has to be triggered by a specific set of circumstances - and considering the circumstances it seems most likely to me that it is something (even if not intended) in the broadcast stream.
MymsMan
Ad detector
Whilst the broadcast format might not contain a definition of an Encryption Protection property it is probably something within the transmission stream that the Humax software is (mis)interpreting as a requiring the ENC flag to be set and BBC are for some reason now causing it to be set on a small subset of recordings and triggering the previously dormant bug.
Since we have no control of the Humax software or the broadcasters transmission streams we have no way of preventing the flag being set but fortunately thanks to the auto-unprotect we can at least deal with the consequences unlike those who don't have access to the custom firware!
Black Hole
May contain traces of nut
I think that's more or less what I said. It would be interesting, and possibly useful, to figure out what the trigger is.
MymsMan
Ad detector
You were posting as I was typing!
Black Hole
May contain traces of nut
No it doesn't. auto-unprotect clears the ENC flag in the .hmt file, but it also clears the protected status in the DLNA database. If the DLNA database shows a recording as protected, it will not be streamed to unauthorised clients - and therefore WebIF decryption is not available. This is equivalent to having used Foxy on the recording. Until the recording is decrypted, MPG extraction will not be available.
This begs a question: are these errant StDef recordings with ENC set also protected in the DLNA database?
The database entry for a recording can be reset by renaming or moving the recording to another folder, and then waiting for the indexer (or rebooting - which forces the indexer to run).
This begs a question: are these errant StDef recordings with ENC set also protected in the DLNA database?
The database entry for a recording can be reset by renaming or moving the recording to another folder, and then waiting for the indexer (or rebooting - which forces the indexer to run).
EEPhil
Number 28
I was only going to report another ENC flag set on a StDef recording (BBC2 this morning 00:30 film "Shadow of a Doubt")
Obviously those of us with either a FoxT2 or a 2000T have a way around this problem, should we want to copy the programme. People with the 4000T are going to have fun if this is happening on their device
The above mentioned film does not seem to be in the DLNA database.
Obviously those of us with either a FoxT2 or a 2000T have a way around this problem, should we want to copy the programme. People with the 4000T are going to have fun if this is happening on their device
I can add the following provisional observations.
1) I have experienced the problem on one of my machines three times since the 20th December. Twice on BBC1 and once on BBC 2 recordings. One of the programmes was this morning's "Shadow of a Doubt", as reported by EEPhil.
2) I have not experienced the problem on either of my other two machines. All three run CF and are fed by the same aerial.
3) All the recordings are SD. All were set using non-series recording, set to start automatically and use padding. All were manually moved into an Auto-decrypt folder after they had completely. I believe - but cannot be certain - that they did not exhibit the Enc icon until after the move. (Other recordings from the same channels and performed in the same way did not exhibit the problem.) The Enc icon is displayed both on the screen and on the Web-if.
4) Offloading the files via FTP and attempting to tun them via VLC suggests that they are still encrypted.
5) The problem may be connected with the copy-allowed field at X'03DC' in the hmt file, rather than the enc flag at X'028E'. The latter seems to be set as one would expect whereas, in the failing recordings, the copy-allowed field is set to X'00' rather than X'04'. However, the allowed-number-of-recordings' field at X'0431' is set to X'00'. If so, this suggests that, confusingly, the Enc icon and the hmt 'enc' flag are unrelated to each other.
6) Further corroboration might be provided by the fact that if the copy-allowed field in the failing recordings is manually changed to X'04', and the file moved back into the auto-decrypt folder, it then behaves normally. i.e. it is decrypted, the Enc icon disappears and VLC can now play the file.
7) This would appear to add some weight to the earlier speculations that something in the broadcast transmission streams for these particular programmes might be interacting with the DLNA indexing or auto-decrypt processing to set the copy-allowed and copy-count fields in such a way that the recordings become locked to any further processing. i.e a transient bug caused by interacting variables. Yuk!
I hope this helps.
1) I have experienced the problem on one of my machines three times since the 20th December. Twice on BBC1 and once on BBC 2 recordings. One of the programmes was this morning's "Shadow of a Doubt", as reported by EEPhil.
2) I have not experienced the problem on either of my other two machines. All three run CF and are fed by the same aerial.
3) All the recordings are SD. All were set using non-series recording, set to start automatically and use padding. All were manually moved into an Auto-decrypt folder after they had completely. I believe - but cannot be certain - that they did not exhibit the Enc icon until after the move. (Other recordings from the same channels and performed in the same way did not exhibit the problem.) The Enc icon is displayed both on the screen and on the Web-if.
4) Offloading the files via FTP and attempting to tun them via VLC suggests that they are still encrypted.
5) The problem may be connected with the copy-allowed field at X'03DC' in the hmt file, rather than the enc flag at X'028E'. The latter seems to be set as one would expect whereas, in the failing recordings, the copy-allowed field is set to X'00' rather than X'04'. However, the allowed-number-of-recordings' field at X'0431' is set to X'00'. If so, this suggests that, confusingly, the Enc icon and the hmt 'enc' flag are unrelated to each other.
6) Further corroboration might be provided by the fact that if the copy-allowed field in the failing recordings is manually changed to X'04', and the file moved back into the auto-decrypt folder, it then behaves normally. i.e. it is decrypted, the Enc icon disappears and VLC can now play the file.
7) This would appear to add some weight to the earlier speculations that something in the broadcast transmission streams for these particular programmes might be interacting with the DLNA indexing or auto-decrypt processing to set the copy-allowed and copy-count fields in such a way that the recordings become locked to any further processing. i.e a transient bug caused by interacting variables. Yuk!
I hope this helps.
EEPhil
Number 28
Another film on BBC2 SD seems to cause the ENC icon to be displayed. The following (non-film) programme is NOT showing the icon.
Despite raydon
saying this is not a broadcast property, it sure is beginning to look like one - with the BBC deliberately flagging certain films to prevent copying. I'll have to use my USB dongle to record one of these ENC'd SD items and examine the stream and see if anything obvious is going off!
Despite raydon
saying this is not a broadcast property, it sure is beginning to look like one - with the BBC deliberately flagging certain films to prevent copying. I'll have to use my USB dongle to record one of these ENC'd SD items and examine the stream and see if anything obvious is going off!
EEPhil
Number 28
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.
Black Hole
May contain traces of nut
If everyone experiences the same on a particular programme, then clearly it has to be some property of the transmission (whether intentional or not).