[BootHDR] A method of decrypting recordings on the HD-FOX T2

Powered the box off at the mains this morning. Box now behaving normally.

I have tried to repeat the error using the remote method without success, but when switched into stand-by, the Humax appears to be off, (red light and no HDD activity) but the front window still shows a symbol, looks like a 1.
I have 'Power saving in Stand-by' set, so no clock.
 
I seem to recollect reading somewhere that there can be ‘hardware handshake’ issues with HDCP between devices, depending on which is active first. It would appear that the reboot from power off has resolved the problem.

I agree with Drutt regarding the fact that bootHDRmode is merely executed via a different method.

However, having spent some time analyzing and fixing the problem, I’m a bit reluctant to go to a new version. At the moment it works via the remote and works well, so I think I’m aligned with the “if it ain’t broke, don’t fix it !” brigade – well at the moment anyway ! :)
 
aber1 said:
I agree with Drutt regarding the fact that bootHDRmode is merely executed via a different method.
Click to expand...
It's the method of getting back to HDmode that's different. Rebooting via Telnet is similar to rebooting from Webif to schedule a recording. The box doesn't go into Stand-by. Switching off with the remote does switch the box off but leaves the symbol on the front screen, which on closer inspection is like an opening square bracket ([) probably part of the 'chasing snake' we see at start-up.
It may be be peculiar to my system so I will let matters lie, unless it is reported by others.
 
4291 said:
It may be be peculiar to my system so I will let matters lie, unless it is reported by others.
Click to expand...

The HDR software doesn't talk to the display on the HD so once you're in HDR mode the display remains fixed - usually showing the last chanel you were on - even when you go back to standby. Doing a normal boot cycle in HD mode sorts that out.
 
aber1 said:
However, having spent some time analyzing and fixing the problem, I’m a bit reluctant to go to a new version. At the moment it works via the remote and works well, so I think I’m aligned with the “if it ain’t broke, don’t fix it !” brigade – well at the moment anyway ! :)
Click to expand...

If you fancy having both ways available, the old reboot method is still available in the new package - I just commented out the creation of the "onNextReboot" flag in the startup script. Comment that line back in and you have the choice :)
 
4291 said:
It's the method of getting back to HDmode that's different. Rebooting via Telnet is similar to rebooting from Webif to schedule a recording. .
Click to expand...

Not sure I understand - how are you rebooting back to HD mode via telnet? I would recommend going back to HDmode with a normal standby cycle from the remote.

4291 said:
Switching off with the remote does switch the box off but leaves the symbol on the front screen, which on closer inspection is like an opening square bracket ([) probably part of the 'chasing snake' we see at start-up.
Click to expand...

Its not just you - it's always done that, and not just in the new package (for the reason af123 mentioned). It sorts itself out next time you go into HD mode.
 
Drutt said:
If you fancy having both ways available, the old reboot method is still available in the new package - I just commented out the creation of the "onNextReboot" flag in the startup script. Comment that line back in and you have the choice :)
Click to expand...

Apologies for the delay in replying. Thank you for that and I will look at doing it as soon as possible.
 
Drutt said:
Not sure I understand - how are you rebooting back to HD mode via telnet?
Click to expand...
I just type 'reboot' at the Humax# prompt. The Humax then starts up again with no further intervention from me.
Both methods of getting into HDRmode work for me. Using Telnet to reboot is neater.
I use iTelnet on my iPad, so no need to go upstairs like some have to do to use their PCs. All done from the armchair. :)

The HDMI handshake problem has not recurred, so I put that down to a hiccup.

Thanks again for fixing the Remote control method.
 
BlackCat3000 said:
Ok, just had bootHDR working from telnet and remote on CF1.14 after a manual installation of bootHDRmode.
Upgraded to CF1.15 and then bootHDRmode failed to work, causing the box to freeze.
Flashed back to CF1.14 and bootHDRmode works again from telnet and remote.
No other changes were made.

