[unencrypt] Decrypt-in-place

The only other option is to run unencrypt on ALL files, This is possible and it will unencrypt up to 48 files per day if not in standby
 
That was going to be my suggestion - why make things complicated? I leave mine running to unencrypt EVERYTHING - don't see any reason not to?

That way I am pretty certain that I can move/copy a file wherever I like and it should play/burn to disc etc - as long as I remember to leave a "breathing space" so anything recent has had a chance to be processed.
 
Jeremy said:
Oh dear, something is broken - it won't uninstall. I just got very cold feet - opting out and back to the standard firmware. Thanks anyway.
Click to expand...

Hi Jeremy,

The current version of unencrypt only runs overnight. This was because of some stutters and other issues that I found on my own box at home and running the decryption overnight has definitely improved the situation. Even then, it should be able to decrypt 12 files overnight, which is enough for most people.

I wrote the setup script to only work with one directory because I reasoned that most people would want to test it in a single directory and then to run it for all programmes. If there is a demand for multiple directories, I will see if I can find a way of doing it that's simple to set up.

You mentioned that you were having problems removing it - the command "opkg remove unencrypt" should do it for you. Let me know if that doesn't work.
 
Ezra Pound said:
The point of unencrypt (I think) is to setup a single special directory and then move files into it after they are recorded using the remote control's OPT+
Click to expand...

That wasn't the intention - you could do that, but the ability to work on a subdirectory is so that people can take the program for a test-drive before risking your significant other's precious recordings of Britain's Got Strict Big Brothers.
 
I have got around to installing unencrypt, and with my quality-control hat on I am perplexed as to why I have had to telnet in and type "unencryptsetup". I imagine it could have been done on the WebIF diagnostics entry form, but why don't the WebIF settings handle it?

On a general package management note, it would be nice if installations that require a reboot afterwards told you so in the pop-up progress window, and maybe even offered to do it for you.
 
You would be better adding those as requests onto the webif thread (and for clarification, unencrypt doesn't need a reboot).

Let me know how you get on with unencrypt though, I await your feedback with interest.
 
I decided to make a safety OPT+ copy/decrypt to NTFS of about 130GB, but after 15 hours it's done 80GB - I've turned off unencrypt for the time being in case it conflicted.

I'm sure AF reads it all, but I will mention it again when the opportunity arises.
 
All going well - unencrypt was allowed to run for the first time last night, and rifling my files this morning I have found a dozen with a "Dec" icon and an "extract audio" option. It's going to take a while at this rate - maybe I should adjust the cron settings so it runs every 20 mins from 2am to 4pm for the first blitz (instructions how to do that would be handy, but I'm sure I can work it out if I read back).

Once I get the network shares established I will blog the process.
 
Black Hole said:
All going well - unencrypt was allowed to run for the first time last night, and rifling my files this morning I have found a dozen with a "Dec" icon and an "extract audio" option. It's going to take a while at this rate - maybe I should adjust the cron settings so it runs every 20 mins from 2am to 4pm for the first blitz (instructions how to do that would be handy, but I'm sure I can work it out if I read back).

Once I get the network shares established I will blog the process.
Click to expand...

That's good news.

Are you happy editing files? If so, edit /mod/bin/unencryptsetup and change the line that starts "cronline=...." to reflect your new timings and then rerun unencryptsetup.
 
After running the first unencrypt overnight I then switched it to run every half hour (24/7) and haven't noticed any stuttering. We don't record a massive amount (soaps, being the most common).
 
It should be OK, I had a test running of about five different HiDef real-time read or write streams to the hard disk going on simultaneously, and only got a problem when I added uncontrolled bulk operations as well. The decrypt sends a stream through the normal DLNA channel, so it should not load things unduly.

However, there's no telling what it will do to my AR!
 
I've decided to run it every 5 minutes continuously - I believe if it's still busy from the last one it will ignore the next invocation, and if there's nothing to do it won't spend long checking so it should not slug the system. What I don't know is what happens if I kill the system while a decrypt is running: will it patch up next time?
 
Regarding the log, I think it would be better to show progress by actual system time rather than an ETA count-down (the percentage complete is good enough for that). With the system time we could see how long it actually took, and when it ran.
 
Black Hole said:
I've decided to run it every 5 minutes continuously - I believe if it's still busy from the last one it will ignore the next invocation, and if there's nothing to do it won't spend long checking so it should not slug the system. What I don't know is what happens if I kill the system while a decrypt is running: will it patch up next time?
Click to expand...

The decrypted file is downloaded and then renamed to overwrite the original at the same time as the HMT command is being run. There is a tiny window during which there would be a problem and that is the time it takes to run HMT and for it to run the file. The only way of improving that would be to copy the hmt file and then run HMT and copy both, but that will probably only drop the window from about 3ms to about 1ms.
 
Black Hole said:
Regarding the log, I think it would be better to show progress by actual system time rather than an ETA count-down (the percentage complete is good enough for that). With the system time we could see how long it actually took, and when it ran.
Click to expand...

