What does ENC mean on my SD recording?


New Member
Somehow, a couple of my recent SD recordings have been marked "Enc" in my PVR Media List, as a result of which I seem unable to view them remotely through a DNLA interface. These recordings were both non-series recordings, with scheduled start/stop times manually adjusted. I'm told that ALL SD recordings are encrypted, so what does the Enc icon mean, and any idea how I might have managed to trigger it?

Running CF 1.03.12 mod 3.00 (though I used the PVR, not the CF, to schedule the recordings)
Normally the "Enc" flag means that a recording is protected from being decrypted on copy (the term was chosen by Humax, not us), and that DLNA streaming uses a protected delivery mechanism to authorised clients only. Enc is applied to HiDef recordings; I have not come across a case where a StDef recording is flagged Enc.

If you are running auto-unprotect, this should clear the Enc protection automatically. However, as Enc is only expected on HiDef recordings it is possible auto-unprotect ignores StDef recordings. Removing Enc is a prerequisite for all methods of decryption.

+1 to the fixencflags idea, although just running it and fixing the problem (if it does) won't provide us with any information as to why this has happened.
Last edited:
I installed auto-unprotect yesterday but it does not seem to have cleared the flags. The web-if lists the flags in the Media Details as SD Encrypted ODEncrypted. That said, I've discovered that I can access the .TS file directly using the URL listed in those details. I've yet to try repeating the scheduling process to see if the problem persists.

Just tried running fixencflags, but it doesn't seem to have changed the Enc status of the recordings.
From a humax command line you can use the HMT utility to turn the encrypted flag off
hmt -protect "recording file name"
but that doesn't explain what caused the problem initially
On several occasions I have had an ENC flag remaining after a Hi-Def programme has finished recording, this is always when the the recording is being viewed in 'chase-play', however auto-unprotect has always resolved this after a stand-by / power-up cycle, Also, in the OP's case the file appears to be a Standard Def file, which should never have the ENC icon against it anyway.
I've run hmt -protect and that's cleared the Enc icon on both the PVR's and the web-if's Media Lists. My DLNA client (VLC) still doesn't see the two affected titles, but I suspect that's just a case of waiting for the DLNA db to update itself. Or will I need to Reset DLNA Database?

Still don't understand what caused the problem, but I've manually rescheduled three similar SD programmes in the forthcoming week. If it happens again on one or more of those I might start to get a feeling for what's triggering it.
DLNA indexing is something else that can be speeded up by a stand-by / power up cycle, you need the file to have this icon against it in the Web-If :- DLNA-small.jpg
Well the files had the Indexed on DLNA icon, and the PVR certainly went through stand-by overnight (is that what you meant by stand-by / power-up cycle ?) , but the DLNA client still didn't pick them up. However, resetting the DLNA database did the trick.
is that what you meant by stand-by / power-up cycle ?.
Yes, strictly speaking a 'power cycle' would involve removing power completely, but a stand-by / power-up cycle for the Humax, means, placing the unit in stand-by, waiting for the unit go silent (no hard disk spinning) and then wakening the unit back up, by setting it to it's 'on' state. When this is done a lot of 'start-up routines' are initiated, some of which don't happen at any other time.

Similar to OP, I have 3 recent SD recordings that have the ENC flag listed against them (in the 'More details popup Flags are "SD New Encrypted ODEncrypted". All were recorded from normal BBC1 Yorkshire channel, so not HD (Channel 47, 682.0 MHz, Yorkshire PSB1/BBC A, DVB-T (SD)). All were one off timed recordings. No other recordings in the past few days have had this problem, can't be 100% sure which channels I recorded from though but have recorded a lot of stuff over Xmas.

Interestingly, for me the recordings are indexed by the DLNA server though,

Have not tried suggestions above to resolve this and, if it helps, I can keep at least one of the recordings untouched for investigations if anyone has any suggestions.

Also, the Opt+ menu does not allow me to decrypt as that menu option is disabled.
I presume you have read post 3 and the rest of this topic, I have nothing to add. This may provide an opportunity to find out what's going on.
Yes, have read the posts - just run "hmt -protect" on one of the files which has cleared the flag. This just confirms the above too.

What info. do you want or what would you like me to try to help figure out why this happened?
:) No problem.

Meantime, some more info...

Having run "hmt -protect" all looked good until I tried to "extract MPG" form the file (in webif). Progress bar jumps from 0% to 100% after about 3-5 seconds and, obviously, no MPG file is written. The recording is also in a folder that should auto/decrypt/auto extract MPG. The "auto" log file shows this for the recording:
5000 26/12/2015 15:45:18 - Error during mpg extract:
4999 26/12/2015 15:45:13 - Converting...
4998 26/12/2015 15:45:13 - MPG: /media/My Video/_decrypt/Madagascar 3_ Europe's Most Wanted_20151225_1225​

Can't find any other info in other logs that seems to relate to this.
I've never seen a standard definition recording with an Enc flag. Even so, the auto-unprotect process should have removed the flag.
Could you run the following couple of commands against one of the recordings which still has the flag? (The first command is just to install the package which contains the xxd utility)

humax# opkg install vim
humax# xxd Home\ Alone\ 3_20151226_1529.hmt | grep 03d0:
00003d0: 0000 0000 0000 0000 0000 0000 0200 0000  ................
humax# stripts -E Home\ Alone\ 3_20151226_1529
Hi af123

First results of running the above commands:
humax1# xxd Madagascar\ 3_\ Europe\'s\ Most\ Wanted_20151225_1225.hmt | grep 03d0:
00003d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
humax1# stripts -E Madagascar\ 3_\ Europe\'s\ Most\ Wanted_20151225_1225
Processed in: 0.03s
humax1# xxd Finding\ Nemo_20151224_1550.hmt | grep 03d0:
00003d0: 0000 0000 0000 0000 0000 0000 0000 0000  ................
humax1# stripts -E Finding\ Nemo_20151224_1550
Processed in: 0.02s

Madagascar 3 is the recording that I ran "hmt -protect" on, then ran "hmt +protect" before dong the above (see later in this post as to why). Nemo is untouched by me. Both recordings had been copied to a folder that is set to Auto Decrypt/Auto extract MPG though. I didn't see what the ENC flag was before I copied the files to this folder but only three out of the 10s of recordings copied to this folder recently suffer this problem.

Now, as to why I tried the "hmt +protect" - went to watch Madagascar 3 and it would not play on the Humax direct to TV - said that the channel was scrambled! The other two untouched 'ENC' recordings do play OK, though.

And, one final strange thing. An "_original" folder has been created in the folder with my ENC recordings that has a copy of Madagascar 3 in it. Oddly, this version is not encrypted and plays fine (flags are "SD {Unlimited Copies} ODEncrypted"). Judging by the timestamp of the folder, this was created at the time I ran the "hmt +protect".
Today I've had an instance of 'Enc' on BBC1 SD. This was a recording made by rewinding the time shift buffer and pressing Record. The Media List was then selected and the item replayed once it had caught up recording the buffer (Enc was not present at this time). When the end of the programme was reached and it dropped back to the list, Enc was present. Didn't manage to move it somewhere safe before auto-unprotect got to it though.
There was also a recording scheduled for the programme immediately following in case that is relevant.

Now there's another recording that I can't delete (from the Humax UI) as Delete and Move/Copy are greyed out, but which otherwise looks OK. Don't know if these are connected...