>> * Option to choose between RAM / HDD > >I don't think that's actually necessary. Make the file-based lifebuffer >feature rock-solid; if users want to have the buffer in RAM, make them mount a >tmpfs for that purpose. Should lead to simpler code and, in turn, less bugs :) I'm one of the people who will never use disk-based buffering. I simply don't want my hd constantly being hammered so RAM would be my choice and what you propose seems best afaik. I also don't want this feature forced on you like mythtv. There should be the ability to turn it off completely. > * Option to pick the amount of memory / HDD to use +1 > * Option to warn if you switch channel and you are watching the buffer (eg. > "You are watching from the buffer. Changing channel will delete the current > buffer") I don't see any point in this. If changing the channel flushes the buffer, you really only need to mention it once in the changelog/manual/whatever. > * Being able to rewind just by hitting the back/rewind button without > pressing Ok or something else first. +1 IF the live buffer feature is turned on. If it's off, these keys should retain their current behavior. > * When watching the livebuffer, and you notice that you want to save the > curent progarm, you should be able to save the tv-program from either the > beginning of the buffer, or then if the buffer is longer, from the beginning > of where the program started. This way you will be able to save the whole > progra (movie etc.) You can already start an instant recording. I don't think incorporating buffered content into that would be too unreasonable or complex. > * Option to keep X amounts of HDD-buffers after changing channels. Then in > the recording meny would be an entry where you could watch these buffers, > and possibly save them as a recording afterwards. This doesn't really make sense to me. If you want to have recordings of multiple shows/channels, you should just create timers. If live-buffering does find it's way into VDR, the last thing I want it to be is some big huge complex blob. If anything keep it simple & lean at first, but designed in such a way that you can build from its foundation as extra buffering features are thought up. _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
