HD-FOX Decryption - Plugin Failure

[Black Hole]

Queueing decryption on HD-FOX, I'm getting Status = "FAILED", Log = "Plugin Failure".

The following lines appear relevant in auto.log:

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:

 

[prpr]

Yes, I had this too yesterday but haven't had time to investigate:

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:

humax# touch /mod/etc/keys
humax# touch /mod/boot/cryptokey

makes it work.

 

[prpr]

This would appear to fix it:

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
                }
        }

 

[/df]

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.

 

[Black Hole]

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?

 

[prpr]

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

This is true. The file doesn't exist unless/until you set a custom key.

 

[Black Hole]

touch /mod/etc/keys sorted my problem and got everything moving.

 

[/df]

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.

 

[prpr]

if the idiot programmer could keep two programming language syntaxes in his head for long enough to get the code right

It's hard remembering the differences between C++, Javascript, PHP, Jim. Gets me all the time. The only one I can rely on for syntax, without checking, is C++.