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