On Sat, 4 Dec 2010 10:09:42 -0800
VDR User <user....@gmail.com> wrote:

> On Sat, Dec 4, 2010 at 4:24 AM, Steffen Barszus
> <steffenbpu...@googlemail.com> wrote:
> > a) save some energy - if DVB devices are not opened all the time,
> > the driver has the chance to put it into standby saving some heat,
> > energy and lifetime of the cards
> There are a couple cards that consume a lot of power iirc so this
> could actually be useful for users of those cards.  But what about
> performance/lag?  And also how healthy is it to constantly put a
> device in and out of standby?

Actually how likely it would be that this is constantly happening ?
Having 2 or 3 tuner watching 1 single channel, then every now an then a
couple of recordings i think it's likely 80% in standby - similar to
harddisks which i have in standby except i watch recordings etc. 

> > b) have a beginning of dvb device hotplug - if dvb devices are
> > discovered on demand, its a good chance at a later stage to also add
> > and remove cards on the fly. There is sure some notification
> > required from udev to vdr so it can keep internal reference of the
> > how many devices are there.
> I wonder if this is actually useful.  Is there anyone that would
> need/want this in the real world?

I think yes, beside what gerald mentioned allready, one could also
think of driver reload on a single device without interrupting running
recordings. Also there might be devices which ar not THAT standard like
netceiver or Sundtek network shared devices, which  dont
work like you would expect from internal pci devices. So question is
more what are the arguments against this except the required changes ?
I think this would be what you would expect how it works in todays

One could say it's the reason why you can not have TV picture 2s
after S3 keeping the vdr running during S3. 

To make it short I see use cases for it - i just can not manage to do it
myself - so i thought i share my thoughts, by chance someone interested
is reading it. 

Kind Regards


vdr mailing list

Reply via email to