Hi,
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.).
Lars.
Thanks,
Mark.
-----Original Message-----
From: vdr-bounces@xxxxxxxxxxx [mailto:vdr-bounces@xxxxxxxxxxx] On Behalf
Of L. Hanisch
Sent: Thursday, 17 November 2011 9:59 AM
To: vdr@xxxxxxxxxxx
Subject: Re: 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@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
