Decryption very slow after recent update

[Ben B]

I'm a long-time user of the custom firmware and have been very happy for many years. However I received a couple of updates last night (webif and ir), and since then decryption has become painfully slow. For example, a 60 minute HD program has just taken 2.5 Hours instead of the previous 5 minutes or so.

auto.log has an entry that may provide a clue: "decrypt:system key doesn't match, trying direct" yet the encryption key shown on the diags page and in settings is the same as before.

I've downloaded a python script from these forums to do offline decryption, and now the plot thickens. After downloading the encrypted HD file onto my (Debian) system, vlc can play it with no problems, yet the DEC flag isn't set, nor do I have any autodecrypt flags set on the folder. It's almost as if the files are stored decrypted in the first place and, as might be expected, trying to decrypt the downloaded file results in it being unplayable in vlc.

I'm completely baffled ! Can anyone shed any light on what's happened, or provide a fix? (I'm happy to log in and use vim as required!) And yes, I've tried turning it off and on again ...

Web interface version: 1.4.9-6
Custom firmware version: 3.13 (build 4028)
Humax Version: 1.03.12 (kernel HDR_CFW_3.13)

 

[Ben B]

A bit more info:
Firstly, I should have mentioned that I have a HDR Fox T2.
Secondly, I should have mentioned that the files were sent to the queue for background processing rather than using the Opt+ menu option.

In an attempt to shed more light on the issue, I have used stripts on the humax cli to verify that the file was encoded, and the encryption key is correct for that file. I then downloaded it via the webif Opt+ download menu option, and it was saved as 40987.TS rather than the name on the hard disk and webif (World\'s\ Greatest\ Cars-s1e4.ts). This is strange new behaviour. Stranger still is that vlc plays this 'encrypted' file perfectly, and Mediainfo doesn't report anything wrong either.

Whilst it's true that I can seemingly access decrypted versions of my files more easily, the humax is bogged down with these background tasks and is unresponsive. I use auto ad-detection on many folders, so the queue is nearly always populated, and hence the box will always be preoccupied.

 

[prpr]

The file is obviously not encrypted if VLC can play it. The 40987.TS also implies it's been DLNA decrypted during download.
So the question seems to be: Why is it doing software decryption on box, rather that hardware decryption?
What does "nugget cryptokey" report from the command prompt? Does it match the key displayed elsewhere?

I struggle to see how either of those package updates could have caused this though, especially as they've been in beta for ages and no-one has reported anything like it.

 

[Ben B]

Thanks for the reply - I agree it really is baffling!

nugget says "Can't connect to nugget, No such file or directory." Is there something I should have installed first? (As I type, it is currently recording, and there are pending actions in the queue)

 

[Black Hole]

The first thing you need to do is verify the state of your HDD. If the file system is going flakey, all sorts of things can happen.

 

[Ben B]

The first thing you need to do is verify the state of your HDD. If the file system is going flakey, all sorts of things can happen.

Agreed. SMART says that everything is OK, and I last ran a full check a few months back with no problems. That said, it's in maintenance mode now doing a fixdisk, but as it's a 2TB drive it will take the rest of the night to complete.

What does "nugget cryptokey" report from the command prompt? Does it match the key displayed elsewhere?

After digging through the forums I found a user with exactly the same issue (https://hummy.tv/forum/posts/116055), and you suggested reinstalling nugget. I had the same two files missing, and the reinstallation & reboot has fixed nugget.
After all that, I can confirm that the cryptokey is correct. (I'm using the native key, not a custom key)

As something seems to have gone wrong somewhere, would it be worth simply reinstalling webif?

 

[/df]

New versions of WebIf have decryption code that I enhanced to try various keys. Without checking, I would guess that nugget being improperly installed could cause the decryption issue. It's meant to be a pre-req of WebIf.

 

[prpr]

As something seems to have gone wrong somewhere, would it be worth simply reinstalling webif?

Running the fix-flash-packages diagnostic and rebooting would seem to be a good idea. Reinstalling WebIf less so. I suspect a crash might have disabled certain things.
Then run the plugin_autodisable/off diagnostic (or do touch /mod/boot/no_plugin_autodisable from the command prompt) to stop it happening again.

 

[prpr]

you suggested reinstalling nugget. I had the same two files missing

Interesting. I wonder what causes that.
FWIW, I wrote a package checker script a few years ago that would identify packages with missing files like this.

 

[Ben B]

Running the fix-flash-packages diagnostic and rebooting would seem to be a good idea.

After getting a clean bill of health from fixdisk, I did a fix-flash-packages which seemed to reinstall everything (including webif). I've also touched the no_plugin_autodisable file.

I'd also done a DLNA reset earlier, so it took a couple of reboots for everything to stabilise, but now I've just decrypted a 60 minute HD file in ~7 minutes, which seems about right.

Interesting. I wonder what causes that.

I've had my HDR-FOX T2 for over a decade, upgraded the CF constantly, swapped its hard disk for a bigger version and seen it crash multiple times! I wouldn't know where to start working out where it went wrong ...

However, thanks to everybody for pointing me in the direction of a fix. And thanks to everybody for creating, documenting and maintaining this fabulous firmware; it's very much appreciated.

 

[RobH1]

Now, about that donation.......

 

[prpr]

I did a fix-flash-packages which seemed to reinstall everything (including webif)

It re-installs some things (those with components in the flash storage!).

I've just decrypted a 60 minute HD file in ~7 minutes, which seems about right.

Yep. Thanks for the feedback.

 

[Ben B]

Now, about that donation.......

A good point, well made!

 

[/df]

I had the same two files missing, and the reinstallation & reboot has fixed nugget.

The missing files as mentioned above:

First 2 files were missing. The force reinstall replaced them.

HDRFOX1# ls -l /mod/boot/2/libnugget.so.install
ls: /mod/boot/2/libnugget.so.install: No such file or directory
HDRFOX1# ls -l /mod/boot/bootstrap.d/xrts
ls: /mod/boot/bootstrap.d/xrts: No such file or directory
...

/mod/boot/2/libnugget.so.install is the hook module installed by the nugget package. At startup (xinit, before the settop program starts), it overwrites /mod/boot/2/libnugget.so, which is pre-loaded into the settop box address space.

/mod/boot/bootstrap.d/xrts is the real-time scheduling module.

I then downloaded it via the webif Opt+ download menu option, and it was saved as 40987.TS rather than the name on the hard disk and webif (World\'s\ Greatest\ Cars-s1e4.ts). This is strange new behaviour.

Is that still happening?

 

[Ben B]

Is that still happening?

No, everything is back to normal now with full file names being used. (Note that I did do a DLNA reset as part of my troublshooting, and so had to turn content sharing off and back on again as part of that process)

I can also confirm that those two nugget files are now there since I applied the above fixes.

As a further challenge I filled the queue with about 30 tasks, just to give it all a bit of a stress test during the day, and everything completed perfectly within expected times.