Unencrypt vs Webif with Decrypt

sceptic

Forum Supporter
Now its possible to flag the top level media directory for a recursive decrypt, webif decrypt can be used as an alternative to unencrypt. What are the various pros and cons? Unencrypt runs as a cron job under the users control, does decrypt just run whenever the box is on? Is that likely to cause any issues overloading the box if multiple recordings are going on or is it able to detect this and suspend its operation until they complete?
 

Black Hole

May contain traces of nut
I run unencrypt all day every day (in reality it kicks in within 5 minutes of a new recording being added to the DLNA index), and not suffered any problems because of it. The default cron schedule for unencrypt runs it overnight because a cautious approach was taken at the time; recursive auto-decrypt is offered now only because of the experience with unencrypt.

Auto-decrypt runs whenever a recording is found in a flagged folder that conforms to the conditions required: StDef or auto-unprotected HiDef, DLNA indexed, and not already decrypted. In practical terms that means as soon as the indexer adds it to the database (which can be some time after the recording completes).

Will I switch from unencrypt to recursive auto-decrypt? I've not decided yet. The reason I decrypt as a matter of course is for access to recordings using the HDR-FOX as a NAS (rather than a DLNA server). Unless you do this (or require FTP access to recordings, or stream them by Mediatomb instead of the standard DLNA server), there is little need to decrypt on a routine basis. Pre-decrypted recordings do offer a speed advantage when copying out to USB.

The only thing I have had to remove because of recording problems is sysmon, which is believed to be because I have latent disk problems that sysmon interacts with.
 

af123

