[vdr] [ANNOUNCE] VDR developer version 1.7.24
user.vdr at gmail.com
Fri Mar 2 19:06:42 CET 2012
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.
More information about the vdr