HD-FOX Decryption - Plugin Failure

Status
Not open for further replies.

Black Hole

May contain traces of nut
Queueing decryption on HD-FOX, I'm getting Status = "FAILED", Log = "Plugin Failure".

The following lines appear relevant in auto.log:
Code:
19/03/2021 22:03:02 - De-queuing 45 - decrypt - /media/drive1/Video/Star Trek_ Enterprise/Star Trek_ Enterprise_20210318_1900.ts
19/03/2021 22:03:03 - decrypt:  DECRYPT: /media/drive1/Video/Star Trek_ Enterprise/Star Trek_ Enterprise_20210318_1900
19/03/2021 22:03:03 - decrypt:  Direct decryption
19/03/2021 22:03:03 - decrypt:::decrypt::dequeue: /mod/etc/keys: No such file or directory
19/03/2021 22:03:03 - decrypt:    /mod/webif/lib/ts.class:877 @
19/03/2021 22:03:03 -     -1 -  -
19/03/2021 22:03:03 -    Plugin failure

/mod/etc/keys: No such file or directory - what's that all about? Right enough, there's no such file or directory, but I'm sure I've done this before successfully.

Settings shows this:
1616192134064.png
 
Last edited:
Yes, I had this too yesterday but haven't had time to investigate:
Code:
18/03/2021 17:31:03 - decrypt:::decrypt::dequeue: /mod/boot/cryptokey: No such file or directory
18/03/2021 17:31:03 - decrypt:    /mod/webif/lib/ts.class:859 @
18/03/2021 17:31:03 -     -1 -  -
18/03/2021 17:31:03 -    Plugin failure

Looks like one for @/df I think.

Executing:
Code:
humax# touch /mod/etc/keys
humax# touch /mod/boot/cryptokey
makes it work.
 
Last edited:
This would appear to fix it:
Diff:
humax4 /media/drive1/mod/webif/lib # diff -u ts.class~ ts.class
--- ts.class~
+++ ts.class
@@ -855,15 +855,13 @@
        }
        if { $mode ne "dlna" } {
                # also try other keys, such as this - same as active?
-               try {
-                       set fd [open "/mod/boot/cryptokey"]
+               if {![catch {set fd [open "/mod/boot/cryptokey"]}]} {
                        set bytes [$fd read 16]
                        binary scan $bytes H* key
                        if {[string length $key] == 32} {
                                ladd keys $key
                        }
-               } finally {
-                       catch {$fd close}
+                       $fd close
                }

                # the native key
@@ -873,13 +871,11 @@

                # support a file listing other keys in hex, one-per-line
                # eg, for recordings imported from a broken box
-               try {
-                       set fd [open "/mod/etc/keys" r]
+               if {![catch {set fd [open "/mod/etc/keys"]}]} {
                        foreach key [split [$fd read -nonewline] "\n"] {
                                ladd keys $key
                        }
-               } finally {
-                       catch {$fd close}
+                       $fd close
                }
        }
 
Last edited:
Or actually this is a bit simpler: https://git.hpkg.tv/hummypkg/webif/pulls/43

Apparently (as I thought I posted earlier, but no sign of it), TCL try doesn't actually trap errors unless it's given a handler, even a trivial one as in the above PR.

I have /mod/boot/cryptokey everywhere. Perhaps it only appears if you've set a custom key.

The optional file /mod/etc/keys was invented to allow s/w decryption of recordings imported from other boxes. Maybe you imported recordings from various other boxes but forgot to decrypt them. If the keys that were in use on each other box are listed in the keys file, they can still be decrypted.

This thread seems to have migrated but it's not a firmware issue, just Webif-1.4.9-3 beta.
 
Last edited:
This thread seems to have migrated but it's not a firmware issue, just Webif-1.4.9-3 beta.
I asked for it to be moved; from what prpr said I understood the problem as being a beta-tester one but got the target wrong. I'll ask for another relocation.

I have /mod/boot/cryptokey everywhere. Perhaps it only appears if you've set a custom key.
But I have a custom key set (see post 1), and I do have /mod/boot/cryptokey (I didn't go looking for it before) so that element of prpr's work-around doesn't look as if it's needed.

The optional file /mod/etc/keys was invented to allow s/w decryption of recordings imported from other boxes. Maybe you imported recordings from various other boxes but forgot to decrypt them.
I doubt it. But prpr's test seems to imply the existence of even an empty /mod/etc/keys is sufficient to overcome the problem.

Wouldn't it be an easier solution simply to ensure the relevant files exist by installation?
 
Last edited:
I wasn't clear enough. By "you" I meant a hypothetical CF user who might be in the multi-box scenario.

There's no need to rely on files (that might be deleted at any time) being present if the idiot programmer could keep two programming language syntaxes in his head for long enough to get the code right ... Anyhow, all should be good in the non-beta version. Perhaps @af123 will roll up the two remaining PRs (including the fix for this) into a 1.4.9-4 before then.
 
Last edited:
Status
Not open for further replies.
Back
Top