Administrator
Staff member
The web interface version has a number of advantages over the unencrypt package although both will do the job nicely.
  • It is actively maintained and I believe the code to be more robust - it has many more sanity checks in it than unencrypt and takes care to minimise the times when going into standby can cause issues such as files being left lying around. It has undergone specific testing to confirm that it can recover from unexpected shutdown (standby);
  • It is more flexible as you can selectively flag folders and folder trees for decryption;
  • Works by scanning the disk for files to convert (unencrypt scans the DLNA database which doesn't scale as well as the number of recordings increases);
  • No CLI configuration and optional cron table editing required.
The advantage of unencrypt is that it gives you more control over the scheduling although something similar could be done by changing when the web interface automatic processing task is launched - that's from cron too.

I'm not intending to knock unencrypt - it's been around a while and is used by a lot of people without any problems.
 
OP
sceptic

sceptic

Forum Supporter
Thanks for that af123. You confirmed what I suspected in point 1 so I think I'll also be making the switch!
 

lstar337

Member
Is bullet one suggesting that unencrypt is no longer being developed/maintained by the author?

I have been eating through the unencrypt thread when I have spare minutes, but I have only got to page 14. If unencrypt is no longer being maintained, then I'll stop reading now and just use the webif.
 

Black Hole

May contain traces of nut
I think this is your best choice now.

The same conditions are necessary: anything to be decrypted must be present in the DLNA database, Content Sharing must be set to "on" in the Humax Internet Settings, and for HiDef recordings to be decrypted the autounprotect package must be running. The database indexing is performed as-and-when by the Humax, we have no control over it.
 

af123

Administrator
Staff member
Is bullet one suggesting that unencrypt is no longer being developed/maintained by the author?

Unencrypt was written by Sam Widges who hasn't posted here in a long time. The last version of unencrypt was 0.1.4, a year ago.
 
OP
sceptic

sceptic

Forum Supporter
Since making the switch over to recursive decrypt I find that my box seems really sluggish, especially when opening up the media list. This happens even if no recordings are going on and all programs are decrypted. I also see some errors in the log like this one. It also seems to be decrypting items it has put into [Deleted Items]\webif_autodecrypt, is that correct? I think it would be nice if the Deleted Items could be excluded from the process and the auto_decrypt copy cleared down once the decrypt was completed OK...

Runtime Error: /mod/webif/lib/bin/auto:143: Connecting to 192.168.1.200:9000 (192.168.1.200:9000)
wget: cannot connect to remote host (192.168.1.200): Connection refused
in procedure 'scan' called at file "/mod/webif/lib/bin/auto", line 276
in procedure 'scan' called at file "/mod/webif/lib/bin/auto", line 263
in procedure 'scan' called at file "/mod/webif/lib/bin/auto", line 263
in procedure 'scan' called at file "/mod/webif/lib/bin/auto", line 263
in procedure 'decrypt' called at file "/mod/webif/lib/bin/auto", line 259
in procedure 'entries' called at file "/mod/webif/lib/bin/auto", line 236
in procedure 'do_decrypt' called at file "/mod/webif/lib/bin/auto", line 225
at file "/mod/webif/lib/bin/auto", line 143
 

Black Hole

May contain traces of nut
It should be the pre-decrypted items that end up in the recycle bin, as per deletion policy with undelete installed.

If your system is sluggish, it could be that the additional disk usage has exposed some disk problems. Do you get any glitches in HiDef recordings?
 
OP
sceptic

sceptic

Forum Supporter
I've not noticed any glitches. Usually the media list takes a couple of secs to open. When its sluggish it can take 10-15 secs. I have 278 recordings on the HDD.

I thought it was decrypting because of this:-

ECRYPT: [/media/My Video/[Deleted Items]/webif_autodecrypt/Borgen]
DECRYPT: /media/My Video/[Deleted Items]/webif_autodecrypt/Borgen/Borgen_20130126_2200
DLNA: http://192.168.1.200:9000/web/media/521.TS
Runtime Error: /mod/webif/lib/bin/auto:143: Connecting to 192.168.1.200:9000 (192.168.1.200:9000)
wget: cannot connect to remote host (192.168.1.200): Connection refused
in procedure 'scan' called at file "/mod/webif/lib/bin/auto", line 276
in procedure 'scan' called at file "/mod/webif/lib/bin/auto", line 263
in procedure 'scan' called at file "/mod/webif/lib/bin/auto", line 263
in procedure 'scan' called at file "/mod/webif/lib/bin/auto", line 263
in procedure 'decrypt' called at file "/mod/webif/lib/bin/auto", line 259
in procedure 'entries' called at file "/mod/webif/lib/bin/auto", line 236
in procedure 'do_decrypt' called at file "/mod/webif/lib/bin/auto", line 225
at file "/mod/webif/lib/bin/auto", line 143
 
OP
sceptic

sceptic

Forum Supporter
It also have some entries like this in my log:-

DECRYPT: [/media/My Video/[Deleted Items]/webif_autodecrypt/[Deleted Items]/webif_autodecrypt/FA Cup Replay Highlights]
 

af123

Administrator
Staff member
The recursive functions do seem to be going down into the dustbin and they definitely shouldn't!
That definitely needs fixing (update will by out shortly) but should the recursion break for any special directory (i.e. one that has a name starting with a [ character)? I don't think it should.
 

af123

Administrator
Staff member
webif 0.11.0-2 just released that stops the recursive automatic functions from applying to any files which are in the bin.
 

Black Hole

May contain traces of nut
should the recursion break for any special directory (i.e. one that has a name starting with a [ character)? I don't think it should.

I thought we had agreed all folders beginning "[" are to be immune from global operations. Somebody wanting to break this rule can set specific processing for that folder. (Anyone aware of this rule is specifically using the "[" to protect a folder from processing.)

The recycle bin falls into this category.
 
OP
sceptic

sceptic

Forum Supporter
Thanks af123, that was quick! For me files deleted by the recursive decrypt process should not end up in the dustbin as the source files are still on the HDD in decrypted form. It the user then manually deletes them then of course they should end up in the dustbin.
 

Black Hole

May contain traces of nut
It's a safety net - there is a (slight) risk of transcription error during decryption (or shrink, or conversion to mpg).
 
OP
sceptic

sceptic

Forum Supporter
Ah I see. I thought perhaps that if the decrypted file size was the same as the encrypted file size then it would be safe to delete it...

Any ideas what is the cause of those connection refused errors in my log?
 
Top