[vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )

Hawes, Mark MARK.HAWES at au.fujitsu.com
Tue Nov 15 23:29:41 CET 2011


-----Original Message-----
From: vdr-bounces at linuxtv.org [mailto:vdr-bounces at linuxtv.org] On Behalf
Of L. Hanisch
Sent: Wednesday, 16 November 2011 5:51 AM
To: vdr at linuxtv.org
Subject: Re: [vdr] 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 at au.fujitsu.com>:
>>>> 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.

Mark.    

_______________________________________________
vdr mailing list
vdr at linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr





More information about the vdr mailing list