I have pulled this out of the general WebIF topic to provide some subdivision of discussion.
Thanks - good call : )
Savings are estimated at 20% for a StDef recording and 75% for radio.
xyz321 has noted in the webif thread that the rate at which EPG data are broadcast is fairly constant across the Muxes and so the savings will be around 200-300MiB per hour. That figure can be refined as we get more data.
I hadn't tested shrink on audio recordings but will have a look to see what's going wrong there. It works fine on standard and high definition files although the web interface doesn't currently allow you to shrink high definition because I hadn't tested it at the time.
The next webif release will include (at least):
- shrinking of high definition recordings (without the inter-frame packet warnings and statistic overflows);
- shrinking of audio recordings (if it proves possible!);
- option to set folders as auto-shrink, auto-dedup and auto-decrypt. When recordings are automatically shrunk or decrypted and you have the undelete package installed, they old versions will be placed in the dustbin and subsequently automatically deleted in line with the retention period you have configured. If you don't use undelete then they are just removed (would people prefer them to be placed in a _original/ sub-folder as per manual shrink through the web interface?);
- icons against recordings to show if they are shrunk or not (a bit tricky because I have to scan the first few thousand packets of the .ts file to see whether there are any EIT frames in there, but I prefer that approach at the moment to re-purposing a flag in the .hmt file). That's something that happens asynchronously from the web interface display so is filled in shortly after load like the folder sizes and folder new flags.
- more recording in-use checking to avoid multiple processes accessing the same recording at once - I'm also going to provide an API to this so that other packages can easily hook into it (I'm thinking of flatten, nicesplice, seriesfiler, unencrypt, ...) - it will be good to have everyone doing the same checks.
* Automatic processing has proven interesting so far. I have a robust locking mechanism in place so that only one copy can run at once (more than simple lock files) which could be used by other processes too (and, for example, I will be extending to the package management scripts so that you can get a
Package management is busy message rather than a hang followed by an opkg error). I'm currently working on making it as safe as possible on a system which can power off any moment. There are only a few critical sections while sets of files are being moved around so I'm adding recovery and cleanup mechanisms (basic journalling) to handle these. For people who use
redring I'm also adding a general mechanism where it can be instructed to delay the power off command until after a critical section has completed.
You can see it's quite involved so it may take a few days before I'm ready to publish an update!
