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.



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 mailing list

Reply via email to