[vdr] [ANNOUNCE] VDR developer version 1.7.24

Timothy D. Lenz tlenz at vorgon.com
Sun Mar 4 19:02:22 CET 2012

On 3/2/2012 11:06 AM, VDR User wrote:
> On Fri, Mar 2, 2012 at 4:13 AM, Tony Houghton<h at realh.co.uk>  wrote:
>> Signal the server to start recording. But then the client has to be able
>> to match up its buffer with what the server has recorded after the
>> buffer filled and let the server know when the temp recording is no
>> longer needed. Complicated.
> Maybe something like this would work...
> User can define how much of his ram he wants used for buffering. VDR
> uses x% of this for constant buffering. The remainder is only used
> when pause/rewind has been pressed. When the remainder is filled, the
> entire buffer is dumped to disk as a temp recording, which continued
> to be recorded until a) live view has been resumed for X secs, or b)
> until the show ends. The temp recording is then purged after a user
> defined X minutes (or never if 0) of it's last modified timestamp.
> If live buffering is to be added, it should have some flexibility, but
> it still doesn't need to be overly complicated. Whatever the actual
> live buffer behavior, I believe a ram-based solution is the best
> choice for a number of reasons.
>> Have the server record everything it plays and not bother with buffering
>> in the client. I don't think most people want VDR to work that way
>> because of extra load on the hard drive.
> HELL NO! I will not use software that forces my harddrive(s) into a
> constant write state 24/7. I don't want the extra wear. I don't want
> the extra heat. I don't want the extra power consumption. And I'm
> certainly not alone.
I agree, this is what MythTV does and why I never tried to fully install 
it. I started to once to try it out, but I just didn't like the need for 
continous recording.  Would be ok with sold state drives that don't ware 
out with use like the current ones do. But even they are too costly for 
me to even look at.

More information about the vdr mailing list