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" <steffenbpu...@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@linuxtv.org> 2011/11/15 Hawes, Mark <mark.ha...@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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
