VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
Lars,
Thanks for the reply.
Output of ls -la /dev/dvb/adapter0:
root@Nutrigrain:/home/digitalTV/vdr-1.7.21# ls -la /dev/dvb/adapter0/* crw-rw---- 1 root video 212, 1 Nov 14 19:20 /dev/dvb/adapter0/demux0 crw-rw---- 1 root video 212, 5 Nov 14 19:20 /dev/dvb/adapter0/demux1 crw-rw---- 1 root video 212, 2 Nov 14 19:20 /dev/dvb/adapter0/dvr0 crw-rw---- 1 root video 212, 6 Nov 14 19:20 /dev/dvb/adapter0/dvr1 crw-rw---- 1 root video 212, 0 Nov 14 19:20 /dev/dvb/adapter0/frontend0 crw-rw---- 1 root video 212, 4 Nov 14 19:20 /dev/dvb/adapter0/frontend1 crw-rw---- 1 root video 212, 3 Nov 14 19:20 /dev/dvb/adapter0/net0 crw-rw---- 1 root video 212, 7 Nov 14 19:20 /dev/dvb/adapter0/net1 root@Nutrigrain:/home/digitalTV/vdr-1.7.21#
As you can see there is a demux1 and dvr1 but all hung off adapter0 which is presumably the problem.
I actually want to use both the DVB-S2 and the DVB-T frontends, though not concurrently.
Happy to work with you on developing the required patch.
If as you suggest that this is actually a VDR problem then I'll also post this reply in the VDR mailing list and we can take it from there.
Regards,
Mark.
-----Original Message----- From: linux-media-owner@vger.kernel.org [mailto:linux-media-owner@vger.kernel.org] On Behalf Of L. Hanisch Sent: Tuesday, 15 November 2011 5:35 AM To: linux-media@vger.kernel.org Subject: Re: HVR 4000 drivers broken - adapter0/frontend1 busy
Hi,
Am 14.11.2011 04:14, schrieb Hawes, Mark:
stable release > using kernel 2.6.37.6.
vdr doesn't know anything about hybrid cards where you can access only one frontend at the same time. On startup vdr opens all frontends, so when accessing the second one this is blocked.
Since I don't know this card exactly, what devices does it create? Is there also a demux[01] and dvr[01] or just a demux0 and dvr0? Which frontend do you want to use? For now you have to choose one and start vdr with the "-D" parameter to tell it which to use. If there's no demux1 and dvr1 and you want to use frontend1 you'll have the next problem since vdr asumes that every frontend has its own demux/dvr. I wrote a patch, so vdr uses demux0 with frontend1.
http://linuxtv.org/pipermail/vdr/2011-November/025411.html
Soon I will have some DVB-C/T hybrid device so I will try to extend the patch so both frontends can be used (not at the same time of course).
It would be nice if you can send me the output of "ls -la /dev/dvb/adapter0/*".
I don't know exactly what the dvb/v4l spec is saying about hybrid devices and how they should expose their capabilities but it seems to me there's some discussion about this topic from time to time.
After all this is a problem at application level, not driver level. If I'm wrong please correct me. And maybe you want to read the vdr mailing list...
Regards, Lars.
The drivers seem to detect the card OK as seen in dmesg output:
[ 7.501729] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9
loaded
[ 7.503174] cx88[0]: subsystem: 0070:6902, board: Hauppauge
WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68,autodetected], frontend(s): 2
[ 7.503373] cx88[0]: TV tuner type 63, Radio tuner type -1 [ 7.551718] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) ->
IRQ 16
PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
on minor 0
[ 7.617097] cx88[0]: i2c init: enabling analog demod on
HVR1300/3000/4000 tuner
243
serial# 3313260
[ 8.035934] tveeprom 15-0050: MAC address is 00:0d:fe:32:8e:6c [ 8.035965] tveeprom 15-0050: tuner model is Philips FMD1216MEX
(idx 133, type 78)
[ 8.036005] tveeprom 15-0050: TV standards PAL(B/G) PAL(I)
SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xf4)
transmitter
FMD1216MEX MK3 Hybrid Tuner)
[ 8.087006] Registered IR keymap rc-hauppauge [ 8.088273] input: cx88 IR (Hauppauge WinTV-HVR400 as
/devices/pci0000:00/0000:00:1e.0/0000:03:00.2/rc/rc0/input6
[ 8.089502] rc0: cx88 IR (Hauppauge WinTV-HVR400 as
/devices/pci0000:00/0000:00:1e.0/0000:03:00.2/rc/rc0
[ 8.090743] input: MCE IR Keyboard/Mouse (cx88xx) as
/devices/virtual/input/input7
[ 8.092315] rc rc0: lirc_dev: driver ir-lirc-codec (cx88xx)
registered at minor = 0
[ 8.093521] cx88[0]/2: cx2388x 8802 Driver Manager [ 8.094694] cx88-mpeg driver manager 0000:03:00.2: PCI INT A ->
GSI 19 (level, low) -> IRQ 19
[ 8.095882] cx88[0]/2: found at 0000:03:00.2, rev: 5, irq: 19,
latency: 64, mmio: 0xfc000000
[ 8.097825] cx8800 0000:03:00.0: PCI INT A -> GSI 19 (level, low)
-> IRQ 19
[ 8.099081] cx88[0]/0: found at 0000:03:00.0, rev: 5, irq: 19,
latency: 64, mmio: 0xfa000000
[ 8.112941] WARNING: You are using an experimental version of the
media stack.
[ 8.112943] As the driver is backported to an older kernel, it
doesn't offer
linux-media@vger.kernel.org):
[ 8.112946] e9eb0dadba932940f721f9d27544a7818b2fa1c5 [media] V4L
menu: add submenu for platform devices
[ 8.112947] 1df3a2c6d036f4923c229fa98725deda320680e1 [media] cx88:
fix menu level for the VP-3054 module
[ 8.112948] 486eeb5628f812b4836405e2b2e76594287dd873 [media] V4L
menu: move all PCI(e) devices to their own submenu
shared
low) -> IRQ 19
[ 8.215106] cx88[0]/1: CX88x/0: ALSA support for cx2388x boards [ 8.220763] cx88[0]/2: subsystem: 0070:6902, board: Hauppauge
WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68]
(Philips FMD1216MEX MK3 Hybrid Tuner) instead
[ 8.279264] DVB: registering new adapter (cx88[0]) [ 8.280558] DVB: registering adapter 0 frontend 0 (Conexant
CX24116/CX24118)...
[ 8.282871] DVB: registering adapter 0 frontend 1 (Conexant CX22702
DVB-T)...
[ 8.423842] Adding 1954444k swap on /dev/sda2. Priority:-1
extents:1 across:1954444k
Duplex>
please use /proc/2104/oom_score_adj instead.
reporting that the second frontend (DVB/T) is busy:
[2426] unknown locale: '0'
20:04:07 Nutrigrain vdr: [2428] video directory scanner thread ended (pid=2426, tid=2428) Nov 13 20:04:07 Nutrigrain vdr: [2426] registered source parameters for 'A - ATSC'
Nov 13 20:04:07 Nutrigrain vdr: [2426] registered source parameters
for 'C - DVB-C'
Nov 13 20:04:07 Nutrigrain vdr: [2426] registered source parameters
for 'S - DVB-S'
Nov 13 20:04:07 Nutrigrain vdr: [2426] registered source parameters
for 'T - DVB-T'
Nov 13 20:04:07 Nutrigrain vdr: [2426] probing /dev/dvb/adapter0/frontend0 Nov 13 20:04:07 Nutrigrain vdr: [2426] new
device number 1 Nov 13 20:04:12 Nutrigrain vdr: [2426] frontend 0/0 provides DVB-S2 with QPSK ("Conexant CX24116/CX24118") Nov 13 20:04:12
which is where I first experienced the problem. I then tried the latest s2-liplianin- f5cd7d75370e drivers and finally (in the example above) the latest v4l-dvb drivers, all of which exhibit the same problem. I have also tried to use the mfe drivers from November 2008 but could not get them to compile.
in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 15 Nov 2011 14:08:24 +1100 "Hawes, Mark" MARK.HAWES@au.fujitsu.com wrote:
Not that on itself, but possibly the implications. Can you try to start the vdr with -D 1 to start the vdr only at the second card ? Assumption would be, that you can use each individually, if you not filter for a device you get a busy device on the second.
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.
On Tue, 15 Nov 2011 14:08:24 +1100 "Hawes, Mark" MARK.HAWES@au.fujitsu.com wrote:
/dev/dvb/adapter0/*
Nov
the vdr with -D 1 to start the vdr only at the second card ? Assumption would >be, that you can use each individually, if you not filter for a device you get a busy device on the second.
Have done so and yes, the DVB-T device is now recognised instead of the DVB-S2 device (and it works).
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.
I actually want to use both the DVB-S2 and the DVB-T frontends,
though
there.
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
2011/11/15 Hawes, Mark MARK.HAWES@au.fujitsu.com:
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 ;).
Am 15.11.2011 11:52, schrieb Steffen Barszus:
I'm just preparing a test environment for extending the vdr to use multi-frontend devices. Good to know that there are drivers which behaves different in creating device nodes. The Cine-C/T cards for example creates only one demux/dvr node and two frontends. Soon I will have my hands on such a device. If I can get a patch working for this card it's only a small step to support the HVR 4000, two.
I have already dealt with vdr devices and have some knowledge about the concepts. I developed the dynamite plugin which extends vdr with some device hotplugging capabilities. It also requires patching the vdr. But with this you can use both devices without restarting vdr and affecting timers and recordings. But for now there's no automatism so that the right device for the watched/recorded channel is attached. Please have a look at the README if you're interested. If you have questions, just ask.
http://projects.vdr-developer.org/projects/plg-dynamite https://github.com/flensrocker/vdr-plugin-dynamite
If you want to develop something on your own, start reading device.[hc] and dvbdevice.[hc] at the vdr source. I definitly will try to develop a "multi-frontend-patch" but spare time is always rare. I will reserve one evening per week for this. And I hope to finish it till christmas. ;-)
If you have ideas please let me know. I'm looking for some inspiration for storing the different frontend capabilities at the cDvbDevice and how to maintain the different cDvbTuner objects. My experience while working on dynamite will help me in particular since I invested some time on closing/reopening the file handles at the right places. Hotplugging "single frontend" devices seems to be a good first step towards the solution of this problem.
Lars.
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of L. Hanisch Sent: Wednesday, 16 November 2011 5:51 AM To: vdr@linuxtv.org Subject: Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
device nodes are created within one adapter, an application needs
to
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
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
me
;).
I'm just preparing a test environment for extending the vdr to use
multi-frontend devices. Good to know that there are drivers which behaves >different in creating device nodes. The Cine-C/T cards for example creates only one demux/dvr node and two frontends. Soon I will have my hands >on such a device. If I can get a patch working for this card it's only a small step to support the HVR 4000, two.
I agree that any such solution should not be card specific but apply in general to cards with various adapter 'architectures'. I can offer my system as a HVR 4000 testbed for such a development.
I have already dealt with vdr devices and have some knowledge about
the concepts. I developed the dynamite plugin which extends vdr with some >device hotplugging capabilities. It also requires patching the vdr. But with this you can use both devices without restarting vdr and affecting timers >and recordings. But for now there's no automatism so that the right device for the watched/recorded channel is attached. Please have a look at the >README if you're interested. If you have questions, just ask.
http://projects.vdr-developer.org/projects/plg-dynamite https://github.com/flensrocker/vdr-plugin-dynamite
I had a look at the readme. The approach of making all devices hot pluggable is an interesting one and provides for a flexible solution. How important it is to get plugins to adapt to the approach is still unclear to me. Presumably if they are in the plugin list prior to the dynamite plugin they will be 'immune' as they will declare their own devices to the pool first.
While the approach has its merits I believe that it is probably overkill in this case. I believe that VDR should be able to cater for hybrid cards natively alongside existing cards with more conventional adapter layouts and any patch should ultimately have that as its goal.
If you want to develop something on your own, start reading
device.[hc] and dvbdevice.[hc] at the vdr source.
I definitly will try to develop a "multi-frontend-patch" but spare
time is always rare. I will reserve one evening per week for this. And I hope to >finish it till christmas. ;-)
As indicated above I'd be happy to test anything you come up with.
If you have ideas please let me know. I'm looking for some
inspiration for storing the different frontend capabilities at the cDvbDevice and how to >maintain the different cDvbTuner objects. My experience while working on dynamite will help me in particular since I invested some time on >closing/reopening the file handles at the right places. Hotplugging "single frontend" devices seems to be a good first step towards the solution of >this problem.
Lars.
As I see it there are two possible approaches: try to bolt on support for hybrid cards as exception cases to the current code, or redesign the handling of the devices from the ground up to also cater for the more exotic adapter layouts. There could be a third 'hybrid' solution which sits somewhere between the two.
The comment above from Steffen seems to make some sense ' if the device nodes are created within one adapter an application needs to assume that the devices cannot be used concurrently and needs to close one "device node group" before opening the other one'. As I understand it this would mean that VDR should register all front ends on initialisation and then only try to open them when required. If another frontend is found to be open on the same device hierarchy a decision is then made to see if it can be closed, e.g. no recordings on it etc. If it can't then the attempt to switch channel fails with 'Channel not available". I may be simplifying things a bite here but that is as I see it. Happy to be corrected.
Mark.
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 15.11.2011, at 23:29, "Hawes, Mark" MARK.HAWES@au.fujitsu.com wrote:
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).
Klaus
On Wed, Nov 16, 2011 at 4:38 AM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de wrote:
If I am following you correctly, There is one issue however. If an adapter can have only a single frontend, then there will exist another issue:
- Card has dual multi standard frontend(s). - Card has CI cards on both the paths (2 CI controllers) - Card provides scrambled stream as well as descrambled stream (4 simultaneous streams) - Card needs to swap between the CI modules to take advantage of the different modules, rather than reconnecting antenna inputs/manually swapping the CI modules.
Eventually, to handle such a situation: all the nodes exposed to the application has to be under the "same" adapter, rather than as 4 different adapters, of which 2 of them won't have any frontend or ca devices.
Regards, Manu
Hi all,
I have HVR-4000 in my htpc together with Nova HD S2, and I'm willing to help as tester. It would be nice to finally getting dvb+t and dvb-s/s2 working together with VDR.
-- Pozdrawiam, Tomasz Bubel
2011/11/16 Manu Abraham abraham.manu@gmail.com:
To my understanding the mentioned use case would have - according to linux-media project logic of how to handle this - would look like
/dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/demux0 ... /dev/dvb/adapter0/ca0 /dev/dvb/adapter1/frontend0 /dev/dvb/adapter1/frontend1 /dev/dvb/adapter1/demux0 ... /dev/dvb/adapter1/ca0
so it would be 2 adapter with 4 frontends. If for some reason they should be in one adapter how to distinguish between the different cases ? Maybe i did not understand properly the issue.
Anyhow - if such a case exist - it needs to be discussed how it will be handled at driver side and how applications need to talk to the driver - it doesnt help to implement the perfect driver, if nobody can use it. The multi frontend approach for multi-standard devices as described here, should logically anyway only be used if more then one receiption possibility can be connected at the same time. (i.e. if sattelite cable also can contain the DVB-T signal or both can be connected same time)
Reading linux-media mailing list doesn't give a clear picture on the rules on one hand , but on the other hand implementations like the mentioned one exist. Preferably the API would describe how to handle it and rules exist for the drivers to be followed, so that applications dont get broken if following the API.
On Wed, Nov 16, 2011 at 6:30 PM, Steffen Barszus steffenbpunkt@googlemail.com wrote:
The very same driver can have 4 real frontends too. By now the issue got complicated too far by the logic mentioned above: So, how will you distinguish between real functional and independant adapters, then (when having multiple adapters) ?
Manu
On Thu, 17 Nov 2011 10:10:34 +0530 Manu Abraham abraham.manu@gmail.com wrote:
Listen Manu,
i'm not proposing anything here - i try only to reflect what i read on linux-media mailinglist. If you have different opinion/suggestion/understanding i would be thankful if you could provide some better input on how vdr needs to handle this.
Am 16.11.2011 00:08, schrieb Klaus Schmidinger:
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.
And I excuse the pun... ;-)
Lars.
On 16.11.2011 19:16, L. Hanisch wrote:
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.
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.
Klaus
Am 16.11.2011 23:26, schrieb Klaus Schmidinger:
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.
I'm fine with this and looking forward to it. A new stable release would be fine! Xmas is next door... :)
Lars.
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. 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.
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?
Thanks,
Mark. -----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of L. Hanisch Sent: Thursday, 17 November 2011 9:59 AM To: vdr@linuxtv.org 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:
multiple cDvbDevices which must interact somehow with each other.
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.
I'm fine with this and looking forward to it. A new stable release would be fine! Xmas is next door... :)
Lars.
Hi,
Am 17.11.2011 11:02, schrieb Hawes, Mark:
Nice to hear.
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 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.
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.
Regards,
Mark.
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of L. Hanisch Sent: Friday, 18 November 2011 4:44 AM To: vdr@linuxtv.org Subject: Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
Hi,
Am 17.11.2011 11:02, schrieb Hawes, Mark:
Nice to hear.
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 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.
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
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
My apologies - the dvbhddevice and dvbsddevice plugins are OK, I was using versions I copied across and were unpatched.
Mark.
-----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.
Regards,
Mark.
-----Original Message----- From: vdr-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of L. Hanisch Sent: Friday, 18 November 2011 4:44 AM To: vdr@linuxtv.org Subject: Re: [vdr] VDR and Hybrid DVB Cards ( was "HVR 4000 drivers broken - adapter0/frontend1 busy" in linux-media list )
Hi,
Am 17.11.2011 11:02, schrieb Hawes, Mark:
Nice to hear.
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 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.
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
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On 16.11.2011 23:59, L. Hanisch wrote:
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.
Klaus
I am wondering what's the reason of breaking this current rule as it sounded so clear...So if cards all delivery systems are mapped as an adapters under same frontend, there must be a some method for querying which of those adapters are tied together. Did Manu say whether that info can be get via dev tree, via sysfs or by using some new ioctl?
And if the patch wont go in, it means that hvr-4000 owners needs to maintain in addition of the vdr-patch, also a patches for all plugins that the patch breaks :-(. On the other hand, if the patch would be accepted to vdr before 2.0, I am sure that all plugi-ns would be adapter to work in couple of weeks to work with the new interfaces.
Mika
On 18.11.2011 23:40, Mika Laitio wrote:
That was my misunderstanding in the beginning, too, and it resulted in a lengthy discussion with Manu ;-)
From what I understood, every physical device (i.e. a DVB PCI card, a USB receiver or whatever) will be exactly *one* adapter. If an adapter provides several delivery systems (like, for instance, DVB-S and DVB-T) and only one of these can be used at a time, there will be *one* frontend that needs to be switched to the desired delivery system before tuning to a transponder. A new ioctl() will allow the application to query which and how many delivery systems a frontend provides. If the adapter has like two DVB-S tuners that can be used simultaneously, then it will have two separate frontends.
From what I understand at this time I don't see why implementing multi-frontend support would break any plugins. Lars' patch apparently does, but my goal would be to make this totally seemless, so plugins wouldn't even notice.
Right now I have only very little (if any) time to work on VDR, because my daytime job requires all my attention. This will change by the end of the year, and then we'll see whether Manu's patch has made it into the driver and whether this can be used for VDR 2.0.
Personally I hope Manu's implementation gets adopted, because I find it very straightforward.
Klaus
On Sat, 19 Nov 2011 00:40:30 +0200 Mika Laitio lamikr@pilppa.org wrote:
If Manu is successful in what he is trying (and existing driver following other rules will be ported) then that sounds fine to me. I dont care what solution , but i care for having one.
Its not a drama if on the other hand above happens. If above happens than vdr needs only to adapt to shared ca devices (which are implemented as i.e. caio0 & ca0 and need some special handling from vdr side.
Am 18.11.2011 19:03, schrieb Klaus Schmidinger:
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. :)
In the meantime I will polish my patch a bit and rework on the changes which breaks existing plugins. It was just a first try anyway.
Lars.
On 19.11.2011 17:15, L. Hanisch wrote:
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".
Klaus
Am 15.11.2011 23:29, schrieb Hawes, Mark:
This is right. But just like the cDvbDeviceProbe there's a cDynamicDeviceProbe class which plugins can use to add hotplugging features to their devices. pvrinput is an example for this.
What I tried to communicate is, that I have some work done which is part of the problem: closing the handles and the right places. I will try to reuse some of the code to extend the cDvbDevice for multiple frontends. Difficult to explain, please let me do some code first. ;-)
I will post it on the list when I have something to show.
I think there are cards which have a digital and an analog tuner. But they are only interesting if they support hardware encoding of the analog material like the Hauppauge PVRx50 cards. I don't think it would be needed to support such cards (iow the analog part of those cards). But one should keep this at the back of one's head.
Yes, that's the way I want to try to go.
Lars.
-
Hawes, Mark -
Klaus Schmidinger -
L. Hanisch -
Manu Abraham -
Mika Laitio -
Steffen Barszus -
Tomasz Bubel