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@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.HAWES@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
This is starting to sound like a big overhaul. If that's the case, maybe it should go one step further and compartmentalize all the settings so VDR can take the next step and provide a true server/client option. ;)