BootHDR-2000T

MontysEvilTwin

Well-Known Member
A couple of weeks ago I made a failed attempt to install bootHDR on a HD-FOX using the HDR-2000T update file. I've thought about this more and I've seen Drutt posting today (hi Drutt) so I thought I'd create a thread. From reading posts on other threads I think that it may be possible but would need changes to the package and the tool used to extract the software from the HDF file, requiring the time and effort of the people capable of doing this.
I am interested for a couple of reasons. Navigation of the new iPlayer site is really slow and clunky on the HDR-FOX. ChrisDaniels has suggested that this is due to the menu animations, and he is probably right, but I have noticed that after the landing page loads, the page is immediately redrawn, with everything then shifted to the right like an offset is being applied. This could also tax the processor and slow the site navigation so I wonder if the HDR-2000T version would behave any better?
The main reason though is DLNA. There is no native server on the HD-FOX, even in HDR mode. I have read in a thread that the HDR-FOX has a hardware module for DLNA and that is why it doesn't work on the HD-FOX. The 2000T has clearly been designed with cost cutting in mind and it is known that its DLNA server can't serve a protected stream. Does this model have a software based DLNA server? If it does, could it be persuaded to run on the HD-FOX? We also know that if you Foxy the HMT file of a high def. recording on the 2000T, then move the recording to another folder, it is then served as a decrypted stream. Could this be used as a way of automating decryption on the HD-FOX? There are many ifs here but if it does work you could schedule recordings as normal, and use auto-unprotect to clear the 'enc' flags. Then reboot into HDR mode (perhaps at a specific time using a script to change mode) and automatically decrypt via the DLNA server and shut down. Simples (probably not!).
 

Black Hole

May contain traces of nut
While not wanting to pour cold water on your idea, the thought that the HDR-2000T hardware is sufficiently compatible with the HD-FOX for HDR-2000T code to do anything useful at all on a HD-FOX seems pie in the sky to me.

You think that cost cutting means removing features. In fact, cost cutting means finding cheaper ways to implement and manufacture a complete package that nonetheless will be seen by the consumer as an upgrade. We view the 2000T as a step backwards simply because we can't get into it - that's not what the consumer market sees. Some of the cost reduction will be in a cheaper chassis, but the cost of electronics is coming down all the time so the "brains" are likely to have more electronics in it, not less (although contained, possibly, in fewer ICs).

That said, it would (I think) be quite straightforward to make the 2000T firmware loadable using BootHDR, or even as a firmware update (capacity might be a problem), but the risk of bricking it is too great as a firmware update, and I have no idea whether it would be actually dangerous to try booting to the 2000T code.
 
OP
MontysEvilTwin

MontysEvilTwin

Well-Known Member
@Black Hole. You are right that the hardware may be so different that the software won't run on the HD-FOX. Attempting it depends on how easy it is to modify the package and HDF tool, and whether or not the people who are capable of doing this think it is worth the effort.
I take your point about cost cutting. For example, the HDR-2000T has a faster processor and more memory than the HD- and HDR-FOX but in relative (and possibly absolute) terms these higher spec. components are likely to be less expensive. However, the lack of the display panel and the replacement of the stylish, multicolour led ring with simple red and blue LEDs that struggle to distinguish between 'on and recording' and 'standby' are cost cutting measures that detract from the user experience and give the unit a cheap feel. The fact that the 2000T cannot serve a protected stream made me wonder if they have dispensed with the hardware module and implemented a software based DLNA server? Has the DLNA module been located on the HDR-FOX main board, and is there an equivalent in the 2000T?
 

af123

Administrator
Staff member
I have read in a thread that the HDR-FOX has a hardware module for DLNA and that is why it doesn't work on the HD-FOX.
That's the first time I've read that. Doesn't make sense, the DLNA server is a purely software component, although it makes use of the SoC for decryption.
 

Black Hole

