• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Enabling Folder or Recursive decrypt causes T2 to crash when processing is scheduled

K

Karl Prince

New Member
Hi, whilst I have had CF installed for years, it was only after a recent upgrade to a 4TB drive I became more aware of the capabilities, and started to use its features for other than large disk format.

I found that whilst I have been manually been able to decrypt files (using hardware/DNLA), but if I use the flag folder or recursive decrypt it crashes the box with the following recorded in the auto.log
A second question about decrypt, the _original folder gets created in the TS file folder, is there an easy way of cleaning these up I'm missing?

1752249933334.png
1752250509218.png
 
It is not currently set but had you set a custom encryption key yesterday when A&E After Dark was recorded?
Otherwise I cant explain the key doesn't match message? It shouldn't cause a system crash!

The _original folders are only created when the manual method is used, auto decrytion sends file to the dustbin if you have the undelete package installed
To clean up _original folders you could probably create a sweeper rule but that won't be needed once you figure out what is going wrong with auto decrypt.
 
MymsMan said:
It is not currently set but had you set a custom encryption key yesterday when A&E After Dark was recorded?
Otherwise I cant explain the key doesn't match message? It shouldn't cause a system crash!

The _original folders are only created when the manual method is used, auto decrytion sends file to the dustbin if you have the undelete package installed
To clean up _original folders you could probably create a sweeper rule but that won't be needed once you figure out what is going wrong with auto decrypt.
Click to expand...
I've never set the custom encryption key, and I was able to manually decrypt it OK after the scheduler attempt.

I should have noted that I have tried this in several folders, originally using recursive from root, which took me a little while to clear until I disabled auto whilst I learnt about the queue.

Auto logging is on debug level, and I can't find anything in any of the other logs from the WebIf
 
Be aware the box can occasionally (very occasionally) forget its key. Reboot sorts it. Anything you try to decrypt (including play) that was recorded before it forgot can't be accessed. Anything recorded while it forgot can't be accessed after you restore it.
 
Black Hole said:
Be aware the box can occasionally (very occasionally) forget its key. Reboot sorts it. Anything you try to decrypt (including play) that was recorded before it forgot can't be accessed. Anything recorded while it forgot can't be accessed after you restore it.
Click to expand...
The box has been power cycled numerous times, all the files I have tried to decrypt using "auto" have been accessible encrypted, and subsequently have able to be decrypted individually from WebIF
 
Karl Prince said:
The box has been power cycled numerous times, all the files I have tried to decrypt using "auto" have been accessible encrypted, and subsequently have able to be decrypted individually from WebIF
Click to expand...
Can you paste the messages produced by a succesful manual decryption in the hope that it might give some clue as to what is different from auto
 
Can you confirm this was recorded from 5STAR ?
Does it do this on every recording or only certain ones?
Are you au fait with the command line and entering commands manually and reporting the results?
 
prpr said:
Can you confirm this was recorded from 5STAR ?
Does it do this on every recording or only certain ones
Click to expand...
​
It was recorded on 5STAR, I've had it happen on several different recordings from different channels when I had it originally happen earlier this year, its only now I've been able to make time to be able to work proactively with the forums to investigate.​
If there is anything you want me to try particularly, like HD (seems like I should have thought of that already, though it different codecs rather then encryption), or particular channels let me know.​

prpr said:
Are you au fait with the command line and entering commands manually and reporting the results?
Click to expand...

I'm comfortable with command line, though several years since I've done unix/linux in anger​

Something I noticed after the crash (and after posting) is that the HDMI wasn't being picked up by my Panasonic BluRay/Amp, and I had to power cycle the Hummy to get it to work. Possibly a one-off (though the Panny seems sensitive to this for instance if select the media view as it selects the HDMI, it won't find it, a soft shut down power up of the Hummy resolves). Anyway may not be relevant, and I will explicitly check next time I instigate a crash.
 
Karl Prince said:
I'm comfortable with command line
Click to expand...
Can you run the jimsh interpreter at the command prompt (via telnet/ssh/webshell and the cli option) and then these commands and report output:
Code: 
source /mod/webif/lib/setup
require system.class
system nugget cryptokey
system encryptionkey
system customencryptionkey
exit
 
