[vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )

Klaus Schmidinger Klaus.Schmidinger at tvdr.de
Sat Nov 19 18:17:15 CET 2011

On 19.11.2011 17:15, L. Hanisch wrote:
> Am 18.11.2011 19:03, schrieb Klaus Schmidinger:
>> On 16.11.2011 23:59, L. Hanisch wrote:
>>> Am 16.11.2011 23:26, schrieb Klaus Schmidinger:
>>>> On 16.11.2011 19:16, L. Hanisch wrote:
>>>>> Am 16.11.2011 00:08, schrieb Klaus Schmidinger:
>>>>>> That is also my understanding of multi frontend devices.
>>>>>> If an "adapter" has several "frontends" only one of them can
>>>>>> be active at any given time. This has nothing to do with
>>>>>> any "explosives" (excuse the pun ;-) and will be implemented
>>>>>> in the core VDR code as time permits. Right now I'm cleaning up
>>>>>> the "lnb sharing" (aka "device bonding") stuff and will hopefully
>>>>>> find more time for VDR development by the end of the year (and
>>>>>> thereafter).
>>>>> If you don't mind I would try to prefabricate something.
>>>>> On a first guess: would you combine the multiple frontends of an adapter in one cDvbDevice? I think this would be
>>>>> better than having multiple cDvbDevices which must interact somehow with each other.
>>>> Sure there will be one cDvbDevice per adapter for a multi-frontend device
>>>> where only one frontend can be active at any time.
>>>> If (like on the TT-S2 6400) there are several frontends that can be
>>>> active simultaneously, then there shall be separate adapters for each
>>>> frontend, and thus a separate cDvbDevice for each adapter.
>>> Here's a first "quick'n'dirty" patch. Since my hardware hasn't arrived yet I tested with a DVB-T and DVB-C stick and
>>> sym-linked the devices within one adapter. I have no ca-devices in this setup.
>>> Switching between C and T channels works here, but it's not really tested with timers/recordings etc.
>>> I don't have a FF card, so the patches for the plugins are more of "remove compiler warnings" only. One have to think
>>> about cDvbDeviceProbe and the parameters. A frontend argument doesn't make much sense now.
>>>> Note, though, that support for such devices will most likely not
>>>> go into VDR for version 2. I'm trying to wrap things up in order
>>>> to make a stable version 2, and after that will address new things
>>>> like this.
>>> I'm fine with this and looking forward to it. A new stable release would be fine! Xmas is next door... :)
>> I've received an email from Manu Abraham, informing
>> me that he intends to change the driver in such a way that there will always
>> be only *one* frontend, even if it can handle multiple delivery systems.
>> So every frontend an adapter will provide will always be useable independent
>> of all other frontends of that adapter.
>> Personally, I like this method more than having separate frontends for
>> each delivery system, and having to manage access between them.
>> Just wanted to let you know that the official implementation in VDR
>> (most likely after version 2.0) will go a different way than your patch.
> I followed the discussion on linux-media. But since it's a new ioctl some kind of backport would be needed and also a workaround for drivers which doesn't provide the new ioctl.
> One frontend per adapter would be very nice. And in case of dual tuner cards I would expect two adapters since they are independent from each other. If they are combined in one adapter they cannot be distinguished from "old" adapters with mutually exclusive frontends - and things would be dirtier as
> is. :)

Right now VDR considers every frontend to be available independently
of any other, be it an adapter with only a single frontend or one with
several ones. There is no handling for frontends with different delivery
systems (except for DVB-S/DVB-S2, but that's pretty much the same).

Support for frontends with several delivery systems will become available
once the driver supports them in the way Manu described. There is no need
for any backwards compatibility ;-) Those who want to use devices with
multi-delivery-system frontends will just have to use the new driver.
Of course VDR will continue to work with the current driver, but only
by considering all frontends "single delivery-system".


More information about the vdr mailing list