May contain traces of nut
Most of the HD/HDR-FOX functionality (and presumably 1800/2000T also) is contained in a SoC - "system on a chip". The path the various video data streams take are (most likely) routed through various hardware blocks implemented within the SoC - we know the SoC is supplied by Broadcom, and is targeted at this kind of application. There will be a hardware block to handle encryption/decryption, for example.

The 2000T will serve StDef, so it must already be capable of decrypting data en route from HDD to the DLNA stream. We also know that by applying Foxy to a HiDef recording and then forcing a re-index, the 2000T will serve HiDef. It is simply a case of Humax having decided to code it so that recordings marked Enc are not entered into the DLNA index, and therefore cannot be requested for streaming. It is unlikely that a software decryption process could keep up with the data rate.
 
OP
MontysEvilTwin

MontysEvilTwin

Well-Known Member
That's the first time I've read that. Doesn't make sense, the DLNA server is a purely software component, although it makes use of the SoC for decryption.
I have probably just got the wrong end of the stick: I'll try and find the post and reread it. Why does the DLNA server not work on the HD-FOX in HDR mode? Is this known?

Edit. It was this post here that stuck in the back of my head and made me think that the HD-FOX lacked the hardware necessary to run the HDR-FOX DLNA server.
 
Last edited:

Black Hole

May contain traces of nut
That is an interesting point. Various ducks need to be lined up for the HDR-FOX - for example the server only indexes content on the HDD, and the HD-FOX doesn't have one. When you boot into HDR mode, can you then access Menu >> Settings >> System >> Internet Setting >> Content Sharing = On? If you can, does an external DLNA client detect the existence of a server?

The answers to these might help pin down where the blockage is.
 
OP
MontysEvilTwin

MontysEvilTwin

Well-Known Member
The 2000T will serve StDef, so it must already be capable of decrypting data en route from HDD to the DLNA stream. We also know that by applying Foxy to a HiDef recording and then forcing a re-index, the 2000T will serve HiDef. It is simply a case of Humax having decided to code it so that recordings marked Enc are not entered into the DLNA index, and therefore cannot be requested for streaming. It is unlikely that a software decryption process could keep up with the data rate.
I thought that the HDR-2000T is incapable of serving a DTCP-IP stream and that's why it doesn't serve high def. content? After Foxy treatment and moving the programme to a different location to get it re-indexed by the DLNA server, the content is then treated like it is standard def. - decrypted on the fly and served as a standard DLNA stream. Why did Humax remove the capability of DTCP-IP streaming? Is this to do with hardware or did they remove it from the software to save paying a licence fee for the technology?
 

Black Hole

May contain traces of nut
I thought that the HDR-2000T is incapable of serving a DTCP-IP stream and that's why it doesn't serve high def. content?
That may be the case, but whether it is actually incapable is unknown. How, exactly, it implements the "ban" is also a matter of supposition.
 
OP
MontysEvilTwin

MontysEvilTwin

Well-Known Member
That is an interesting point. Various ducks need to be lined up for the HDR-FOX - for example the server only indexes content on the HDD, and the HD-FOX doesn't have one. When you boot into HDR mode, can you then access Menu >> Settings >> System >> Internet Setting >> Content Sharing = On? If you can, does an external DLNA client detect the existence of a server?

The answers to these might help pin down where the blockage is.
On the HDR-FOX it is quite straightforward to get the DLNA server to index content on a USB disk drive, it just has to be mounted in 'My Video' (e.g. using the MVdisks package). In HDR mode on the HD-FOX there is no content share option available.
 

af123

Administrator
Staff member
You'd see the same if you shut down the Humax software on an HDR and then started it up again by hand. Many options would stop working, including the ability to record, and the Content Sharing menu item would be disabled and greyed out. HDR mode on the HD is just the same as this.
 
OP
MontysEvilTwin

MontysEvilTwin

