Hi All,
I would have a feature-request for the LiveBuffer patch that is available VDR.
Sometimes when I'm watching a program from the buffer, i accidentally hit the <up>/<down> button for pausing/resuming the program (or ch+/ch- too). This of course changes the channel, and i loose my buffer...
What would be great is a feature that warns me before changing channels while watching from the buffer. A prompt like this would be great: "Do you really want to change channel?"
Also a nice thing to have is a way of watching the saved livebuffer-files. Now it get´s saved into /video/LiveBuffer, and vdr does not see this. Maybe it could be saved into a subdirectory like /video/LiveBuffer/2100-01-01.00.01.50.99.rec, then vdr would always have it as the last recording available in the recordings-list...
Regards,
René
On Mon, Mar 2, 2009 at 2:28 AM, Rene linuxtv@hertell.com wrote:
Also a nice thing to have is a way of watching the saved livebuffer-files. Now it get´s saved into /video/LiveBuffer, and vdr does not see this. Maybe it could be saved into a subdirectory like /video/LiveBuffer/2100-01-01.00.01.50.99.rec, then vdr would always have it as the last recording available in the recordings-list...
You really want to record non-stop 24/7 to your harddrive like MythTV does?
VDR User wrote:
On Mon, Mar 2, 2009 at 2:28 AM, Rene linuxtv@hertell.com wrote:
Also a nice thing to have is a way of watching the saved livebuffer-files. Now it get´s saved into /video/LiveBuffer, and vdr does not see this. Maybe it could be saved into a subdirectory like /video/LiveBuffer/2100-01-01.00.01.50.99.rec, then vdr would always have it as the last recording available in the recordings-list...
You really want to record non-stop 24/7 to your harddrive like MythTV does?
Not really.
Maybe it could be with somekind on/off feature, cause it wears out the hdd when constantly recording. There could be a timeout-feature that if the remote is not touched for eg 2h, the LiveBuffer would be disabled..
René
VDR User wrote:
On Mon, Mar 2, 2009 at 2:28 AM, Rene linuxtv@hertell.com wrote:
Also a nice thing to have is a way of watching the saved livebuffer-files. Now it get´s saved into /video/LiveBuffer, and vdr does not see this. Maybe it could be saved into a subdirectory like /video/LiveBuffer/2100-01-01.00.01.50.99.rec, then vdr would always have it as the last recording available in the recordings-list...
You really want to record non-stop 24/7 to your harddrive like MythTV does?
What about using RAM oder some kind of flash media?
I would really appreciate such a function - as long I can choose where I want the buffer to be written... I also would prefer not to have a HD recording 24/7...
With kind regards
Joerg
On Mon, Mar 2, 2009 at 7:49 AM, Jörg Knitter joerg.knitter@gmx.de wrote:
What about using RAM oder some kind of flash media?
I would really appreciate such a function - as long I can choose where I want the buffer to be written... I also would prefer not to have a HD recording 24/7...
Since flash media has a limited amount of writes, I wouldn't recommend using that as a place to do massive recording.
I think at the very least the user should have the option to turn constant hdd recording on/off. I think it's ridiculous MythTV doesn't allow the user to decide if he wants it and just forces it. Not only does it create a lot more wear on your hdd, it also keeps your power usage high and thus your electric bill bigger each month. All that just so I can rewind live tv any time? Umm, no thanks. There's nothing that important on tv that I can't find on the net or see again later when it repeats. ;)
On Mon, 2009-03-02 at 08:18 -0800, VDR User wrote:
On Mon, Mar 2, 2009 at 7:49 AM, Jörg Knitter joerg.knitter@gmx.de wrote:
What about using RAM oder some kind of flash media?
I would really appreciate such a function - as long I can choose where I want the buffer to be written... I also would prefer not to have a HD recording 24/7...
Since flash media has a limited amount of writes, I wouldn't recommend using that as a place to do massive recording.
I think at the very least the user should have the option to turn constant hdd recording on/off. I think it's ridiculous MythTV doesn't allow the user to decide if he wants it and just forces it. Not only does it create a lot more wear on your hdd, it also keeps your power usage high and thus your electric bill bigger each month. All that just so I can rewind live tv any time? Umm, no thanks. There's nothing that important on tv that I can't find on the net or see again later when it repeats. ;)
My 2c...
RAM is cheap - just add some RAM and use a memory-based filesystem like tmpfs? Then there would be no special handling required from VDR since the 'livebuffer' file is part of the directory tree like any other file.
Cheers, Gavin.
On Mon, Mar 2, 2009 at 8:39 AM, Gavin Hamill gdh@acentral.co.uk wrote:
My 2c...
RAM is cheap - just add some RAM and use a memory-based filesystem like tmpfs? Then there would be no special handling required from VDR since the 'livebuffer' file is part of the directory tree like any other file.
Not a bad idea really as long as nothing else needs ram. I recorded 70mins worth of 1080i HDTV the other day and total size was about 3.5G. 4GB is about $35-$40 for DDR2-800 so it's not too expensive. I usually take advantage of mail-in-rebates so I've actually got a few 2x2GB kits here that I haven't paid more then $20 for each and all my boxes have at least 4GB in them already.
Is it possible to resize the live buffer is another app needs more ram?
On Mon, 2 Mar 2009 08:50:42 -0800 VDR User user.vdr@gmail.com wrote:
On Mon, Mar 2, 2009 at 8:39 AM, Gavin Hamill gdh@acentral.co.uk wrote:
My 2c...
RAM is cheap - just add some RAM and use a memory-based filesystem like tmpfs? Then there would be no special handling required from VDR since the 'livebuffer' file is part of the directory tree like any other file.
Not a bad idea really as long as nothing else needs ram. I recorded 70mins worth of 1080i HDTV the other day and total size was about 3.5G. 4GB is about $35-$40 for DDR2-800 so it's not too expensive. I usually take advantage of mail-in-rebates so I've actually got a few 2x2GB kits here that I haven't paid more then $20 for each and all my boxes have at least 4GB in them already.
Is it possible to resize the live buffer is another app needs more ram?
For boxstar I was thinking of having the live buffer in RAM to save writing to the HD, and even wondered about having it in the player front-end instead of the server. Both approaches have their pros and cons.
The beauty of virtual memory is that it works both ways. An application written to use a file can have the file cached in RAM and one written to use RAM can have it swapped to disc if the RAM is needed for something else.
But I wonder, does writing to the HD really shorten its life significantly compared to constant spinning or frequently being spun up and down?
Tony Houghton wrote:
On Mon, 2 Mar 2009 08:50:42 -0800 But I wonder, does writing to the HD really shorten its life significantly compared to constant spinning or frequently being spun up and down?
Yes, i guess it does, cause it writes to the hdd:s surface constantly in large amounts...
But back to my original question. Could someone who is more familiar to c-programming and knows how VDR works check out the LiveBUffer patch and add a these few new features to it? I would love to get warned if i change the channel in the middle of watching a program from the buffer...! :-)
This would be more important feature if the buffer is in RAM, and not on the HDD. If i really missed something important, then I just check it with eg. VLC over a a samba-export..
Regards,
René -=-=- ... ASCII a stupid question, get a stupid ANSI!
On Mon, 02 Mar 2009 19:30:55 +0200 Rene Hertell linuxtv@hertell.com wrote:
Tony Houghton wrote:
On Mon, 2 Mar 2009 08:50:42 -0800 But I wonder, does writing to the HD really shorten its life significantly compared to constant spinning or frequently being spun up and down?
Yes, i guess it does, cause it writes to the hdd:s surface constantly in large amounts...
But there's no physical contact, the surface just has its magnetic polarity changed (or something like that). Is there a limit to how many times it can survive those changes? Or perhaps the head moving mechanism can wear out?
On Mon, 2009-03-02 at 19:15 +0000, Tony Houghton wrote:
On Mon, 02 Mar 2009 19:30:55 +0200 Rene Hertell linuxtv@hertell.com wrote:
Tony Houghton wrote:
On Mon, 2 Mar 2009 08:50:42 -0800 But I wonder, does writing to the HD really shorten its life significantly compared to constant spinning or frequently being spun up and down?
Yes, i guess it does, cause it writes to the hdd:s surface constantly in large amounts...
But there's no physical contact, the surface just has its magnetic polarity changed (or something like that). Is there a limit to how many times it can survive those changes? Or perhaps the head moving mechanism can wear out?
I thought the driving force for having HDs power down was to reduce power, noise and heat?
Disk and RAM are both cheap. Take a backup to a giant slow USB disk once a month, etc. :)
Cheers, Gavin.
On Mon, 02 Mar 2009 19:32:02 +0000 Gavin Hamill gdh@acentral.co.uk wrote:
On Mon, 2009-03-02 at 19:15 +0000, Tony Houghton wrote:
On Mon, 02 Mar 2009 19:30:55 +0200 Rene Hertell linuxtv@hertell.com wrote:
Tony Houghton wrote:
On Mon, 2 Mar 2009 08:50:42 -0800 But I wonder, does writing to the HD really shorten its life significantly compared to constant spinning or frequently being spun up and down?
Yes, i guess it does, cause it writes to the hdd:s surface constantly in large amounts...
But there's no physical contact, the surface just has its magnetic polarity changed (or something like that). Is there a limit to how many times it can survive those changes? Or perhaps the head moving mechanism can wear out?
I thought the driving force for having HDs power down was to reduce power, noise and heat?
Yes, avoiding disc access to keep it spun down is a good idea, but it's difficult to keep one spun down in Linux because of logging activity etc. Even if you manage to solve that problem I think the drive would still need to be used often enough to make it a good idea only if it's something like a laptop drive, designed to be spun up and down more frequently than a desktop one.
Tony Houghton schrieb:
On Mon, 02 Mar 2009 19:32:02 +0000 Gavin Hamill gdh@acentral.co.uk wrote:
On Mon, 2009-03-02 at 19:15 +0000, Tony Houghton wrote:
On Mon, 02 Mar 2009 19:30:55 +0200 Rene Hertell linuxtv@hertell.com wrote:
Tony Houghton wrote:
On Mon, 2 Mar 2009 08:50:42 -0800 But I wonder, does writing to the HD really shorten its life significantly compared to constant spinning or frequently being spun up and down?
Yes, i guess it does, cause it writes to the hdd:s surface constantly in large amounts...
But there's no physical contact, the surface just has its magnetic polarity changed (or something like that). Is there a limit to how many times it can survive those changes? Or perhaps the head moving mechanism can wear out?
I thought the driving force for having HDs power down was to reduce power, noise and heat?
Yes, avoiding disc access to keep it spun down is a good idea, but it's difficult to keep one spun down in Linux because of logging activity etc. Even if you manage to solve that problem I think the drive would still need to be used often enough to make it a good idea only if it's something like a laptop drive, designed to be spun up and down more frequently than a desktop one.
Well there are more things in the world then you think ;) - Some people use CF card , some people Microdrives, some Notebookdrives. The video directory is on a couple of harddisks. Thats possible if you layout the directory structure correct with vdr. My machine ist running from a microdrive since more then a year now.
Livebuffer would sure be interesting but not if: 1) it constantly keeps the disks spinning 2) it consumes a fixed amount of memory.
Is there some tmpfs which allocates a certain percentage of given memory ? Would livebuffer be able to cope with that ?
Then i would for sure pick a bit RAM and try it out. Again: Livebuffer might be nice - but not for the price to pay ...
Kind Regards
Steffen
-
Gavin Hamill -
Jörg Knitter -
Rene -
Rene Hertell
-
Steffen Barszus -
Tony Houghton -
VDR User