My apologies - the dvbhddevice and dvbsddevice plugins are OK, I was
using versions I copied across and were unpatched.


-----Original Message-----
From: Hawes, Mark 
Sent: Friday, 18 November 2011 5:54 PM
To: 'VDR Mailing List'
Subject: RE: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers
broken - adapter0/frontend1 busy" in linux-media list )

Hi Lars,

Some results from further testing:

 - "live viewing with switching channels between frontends": Works OK,
with about a 3 second delay switching from terrestrial to satellite and
about 10 seconds going the other way. The timings are pretty consistent
and I put the difference down to the time to lock being significantly
longer for satellite. 

- "timer recording starts while viewing live TV on the other frontend":
Seems to behave reasonably. The screen goes blank and eventually the
picture is replaced with what appears to be that of the first channel on
the transponder that we are now recording. It stays there even after the
recording completes. The same behaviour is experienced when going either
way, e.g. viewing terrestrial when satellite recording starts or viewing
satellite when terrestrial recording starts.

Have not played with timer conflicts yet.

Now, the problem: It's broken a number of plugins which no longer
compile. These include dvbhddevice, dvbsddevice, dvd, osdpip, Rotorng,
sc and upnp which I use but I'm sure a number of others will be
affected. The primary reason appears to be the redefinition of
cDvbDevice, but some other errors are also reported. Is this
redefinition the 'dirty' part of this initial attempt, or is it
fundamental to the approach? If it's the latter I suspect it will be
very problematic for many users of affected plugins as these will need
to be modified to conform. 



-----Original Message-----
From: [] On Behalf
Of L. Hanisch
Sent: Friday, 18 November 2011 4:44 AM
Subject: Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers
broken - adapter0/frontend1 busy" in linux-media list )


Am 17.11.2011 11:02, schrieb Hawes, Mark:
> Hi Lars,
> Thanks for the patch.
> Basically, it seems to work for the HVR 4000. Both front ends are 
> detected successfully, and both can be used. I'm using it with the 
> xineliboutput plugin and it seems to co-exist OK.

  Nice to hear.

> Starting a recording on one prevents a channel switch to the other 
> with the "Channel not available message". However, when doing so the 
> screen goes black and its necessary to retune the recorded channel to 
> get the picture back. Not a big issue, more an annoyance.

  Ok, I will try to reproduce this. It may be (since the device hasn't
changed) vdr is thinking that it's showing an available channel or
something like this.

> I'll be playing with it in the next couple of days including 
> introducing a SD premium card into the mix to see what happens. Is 
> there anything in particular that you would like me to try?

  I haven't made too much thoughts about tests. Maybe we can work on a
checklist together.

  use cases:
- live viewing with switching channels between frontends
- timer recording starts while viewing live tv on the other frontend
- timer conflicts with different priorities on the different frontends
- streamdev-client/-server?
- ...?

  It looks like the HVR 4000 has no CI. At the moment I don't have
access to cards with decryption hardware, too.
  And I'm not too familiar with this part of the vdr (ci/cam etc.).


> Thanks,
> Mark.
> -----Original Message-----
> From: [] On 
> Behalf Of L. Hanisch
> Sent: Thursday, 17 November 2011 9:59 AM
> To:
> Subject: Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers 
> broken - adapter0/frontend1 busy" in linux-media list )
> 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... :)
> Lars.
> _______________________________________________
> vdr mailing list

vdr mailing list

vdr mailing list

Reply via email to