• 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.

Problems copying to USB disk

I must say, the logic behind the whole encryption/decryption thing has always had me entirely baffled. Can't see the point in encrypting SD recordings, when the vanilla box just decrypts them if you ask it to copy to an external drive. (HD is another story of course.)
The logic is that Humax has to toe the line with regard to the requirements placed on them by their licence to use the Freeview EPG data. The DRM system as implemented has features we have rarely (if ever) seen invoked - such as the ability to limit the number of copies made to USB. Encryption to internal HDD is a pre-requisite for enforcement of rights management when required, regardless of whether it is StDef or HiDef content.

DVB-T receiver dongles for PCs, which natively provide in-the-clear data which can be saved directly to disk, don't have access to the EPG and have to use Internet programme guides.

I don't entirely agree with GT's previous remarks about the key to decryption - the fundamental feature (or flaw) of the HDR-FOX that enables on-the-box automatic decryption is that the HDR-FOX includes a DLNA server while the Foxsat-HDR does not, and it is possible to trick the server into streaming the HiDef content as an unprotected stream. Previously, analysis of the .hmt file flags only enabled decryption of HiDef by USB copy with manual intervention.
 
Last edited:
Oh wow, it's the EPG rather than the actual video content? (At least for SD?)

OK, that's a bit of a shocker.
But taking that as read, how come it's then OK for Humax to decrypt said stream once a user asks their box to copy it to an external drive? Does the licence permit that? If so, what on earth are the licence terms meant to protect?
(I thought it was all about content providers not wanting their stuff to be copied, in which case decrypting to external drive still doesn't make sense to me.)

Edit: I should have added in reply to Graham's remarks that in case there's any doubt, I'm VERY glad my box does what it does ;)
 
It's the HiDef that has to be protected, but the implementation is such that DRM can be turned on or off, or restrictions put in place, for any of the content. The EPG data itself is copyright intellectual property, and it's legitimate use is licensed by Humax from Freeview. Under the licence terms, DRM is required - even though the actual video data (StDef and HiDef) is broadcast in-the-clear.
 
Oh wow, it's the EPG rather than the actual video content? (At least for SD?)

Yes, but actually for HD only. As far as I remember the content providers weren't able to encrypt high definition content because that would be against the terms of the freeview agreement (not to mention the key management problems that would be created with all of the different freeview boxes/TVs out there).
However, they wanted to protect their content and so they compressed the EPG data for high-definition channels using a fixed compression dictionary and it is the dictionary that is under legal protection.
In order for a box manufacturer to use that dictionary and therefore be able to decompress the EPG data, they must sign an agreement requiring them to encrypt the content if they write it to disk.

The dictionary can be found in the public domain and is actually used by the Humax CFW web interface in order to display EPG data for high-definition channels.

So, for example, compare the raw dump of next Saturday's Doctor Who on BBC ONE HD:

Code:
humax# epg -S 17540 -C/1FTX24 dumpraw
...
  content.d77.text: 1f 02 b2 8b 3a b9 87 13 d2 54 da eb 6c 0e d5 a1 72 d3 e3 6c 01 91 05 ea ec 3b 97 47 22 dd 31 2f 50 cd 17 5a bb fc 65 31 8c bd ff bc 53 6d c7 32 fe 60 49 53 cb cd ac 4a 65 cf db b3 ed d0 67 57 4d 51 56 07 94 b1 33 fc 34 fe d5 41 bf 12 d3 b3 5c 3c cb 04 8e a8 de 2b 1c b8  (....:....T..l...r..l.....;.G".1/P..Z..e1....Sm.2.`IS...Je.....gWMQV...3.4..A....\<.....+..)p
which is compressed, with the parsed one:
Code:
humax# epg -S 17540 -C/1FTX24 dump
----------------------------------------------------------
  Service ID: 17540
  Event ID: 41741
  start_date: 0xdfd9 19:25:00 (Sat Oct 10 20:25:00 2015)
  duration: 0:45:00
  encrypted: 0
  Name: Doctor Who
  Text: 4/12. Before the Flood: Sci-fi drama. On a remote army outpost... (potential spoiler removed)
  Content Type: Undefined (15)
  Event CRID: /1FTX24
  Series CRID: /UZJ7X6

DVB-T receiver dongles for PCs, which natively provide in-the-clear data which can be saved directly to disk, don't have access to the EPG and have to use Internet programme guides.

That doesn't make any sense. DVB-T(2) dongles just provide selected data streams to host computers running software. Most of the media centre type software includes the Huffman tables required to decompress the EPG data - for example https://github.com/MythTV/mythtv/blob/master/mythtv/libs/libmythtv/mpeg/freesat_tables.h
(same tables used for Freesat and Freeview).
Many of them may prefer to use Internet-based EPGs due to extended range however.
 
They won't be encrypted again.
Ah-ha!
I have grossly misunderstood ... and have since done a lot more study of the very explicit info on this site...thank you SOOOOO much for all this

First, this might invalidate my earlier copy times, as the first copy would have carried out the decryption and all other to and fro-ing would have been on decrypted files. So here's a new set of figures hot off the press:

Tests using Freecom Toughdrive 120GB with both FAT32 and NTFS partitions on HDR USB port:

Fox->USB (NTFS): with decryption: 7.6 GB/hour
Fox->USB (NTFS): 16 GB/hour
USB->Fox (NTFS): 46 GB/hour
Fox->USB (FAT32) with decryption: 12 GB/hour
Fox->USB (FAT32): 52 GB/hour
USB->Fox (FAT32): 55 GB/hour

So the copy off the Humax to a USB NTFS partition is still very slow.
The figures are also all slightly lower than previously as I had not accurately measured ALL files including sidecars at the time.

Tests using ftp over wired ethernet LAN to a PC with external Seagate 1TB Expansion Desk or Freecom Toughdrive 120GB connected:

Fox->PC : 40 GB/hour
PC ->Fox: 30 GB/hour

Having realized that the ftp copies are NOT decrypted, I now reckon that my preferred route is to carry out decryption on the HDR prior to transfer. This would not be necessary at all if files are going back to the same HDR (albeit with new disk).

I understand that a suitable ad-hoc decryption process in a nutshell is...

----
PVR:
menu > settings > system > internet settings > Content Share = ON
Wait for all recordings to be indexed, WebIF "DLNA" flag.

WebIF:
Install auto-unprotect to ALLOW decryption of files flagged "ENC" - typically HiDef.
Wait for "ENC" flags to be cleared. Use reset-unprotect if necessary.
Use WebIF "Opt" button to decrypt:
All recordings, or any specific folder(s), by enabling "recursive-auto-decrypt" or "auto-decrypt" as appropriate.
Triggered to run within 10 minutes- wait for all "DEC" flags to appear.
Use WebIF encsummary to check whole disk.
Disable "recursive-auto-decrypt" and/or "auto-decrypt" on each folder if no longer required.
Remove auto-unprotect if no longer required.

ALTERNATIVELY:
To have decryption ongoing for each new recording,
especially catering for full recovery of recordings if motherboard goes down:
Leave "auto-unprotect" and "recursive-auto-decrypt" on MyVideos always ON.
Run WebIF encsummary to check all ready.


I think I'm finally there!
 
Last edited:
Right. I would just set recursive auto-decryption on the top level My Video folder.

If you have the undelete package installed then you will end up with all of the original encrypted recordings in the dustbin. Keep an eye on overall disk space whilst things are decrypted.

You can use the encsummary diagnostic to get a view of how many are still to be decrypted (It takes a short while to run).
Code:
Running: encsummary
Showing files under /media/My Video/
Encrypted: 0
Decrypted: 983
Total:  983
 
Disable "auto-decrypt" on each folder if no longer required.
Remove auto-unprotect if no longer required.
I wouldn't advocate uninstalling auto-unprotect. It does no harm and may do some good. I decrypt everything anyway, using the recursive auto-decrypt setting.
 
alexp - you can estimate when your HDR-FOX was manufactured by looking at the serial number, Mac address and loader version. More info here.

Hi:

new Aug 2013: 710 5936, 63710 5936 00599 (Loader a7.33)
recent second-hand: 710 5555, 67710 5555 00600 (Loader a7.33)
recent second-hand: 710 4328, 63710 4328 00576 (Loader a7.31)

The last of these has faint blue ring and text display.
It also registers about 24,000 Power-On hours, which might be the cause.
The other stats are all reasonably similar, so it was probably left permanently on for 3 years.
 
Just decrypt everything as routine, like the rest of us (mostly). Things Every... (click) section 5, follow the link to decryption, Method 2.

If you really only want to decrypt the recordings you wish to download, the easiest way is Method 4.
 
I wouldn't advocate uninstalling auto-unprotect. It does no harm and may do some good. I decrypt everything anyway, using the recursive auto-decrypt setting.

I sympathise, but I am not the only user (hence 3 pvr's !). What happens if someone tries to chase play, or play soon after a recording finishes before all the background processing for this has occurred? I'll get beaten up if things go wrong!

...recursive auto-decrypt on the top level folder MyVideos?
 
If you decrypt everything automatically there is the benefit that, if the Hummy packs up, all the recordings on the HDD are accessible either by a computer (with Windows you need software such as Paragon ExtFS, etc) or by another Hummy. You lose all non-decrypted recordings if the Hummy they were made on fails.
 
What happens if someone tries to chase play, or play soon after a recording finishes before all the background processing for this has occurred? I'll get beaten up if things go wrong!
1. Nothing. 2. They won't.
 
I'm warming to this.

What is there to watch out for when leaving "auto-unprotect" and "recursive-auto-decrypt" on?
From the point of view of non-tech user's actions and behaviours, who won't be able to stop and fix,
and who might view CF with suspicion if things go wrong.
 
Regarding the EPG & encryption, thanks for the clarification guys, and I must say that's even more beyond bonkers. You just couldn't make it up.
IIRC, the EPG data is the main stuff that the strip program removes, right? I certainly don't want it in my files, making 'em bigger to no purpose. Once you've hit record, the EPG data is useless (yes?), so I'd be ecstatic if the player never even saved it to the disk. I'm still at a loss to understand why the player is generous enough to decrypt any SD file you transfer to an external disk (cos the EPG data is still in there...). Not knocking it, mind ;)

One of alexp's latest posts has made me think "whoops", btw: I totally forgot that the Humax UI will decrypt on-the-fly during "copy to USB" (ironic, given this latest conversation). This means that I may have been unduly harsh on it when comparing its speed to the command-line copying. I will carry out that particular test again, making sure to choose a pre-decrypted file this time...

UPDATE: OK, I did the Humax-UI copy of a decrypted file to an ext3 partition - this time it achieved ~ 18MB/s! :thumbsup: I take it all back about the UI copying being rubbish...
 
Last edited:
Actually I guess that's part of what I don't understand.
Why would they want/need to decrypt when you copy to USB? If for some reason the stuff needs to be encrypted on the internal disk, why would it not need to be encrypted on an external disk?
It's not the method that some other DTT HD recorders use but there is some logic behind it.
Some broadcasts are flagged to only allow export once. If the manufacturer wants to use the freeview epg HD data then they have to also respect this as well as encrypt HD recordings to the internal disk, and make it difficult for the user of the recorder to circumnavigate. For standard definition recordings this encryption of the standard recordings on the internal disk make it harder to extract a second time using some other technique, while the encryption on the fly of the standard definition recordings is still compatible with licence restrictions imposed on recorders that use the HD data from the freeview epg, and is beneficial to the user of the HDR-FOX T2.
 
Back
Top