• The forum software that supports hummy.tv will be upgraded to XenForo 2.3 on Wednesday the 20th of November 2024 starting at 7pm

    There will be some periods where the forum is unavailable, please bear with us. More details can be found in the upgrade thread.

Encryption sometimes not removed

R

rapple

New Member
Quick question, motivated by being away on holiday and a couple of my recordings that I took to catch up on aren't playable.

Note the only thread that I have found that might be relevant is here but that may just be my poor searching skills.

So, T2 is set to autodecode. That means I copy to PC using the DLNA streaming as that's easiest for me.
Works on most recordings, I've had a few where VLC can't read properly but other clients can (thread here - VLC issue), but there have been one or two that remained steadfastly completely unplayable except on the T2 through the TV. Up to now I've just watched them there, then deleted them which doesn't suit my viewing habits as well, but life's too short etc.

Having a bit more time than usual (as I am sat by a pool in the Med), I've been trying to find out what the cause is as one file I particularly wanted to watch copied OK but is not playing. Been through a number of things but ended up using TS Doctor on the file, which instead of telling me there was a missing PAT as most other programs did, actually told me the file was encrypted, hence couldn't find the PAT.

so...
a) is there anything I can do until I get back (presumably not if it's an encryption thing)
b) anyone else experienced decryption not happening on some files and found a fix?
If it's like the others that I have experienced, re-streaming makes no difference whatsoever but then I didn't suspect and therefore look at encryption issues.​

Many thanks.
 
Could you give us a little more information about the rogue files:
Are the SD or HD?
What are they flagged as in WEBif (I.e. What icons are showing next to them)?
If they are SD files they do not need decrypting to play via DLNA.

You seem to be saying that you expected them to be decrypted (decoded!?) but they are not. Is that correct? If so can you explain why/how you diagnosed this?
 
HarveyB said:
Could you give us a little more information about the rogue files:
Are the SD or HD?
What are they flagged as in WEBif (I.e. What icons are showing next to them)?
If they are SD files they do not need decrypting to play via DLNA.

You seem to be saying that you expected them to be decrypted (decoded!?) but they are not. Is that correct? If so can you explain why/how you diagnosed this?
Click to expand...
They will be HD.
I can't say what the if is showing as I am away on holiday, hence the question and supposition that I probably can't do much at present.

Yes, I expected them to be decrypted, all others do automatically. I used TS doctor on the files and this tells me they are encrypted.
Ta.
 
rapple said:
They will be HD.
I can't say what the if is showing as I am away on holiday, hence the question and supposition that I probably can't do much at present.

Yes, I expected them to be decrypted, all others do automatically. I used TS doctor on the files and this tells me they are encrypted.
Ta.
Click to expand...
Sorry, I should have said - I use the auto unprotect package.
 
Black Hole, apologies for the delay in response. Ended up relaxing without the extra videos and on return working.

So, I'm accessing the files through the web interface and using the DLNA link within browser to download the file. I think this means that the file is being transferred using the DLNA server, which will decode the file as it streams the file out. This is how I read the instructions in the linked page you gave - method 6 and the content share has always been set to on.

I must be missing something really simple here...

So, with the benefit of being in front of the web interface, the relevant items have the following icons:

upload_2015-9-15_9-32-52.png

and I would try to download the file by pulling up the individual entry and then using the DLNA URL as below to get to the file download.

upload_2015-9-15_9-39-44.png

Unfortunately I delete files when I have transferred them successfully, so I can't see any others with the DEC flag at the moment. Maybe it's just that I've not got this right for decoding and all the other HD files were in fact not encrypted.
 
The lack of an Enc icon shows that auto-unprotect has processed the flags for the recording, so that the HiDef recording is available for unprotected DLNA streaming and/or decryption on USB copy. The presence of the Dec icon shows that the recording has already been decrypted in some way, and a decrypted recording can be copied by any means for playback anywhere.

What can happen is that the flags get out of step with the actual recording status, and then things go tits up (obviously, if the system thinks a file is encrypted when it isn't, or isn't when it is, the data gets scrambled).
 
So, on the assumption that this hasn't been Decoded but the flag is fooling everything to think that it has, what is the best way to remove the DEC flag so I can try again? I assume that FOXY doesn't do this sort of thing and I can't see anything prebuilt in the applications to meddle with recording flags.

Happy to use an HEX editor if it's a particular location within the HMT files.

Are the ENC and DEC flags distinct? I guess they must be but knowledge is better than assumption...

Thanks again for help.
 
Just found it and was trying it out when your email dropped in.

So that's it then flag in weird state. Resetting the encrypted flag with the HMT utility allowed all to process properly.

Many thanks all.
 
rapple said:
Are the ENC and DEC flags distinct?
Click to expand...
Yes. "Enc" is not a very good acronym, but it is what Humax use in the SUI so we decided follow the convention. "Enc" means protected from decryption, whereas "Dec" means not encrypted. As you see, the one is not the inverse of the other.

Enc is also two flags: one in the .hmt sidecar file, and the other in the DLNA database. auto-unprotect clears both, but Foxy only clears the .hmt flag. The flag in the .hmt file controls decryption on USB copy via SUI, the flag in the DLNA database is derived from the .hmt at the time the recording is indexed and controls whether the destination for DLNA streaming has to be an approved device (ie one that is guaranteed to be locked down, and authenticates itself as such).

On-the-box decryption (without any manual intervention) exploits DLNA serving and requires the DLNA copy of the Enc flag to be clear; users without CF or models for which there is no CF can exploit the above using Foxy to clear the flag in the .hmt file and then moving the recording - which forces it to be re-indexed in the DLNA database. Without that, 1800T/2000T won't serve HiDef recordings at all - not even to an approved device.

To correct the Enc/Dec flags, you could also have gone to the WebIF >> Diagnostics page and run the fixencflags diagnostic (type it into the Run Diagnostic: box, in place of the default "general", then click "Run Diagnostic"). This scans all recordings and checks the status of the flags against an analysis of the actual .ts file content, correcting them if necessary.
 
Last edited:
rapple said:
So that's it then flag in weird state. Resetting the encrypted flag with the HMT utility allowed all to process properly.
Click to expand...
This is a known fault with BBC 3 and 4 HD and a combination of certain firmware versions and whether you've just retuned or not.
It sets both Enc and Dec flags and then auto-unprotect removes the Enc flag, leaving it marked as Dec when it isn't.
 
You must log in or register to reply here.
Back
Top