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

ian_and_joanna@talktalk.net ian_and_joanna at talktalk.net
Tue Nov 15 12:30:25 CET 2011


Hi,

I am an HVR4000 owner too.

Re: VDR internals

I'm no expert but the basic assumption is that all devices are available at all time.  This assumption has implications for e.g. timers, epg scans, multi-clients etc. This assumption breaks with the HVR4000.

Basic use to watch one channel at a time with VDR switching between T and S devices as appropriate is the most simple case. But a corner case considering wider use-cases of VDR.

Practical advice

Get a dedicated T or S receiver to be able to receive T and S with vanilla VDR. To exercise the HVR4000 re: integration of multi-frontends may involve a long wait for development.

Existing patches

There had been some work a while ago reported in this forum (search this forum for something like 'multi frontends'), don't know current status.

Regards,


Ian.


Sent from my HTC

----- Reply message -----
From: "Steffen Barszus" <steffenbpunkt at googlemail.com>
Date: Tue, Nov 15, 2011 10:52
Subject: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
To: "VDR Mailing List" <vdr at linuxtv.org>

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
;).

_______________________________________________
vdr mailing list
vdr at linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.linuxtv.org/pipermail/vdr/attachments/20111115/ad98b243/attachment.html>


More information about the vdr mailing list