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