The log is a bit long, indeed. I'll look at tweaking it and then only turning on the current format of log when debugging is enabled.
 
Regarding the log again, I like what it says but wish it was more readable. I was thinking of having a look at this myself but really it would be (yet another) distraction from more important matters.

Here's the start of my log:

Code: 
>>> Contents of /mod/tmp/unencrypt.log 27.24 KiB Processing "My Video/I'm Sorry I Haven't a Clue/I'm Sorry I Haven't a Clue_20110704_1229", Media ID is 4 Processing
"My Video/I'm Sorry I Haven't a Clue/I'm Sorry I Haven't a Clue_20110623_0229", Media ID is 5 Processing "My Video/I'm Sorry I Haven't a Clue/I'm Sorry I Haven't a
Clue_20110109_1159", Media ID is 6 Processing "My Video/I'm Sorry I Haven't a Clue/I'm Sorry I Haven't a Clue_20110622_0929", Media ID is 7 Processing "My Video/I'm
Sorry I Haven't a Clue/I'm Sorry I Haven't a Clue_20110102_1159", Media ID is 8 Processing "My Video/I'm Sorry I Haven't a Clue/I'm Sorry I Haven't a
Clue_20110704_2159", Media ID is 9 Processing "My Video/I'm Sorry I Haven't a Clue/I'm Sorry I Haven't a Clue_20110130_1159", Media ID is 10 Processing "My Video/I'm
Sorry I Haven't a Clue/I'm Sorry I Haven't a Clue_20110704_1829", Media ID is 11 Processing "My Video/I'm Sorry I Haven't a Clue/I'm Sorry I Haven't a
Clue_20110116_1159", Media ID is 12 Processing "My Video/I'm Sorry I Haven't a Clue/I'm Sorry I Haven't a Clue_20110706_0929", Media ID is 13 Processing "My Video/I'm
Sorry I Haven't a Clue/I'm Sorry I Haven't a Clue_20110206_1159", Media ID is 14

and what I would really like it to say is:

Code: 
>>> Contents of /mod/tmp/unencrypt.log 27.24 KiB
05/02/2012 03:31 Processing "My Video/I'm Sorry I Haven't a Clue/I'm Sorry I Haven't a Clue_20110704_1229", Media ID is 4 - 0.85GB 1m55s Complete
05/02/2012 04:01 Processing "My Video/I'm Sorry I Haven't a Clue/I'm Sorry I Haven't a Clue_20110623_0229", Media ID is 5 - 0.87GB 1m56s Complete
etc

Anyway, I now have a fully decrypted set of recordings, and I'm ready to move on to network sharing (despite the "split" function).
 
Are you having problems with formatting - there are linefeeds on your example but not in the original.

The timing info wouldn't be relevant as it only decrypts once per run.However, I think that there may be good reason to have a bulk-decrypt version that just works its way through the disk, one file after another (that's basically what progbackup does anyway) because most people who want to start decrypting are already likely to have content on their boxes.
 
Linefeeds: the "original" is as I see it in the WebIF diagnostics log display - no line breaks. (Actually, I put some in to show where the wrap appears.) Is that the fault of the WebIF output or the log file? I notice it is common to all the log displays I have looked at so perhaps it is something to do with the WebIF. I have mentioned it. Perhaps it's something to do with Internet Explorer and Firefox/Safari/Chrome users don't know what I've been ranting about.

Timing info is relevant (to me) because I would like to see which file was processed on which run. Now I have cleared the backlog, files will be processed only after they get recorded and then added to the database, so even more I would like to see when they get picked up and dealt with. How long each one actually took to process (rather than a guestimate count-down) is also interesting information.

I don't see any problem with "bulk decrypt" - that's what I did with every 5 minutes 24/7, and I see no reason to move from that schedule now.
 
Black Hole said:
You've got a malformed quote there.

Linefeeds: the "original" is as I see it in the WebIF diagnostics log display - no line breaks. (Actually, I put some in to show where the wrap appears.) Is that the fault of the WebIF output or the log file? I notice it is common to all the log displays I have looked at so perhaps it is something to do with the WebIF. I have mentioned it. Perhaps it's something to do with Internet Explorer and Firefox/Safari/Chrome users don't know what I've been ranting about.

Timing info is relevant (to me) because I would like to see which file was processed on which run. Now I have cleared the backlog, files will be processed only after they get recorded and then added to the database, so even more I would like to see when they get picked up and dealt with. How long each one actually took to process (rather than a guestimate count-down) is also interesting information.

I don't see any problem with "bulk decrypt" - that's what I did with every 5 minutes 24/7, and I see no reason to move from that schedule now.
Click to expand...

The quote should be fixed now - Ta.

The linefeeds are a Webif issue, something else for Af123's to-do list ;)

The only file listed is the one that is processed, all other lines refer to files that have already been decrypted. There's no harm in adding a decryption time to the log info, though, anyway.
 
You must log in or register to reply here.
Back
Top