prpr said:
Can you run the jimsh interpreter at the command prompt (via telnet/ssh/webshell and the cli option) and then these commands and report output:
Code: 
source /mod/webif/lib/setup
require system.class
system nugget cryptokey
system encryptionkey
system customencryptionkey
exit
Click to expand...

Running nugget cryptokey caused a system crash

. system encryptionkey
dcd32156b2f636333731303531353830
. system customencryptionkey
.

Is there a different onerror handler for WebIF versus auto? whilst not the root cause, it would explain the different outcomes?
 
Karl Prince said:
Running nugget cryptokey caused a system crash
Click to expand...
This leads me to suspect that if you set the custom encryption key to be the same as the native key might give you a workaround
But it doesn't explain the system crash - you cant be the only user who has never set a custom encryption key!

With and without custom key
Code: 
. system nugget cryptokey
Native key: dc d3 21 17 86 cf 36 33 37 31 30 34 39 35 32 30
Using key:  33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
. system customencryptionkey
33333333333333333333333333333333
. system nugget cryptokey
Native key: dc d3 21 17 86 cf 36 33 37 31 30 34 39 35 32 30
Using key:  <no custom key in use>
. system customencryptionkey
.

BTW does nugget cryptokey also cause a crash when issued from command line (not in jimsh), what does nugget status show
 
Last edited:
prpr said:
Interesting. Are all your packages up to date?
Is there a particular reason you are running Humax firmware 1.02.20 rather than 1.03.12 ?
Click to expand...
Packages are up to date
Firmware version is probably what I installed originally, or possibly at the last disk upgrade, hadn't occurred for me to have to check as the package management is so efficient, assumptions are dangerous.
I'll look into how to uograde and get back with the outcome.
 
Presume you've already done the obvious i.e. run fixdisk in maintenance mode, and done a diag fix-flash-packages and then rebooted.
 
prpr said:
Interesting. Are all your packages up to date?
Is there a particular reason you are running Humax firmware 1.02.20 rather than 1.03.12 ?
Click to expand...
I've upgraded the Humax firmware to 1.03.12, which has resolved the issue (and another one with writing to large USB drives).
I think I went for that version several years ago due to the unattended retuning issue with the later version, then forgot/missed that there were upgrades subsequently.

FYI This is my fourth disk drive, two changed due to failures, and recently just to get more disk space which is when I really found out CF was a lot more than large disk support.

Thank you for all your help, feel about annoyed at myself for missing it, especially as I went to the trouble to post the version details from the diag page.
 
MymsMan said:
This leads me to suspect that if you set the custom encryption key to be the same as the native key might give you a workaround
But it doesn't explain the system crash - you cant be the only user who has never set a custom encryption key!

With and without custom key
Code: 
. system nugget cryptokey
Native key: dc d3 21 17 86 cf 36 33 37 31 30 34 39 35 32 30
Using key:  33 33 33 33 33 33 33 33 33 33 33 33 33 33 33 33
. system customencryptionkey
33333333333333333333333333333333
. system nugget cryptokey
Native key: dc d3 21 17 86 cf 36 33 37 31 30 34 39 35 32 30
Using key:  <no custom key in use>
. system customencryptionkey
.

BTW does nugget cryptokey also cause a crash when issued from command line (not in jimsh), what does nugget status show
Click to expand...
I did try the workaround, but the interface doesn't let you set the custom key to be the same as the native key.

I didn't get to try running nugget from the native shell, as I then upgraded the firmware as prpr suggested, which then resolved the issue.

Thanks for your assistance.
 
Interesting. You were running reasonably up-to-date CF despite it being on top of older Humax firmware.

@prpr: do you think 3.13 vs 3.14 was the problem, or 1.02.20 vs 1.03.12?
 
Black Hole said:
do you think 3.13 vs 3.14 was the problem, or 1.02.20 vs 1.03.12?
Click to expand...
The latter. I presume he's still on 3.13 as he hasn't said otherwise.
I might try loading 1.02.20 on a spare machine when I get back to one, just out of curiosity. I can't see there's going to be a fix though.
 
You must log in or register to reply here.
Back
Top