Safe to auto-decrypt and auto-shrink My Video?

john.robinson

New Member
Hello all! I've recently installed the custom firmware and I'm really pleased with it. Congratulations and many, many thanks to everyone involved in putting it together!

Since my HDR-T2's 1TB disc was getting full, I've been experimenting with auto-decrypt and auto-shrink, so I can copy movies off to another media server on my LAN and save a bit of space respectively, and it's working well.

Is there any reason I shouldn't set auto-decrypt and auto-shrink on my whole "My Videos" folder?
 
No reason but it won't propagate down to any sub-folders. You can unencrypt the whole disk with the unencrypt package.
 
Well that's good news and bad. I've got a lot of files - over 200 - which means loading the Browse page from my browser takes 20 seconds even when the box isn't decrypting or shrinking anything, and I have a lot of folders - about 40 - and every time I click OPT+ Auto-decrypt or OPT+ Auto-shrink, the Browse page reloads, so it's going to take a while to work through them all. Now if only turning those settings on and off didn't need a full page reload, hint hint ;) - naah that's not fair, I'm sure you have better things to be working on and really I'm grateful to have the facility at all! :cool: Oops too many smileys :oops:
 
You just need to create a file in each folder called .autoshrink or .autodecrypt - you might find it easier over FTP, samba or even telnet.

I considered writing a package which adds flags to directories automatically - might have to resurrect the idea.
 
Gotcha. I did it via telnet with
Code:
for i in * ; do if [ -d "$i" ] ; then touch "$i/.autoshrink" ; fi ; done
I'm a fairly experienced Linux user so I like things like custom firmwares :D
 
Since my HDR-T2's 1TB disc was getting full, I've been experimenting with auto-decrypt and auto-shrink
You are only putting off the evil moment, an ever-expanding backlog will eventually overwhelm however much storage you throw at it. Perhaps a better housekeeping regime is called for, and a more prudent approach to selecting programmes to record. There is little point recording (on average) more hours of material than the time you have for viewing, what it's really about is shifting a programme you want to see into a convenient time to see it.

You will also appreciate that decrypting represents a disk read and a disk write, and so does shrink, so including the initial record operation that's multiplied by 5 the chances of data corruption.
 
Bile? You don't like it when somebody disagrees with you, do you! I only suggested you made it compatible with the other packages. Any heat, as I recall, was the result of you not seeing the need.

Before you start calling people names, reputation around here is measured in "likes" - go compare.
 
You are only putting off the evil moment, an ever-expanding backlog will eventually overwhelm however much storage you throw at it. Perhaps a better housekeeping regime is called for, and a more prudent approach to selecting programmes to record. There is little point recording (on average) more hours of material than the time you have for viewing, what it's really about is shifting a programme you want to see into a convenient time to see it.

Well, yes and no. I have quite a lot of recordings that I've watched and would like to hang on to, for watching again, or when I have people over, but I need decrypt them to transfer them to another DNLA streamer, and I might as well shrink them rather than waste disc space. Disc is cheap, but not as cheap as spare CPU cycles.

You will also appreciate that decrypting represents a disk read and a disk write, and so does shrink, so including the initial record operation that's multiplied by 5 the chances of data corruption.

Another reason for migrating content to my other box: it has a RAID-6 disc array. On the other hand, I think it's worth mentioning that scrubbing discs is a way of keeping them alive, while leaving them to rot isn't, so in fact reading and writing files is better than leaving them alone. Or are you suggesting that the decrypting and shrinking processes are in themselves sources of corruption?
 
Or are you suggesting that the decrypting and shrinking processes are in themselves sources of corruption?
You weren't asking me but the processes should not cause corruption unless anything goes wrong. I think the risk is very small.

On the other hand, I think it's worth mentioning that scrubbing discs is a way of keeping them alive, while leaving them to rot isn't, so in fact reading and writing files is better than leaving them alone.
Very interesting point. I scrub my ZFS arrays routinely as well although that has the additional benefit of verifying all the block level checksums at the same time.

These CE/AV disks don't always seem to obey the normal rules though. The sysmon package which does a lot of updates to an SQLite database appears to have caused block level corruption on some people's disks - albeit in Humax boxes which have been running for over 18 months.
 
Well, yes and no. I have quite a lot of recordings that I've watched and would like to hang on to, for watching again, or when I have people over

I have no problem with that, but people do have a habit of squirrelling away stuff that will never see the light of day again (we are probably all guilty to a greater or lesser extent). It would be interesting to check in, say, 5 year's time, how much has actually been used at all. I have been collecting up movies, but I don't have a habit of sitting down to watch a movie, so why am I doing it?

Another reason for migrating content to my other box: it has a RAID-6 disc array. On the other hand, I think it's worth mentioning that scrubbing discs is a way of keeping them alive, while leaving them to rot isn't, so in fact reading and writing files is better than leaving them alone. Or are you suggesting that the decrypting and shrinking processes are in themselves sources of corruption?

Certainly shrinking is a good idea for long term storage. As af123 says, the risk is small (through the whole chain) but not zero. I don't think the process contributes to scrubbing - once the process is complete the file is in its final destination and will not get moved again. I still recommend a selective approach though. Stuff that is just being time-shifted, watched, and deleted doesn't need processing. Stuff destined for deep storage could be just be moved into a "magic folder" which decrypts, shrinks, and auto-syncs to the NAS.

I had a mirrored RAID once - the PSU blew and took out both drives.
 
but I need decrypt them to transfer them to another DNLA streamer

I'd be interested in how you get on here. I've been trying to get decrypted recordings to be streamed from a buffalo linkstation via Twonky to my Sony smart TV. No joy so far. Not sure if its the Linkstation or Twonky or the TV that's the problem.
 
The decrypt and shrink bit is already available (create a folder, set the auto-decrypt and auto-shrink flags from the WebIF), and the use of rsync to transfer stuff has been discussed in another topic.
 
For one magic folder that doesn't matter. I was explaining the concept of only decrypting and shrinking stuff destined for long-term storage, by moving it into a reserved folder that has the auto-decrypt and auto-shrink flags set. They don't need to propagate to sub-folders (unless your intention is to move entire folders, which is not supported in the SUI).
 
Back
Top