Well-Known Member
You'd see the same if you shut down the Humax software on an HDR and then started it up again by hand. Many options would stop working, including the ability to record, and the Content Sharing menu item would be disabled and greyed out. HDR mode on the HD is just the same as this.
That's interesting. It is looking increasingly like my idea is pie in the sky but at least I am getting an idea of how it all works.
 

Black Hole

May contain traces of nut
On the HDR-FOX it is quite straightforward to get the DLNA server to index content on a USB disk drive, it just has to be mounted in 'My Video' (e.g. using the MVdisks package).
Yes, but there is a real existing file system to put a hard link in. On the HDR-FOX, the Humax firmware asks the OS for the content of the internal HDD and is given the content of My Video - including the external drive as if it were just a folder. The Humax firmware doesn't know the difference, and it will only ask about the internal HDD, nowhere else. To get over that one, the HDR-FOX firmware would have to be tweaked everywhere that it referenced the internal HDD to redirect it to a USB drive.

In HDR mode on the HD-FOX there is no content share option available.
So it probably "knows" the HDD partition is missing and blanks out the user option.

There is a lot to overcome to get the HDR code to offer a DLNA server on the HD-FOX, let alone 2000T code!
 

prpr

Well-Known Member
You'd see the same if you shut down the Humax software on an HDR and then started it up again by hand. Many options would stop working, including the ability to record, and the Content Sharing menu item would be disabled and greyed out.
Do we know why this is, and how the Humax software knows it has been restarted?
 
OP
MontysEvilTwin

MontysEvilTwin

Well-Known Member
I started this thread because I thought that the HD-FOX lacked a hardware component necessary to run the HDR-FOX DLNA server and wondered if there were a possibility that the HDR-2000T DLNA server might be compatible with the HD-FOX. From explanations on this thread, and a thread from a year ago (quoted in post #6), it seems that the likely stumbling block is the lack of an internal, SATA hard drive. I am still curious, but it seems that even if the HDR-2000T software could be made to run on the HD-FOX, it would offer no advantage.
If you disconnect the internal hard drive of a HDR-FOX, attached USB drives become inaccessible too. I noticed that if you do this, the content share option is still available and not greyed-out (obviously the DLNA server won't work without content to share). On the HD-FOX, even in HDR mode, the content share (and FTP server) options are simply not there. Is it possible that the DLNA server is not fully integrated into the Humaxtv process, but runs as a separate program? Presumably if it were a separate piece of software it could be located and extracted from the HDR-FOX update (HDF) file?
 

Black Hole

May contain traces of nut
It's good you keep coming up with ideas :)

Separate process? af will have to answer that one, but as far as I know humaxtv is one amorphous lump.

If you disconnect the internal hard drive of a HDR-FOX, attached USB drives become inaccessible too.
I didn't know that.
 

Black Hole

May contain traces of nut
I think your observations indicate that:
  • There are hardware differences between HDR-FOX and HD-FOX beyond the lack of a HDD;
  • HDR-FOX code is able to detect that it is running on different hardware and modify its behaviour;
  • At least elements of the code are common to HDR-FOX and HD-FOX and designed to adapt.
I do not understand why they would do this. Why have a "this is a HDR-FOX" hardware flag, when the issued code is distinct for HD-FOX and HDR-FOX? If there are common elements of source code that nonetheless need to have different behaviours according to the hardware, all they need to do is have a compiler directive and conditional compilation. Testing a hardware flag on execution is inefficient.

It would be interesting to have a BootHD Mode for the HDR-FOX (although only as academic curiosity), just to find out what happens.
 

Owen Smith

Active Member
Software developers probably originally planned one software image for HDR and HD Fox T2. Later they may have found this was awkward or not possible, or more likely Management dictated to the developers that they should split the software (this happens all the time, because Management are more often than not complete idiots on technical issues and won't take advice). Some auto hardware detection may have been left in after the split, no point changing code that works.
 
Top