Hi,<br><br>I am an HVR4000 owner too.<br><br>Re: VDR internals<br><br>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.<br><br>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.<br><br>Practical advice<br><br>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.<br><br>Existing patches<br><br>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.<br><br>Regards,<br><br><br>Ian.<br><br><br>Sent from my HTC<br><br>----- Reply message -----<br>From: "Steffen Barszus" <steffenbpunkt@googlemail.com><br>Date: Tue, Nov 15, 2011 10:52<br>Subject: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )<br>To: "VDR Mailing List" <vdr@linuxtv.org><br><br>2011/11/15 Hawes, Mark <MARK.HAWES@au.fujitsu.com>:<br>>>What i got from previous discussions on linux-media is, that if the<br>>> device nodes are created within one adapter, an application needs to<br>>> assume that<br>>> the devices can not be used concurrently and needs to close<br>>> one "device node group" before opening the other one.<br>>><br>> This suggests a constraint in the current design of the way VDR handles<br>> the detection and use of DVB devices in that it cannot handle so called<br>> 'hybrid' cards where two (or more!) frontends are attached via a single<br>> adaptor without restarting VDR and identifying which frontend to use.<br>><br>> As already mentioned I wish to use both cards on my system and I'd be<br>> interested and happy to help in developing a patch to overcome this<br>> constraint. However I would need some VDR architectural guidance to<br>> suggest how this might be done with minimal disruption to the current<br>> DVB device handling. Any direction would be much appreciated.<br><br>What i said above is AFAIK more or less undocumented up to now. But it<br>seems to be a consensus between most driver developers now.<br><br>Yes vdr needs to change to handle this devices properly based on the<br>previous assumptions, i think soneone else can be more helpful than me<br>;).<br><br>_______________________________________________<br>vdr mailing list<br>vdr@linuxtv.org<br><a href="http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr">http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr</a><br><br><br>