So, my experience leads me to believe that CF1.15 somehow breaks existing installations of bootHDRmode. I was unable to perform a new installation of bootHDRmode under CF1.15 either, but unlike Climber (who succeeded in this) I'm not in a position to reformat the disk and do a clean installation.

Unfortunately, I know too little about Linux to begin to work out what's going wrong.
Click to expand...

My experience with HDR mode has been the same as BlackCat3000. Everything I have tried on CF 1.15 resulted in the picture freezing. As soon as I flashed to CF 1.14 with the same HDD software installation HDR mode works. I wonder what differences are between CF 1.14 and 1.15 that could cause this and why do some boxes on CF 1.15 work and some don't?
Well at least now I can decrypt my recordings :)
 
got the script installed and working from the remote like a champ. Now my question is how do I go about setting this up to boot into HDR mode at 4am and then copying all videos from the PVR on the virtual disk or a mounted NAS drive then to reboot back into HDmode for normal PVR functions?

Yes I know I will need a script and to stick it into init.d just really need a kind soul to help with the script has its out of my league (I think).
 
Only the opt+ copy method of decrypting works so its pretty hard to automate :( It might be useful to make a script that at least puts all the files that need decrypting in one place so they can be copied/decrypted in one go...
 
This now fails to install since Humax reorganised their website. Version 1.2.20 of the standard HDR firmware is no longer available and the links to newer versions are redirected to a secure site.
 
Feature request: I sggest adding a pre-installation script (preinst) to ensure that BootHDR can only be installed on the HD model. Something like the following should work:
Code: 
#!/bin/sh

if [ "`cat /etc/model`" != "HD" ]; then
        echo "This package can only be installed on the HD model."
        exit 1
fi
 
In order to answer a question from a certain telephone number of my acquaintance, I installed bootHDR on one of my HDRs. Clearly it does not have the lock-out suggested by xyz321 above. As it happens I could have got the answer if I had looked more diligently through this topic - post 134 contains what I wanted to know.

My question is how to clean up again. Will uninstalling bootHDR remove everything? If so, how does the removal account for dependencies also being required for other installed packages? The installation dialogue mentions humidify, squashfs-tools, and wget - obviously decryption depends on wget so I wouldn't want to delete that.

Incidentally, the dialogue is still "processing" a considerable time later. I think I will have to kill it.
 
I think the the removal process will only remove the package and not its dependencies. It will definitely not remove any shared dependencies with other packages.

When removing bootHDR you may be left with additional files which have been downloaded by the package itself e.g files in /mod/HDRfs.
 
When installing BootHDR on a HD-FOX, the installation appears to hang. If you cancel, eventually you get a another dialogue box pop up. Click OK to close this. The installation does work. To remove, on a HD-FOX, uninstall as standard through package management. The initial installation creates the folder HDRfs (and its contents) in the /mod folder: this is not deleted when the package is removed. I delete this folder, using Web-If, to finish off the uninstall. I don't know what happens on a HDR-FOX as you will already have a HDRfs folder. On the HD-FOX, these files are installed on /drive1. If you had USB drive attached when you installed did it create the HDRfs folder on the external drive?
 
xyz321 said:
I think the the removal process will only remove the package and not its dependencies. It will definitely not remove any shared dependencies with other packages.

When removing bootHDR you may be left with additional files which have been downloaded by the package itself e.g files in /mod/HDRfs.
Click to expand...
I'm pretty sure I don't need humidify or squashfs-tools for anything else, and their info buttons suggest only bootHDR is using them (in my installation). Correct, uninstalling bootHDR did not remove any dependencies.

Curiously, wget only lists bootHDR, so does that mean it is not needed for WebIF decryption after all?

The info list of packages that depend on a particular package is useful, but it would also be useful if it listed the packages that it depends on.
 
You must log in or register to reply here.
Back
Top