On 3/2/2012 11:06 AM, VDR User wrote:
On Fri, Mar 2, 2012 at 4:13 AM, Tony Houghton<h...@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.
_______________________________________________
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
