On 15.11.2011, at 23:29, "Hawes, Mark" <MARK.HAWES@xxxxxxxxxxxxxx> wrote: > -----Original Message----- > From: vdr-bounces@xxxxxxxxxxx [mailto:vdr-bounces@xxxxxxxxxxx] On Behalf > Of L. Hanisch > Sent: Wednesday, 16 November 2011 5:51 AM > To: vdr@xxxxxxxxxxx > Subject: Re: VDR and Hybrid DVB Cards ( was "HVR 4000 drivers > broken - adapter0/frontend1 busy" in linux-media list ) > >> Am 15.11.2011 11:52, schrieb Steffen Barszus: >>> 2011/11/15 Hawes, Mark<MARK.HAWES@xxxxxxxxxxxxxx>: >>>>> What i got from previous discussions on linux-media is, that if the > >>>>> device nodes are created within one adapter, an application needs > to >>>>> assume that the devices can not be used concurrently and needs to >>>>> close one "device node group" before opening the other one. >>>>> >>>> This suggests a constraint in the current design of the way VDR >>>> handles the detection and use of DVB devices in that it cannot > handle >>>> so called 'hybrid' cards where two (or more!) frontends are attached > >>>> via a single adaptor without restarting VDR and identifying which > frontend to use. >>>> >>>> As already mentioned I wish to use both cards on my system and I'd > be >>>> interested and happy to help in developing a patch to overcome this >>>> constraint. However I would need some VDR architectural guidance to >>>> suggest how this might be done with minimal disruption to the > current >>>> DVB device handling. Any direction would be much appreciated. >>> >>> What i said above is AFAIK more or less undocumented up to now. But > it >>> seems to be a consensus between most driver developers now. >>> >>> Yes vdr needs to change to handle this devices properly based on the >>> previous assumptions, i think soneone else can be more helpful than > me >>> ;). >> >> I'm just preparing a test environment for extending the vdr to use > multi-frontend devices. Good to know that there are drivers which > behaves >different in creating device nodes. The Cine-C/T cards for > example creates only one demux/dvr node and two frontends. Soon I will > have my hands >on such a device. If I can get a patch working for this > card it's only a small step to support the HVR 4000, two. >> > I agree that any such solution should not be card specific but apply in > general to cards with various adapter 'architectures'. I can offer my > system as a HVR 4000 testbed for such a development. >> >> I have already dealt with vdr devices and have some knowledge about > the concepts. I developed the dynamite plugin which extends vdr with > some >device hotplugging capabilities. It also requires patching the > vdr. But with this you can use both devices without restarting vdr and > affecting timers >and recordings. But for now there's no automatism so > that the right device for the watched/recorded channel is attached. > Please have a look at the >README if you're interested. If you have > questions, just ask. >> >> http://projects.vdr-developer.org/projects/plg-dynamite >> https://github.com/flensrocker/vdr-plugin-dynamite >> > I had a look at the readme. The approach of making all devices hot > pluggable is an interesting one and provides for a flexible solution. > How important it is to get plugins to adapt to the approach is still > unclear to me. Presumably if they are in the plugin list prior to the > dynamite plugin they will be 'immune' as they will declare their own > devices to the pool first. > > While the approach has its merits I believe that it is probably overkill > in this case. I believe that VDR should be able to cater for hybrid > cards natively alongside existing cards with more conventional adapter > layouts and any patch should ultimately have that as its goal. >> >> If you want to develop something on your own, start reading > device.[hc] and dvbdevice.[hc] at the vdr source. >> I definitly will try to develop a "multi-frontend-patch" but spare > time is always rare. I will reserve one evening per week for this. And I > hope to >finish it till christmas. ;-) >> > As indicated above I'd be happy to test anything you come up with. >> >> If you have ideas please let me know. I'm looking for some > inspiration for storing the different frontend capabilities at the > cDvbDevice and how to >maintain the different cDvbTuner objects. My > experience while working on dynamite will help me in particular since I > invested some time on >closing/reopening the file handles at the right > places. Hotplugging "single frontend" devices seems to be a good first > step towards the solution of >this problem. >> >> Lars. > > As I see it there are two possible approaches: try to bolt on support > for hybrid cards as exception cases to the current code, or redesign the > handling of the devices from the ground up to also cater for the more > exotic adapter layouts. There could be a third 'hybrid' solution which > sits somewhere between the two. > > The comment above from Steffen seems to make some sense ' if the device > nodes are created within one adapter an application needs to assume that > the devices cannot be used concurrently and needs to close one "device > node group" before opening the other one'. As I understand it this would > mean that VDR should register all front ends on initialisation and then > only try to open them when required. If another frontend is found to be > open on the same device hierarchy a decision is then made to see if it > can be closed, e.g. no recordings on it etc. If it can't then the > attempt to switch channel fails with 'Channel not available". I may be > simplifying things a bite here but that is as I see it. Happy to be > corrected. That is also my understanding of multi frontend devices. If an "adapter" has several "frontends" only one of them can be active at any given time. This has nothing to do with any "explosives" (excuse the pun ;-) and will be implemented in the core VDR code as time permits. Right now I'm cleaning up the "lnb sharing" (aka "device bonding") stuff and will hopefully find more time for VDR development by the end of the year (and thereafter). Klaus _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
