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:
Hi,
I have just acquired a Hauppauge HVR 4000 hybrid DVB-S2 / DVB-T / Analogue card which I am trying to use with VDR 1.7.21 on the latest Slackware
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
[ 7.551788] i915 0000:00:02.0: setting latency timer to 64 [ 7.564218] i915 0000:00:02.0: irq 41 for MSI/MSI-X [ 7.564399] vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 7.564825] [drm] initialized overlay support [ 7.579830] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded [ 7.583007] No connectors reported connected with modes [ 7.583077] [drm] Cannot find any crtc or sizes - going 1024x768 [ 7.588874] Console: switching to colour frame buffer device 128x48 [ 7.591121] fb0: inteldrmfb frame buffer device [ 7.591144] drm: registered panic notifier [ 7.591174] No ACPI video bus found [ 7.591316] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0
on minor 0
[ 7.617097] cx88[0]: i2c init: enabling analog demod on
HVR1300/3000/4000 tuner
[ 7.702578] IR RC5(x) protocol handler initialized [ 7.728589] IR RC6 protocol handler initialized [ 7.730628] cx2388x alsa driver version 0.0.9 loaded [ 7.746096] IR JVC protocol handler initialized [ 7.749962] IR Sony protocol handler initialized [ 7.918601] IR MCE Keyboard/mouse protocol handler initialized [ 7.980484] lirc_dev: IR Remote Control driver registered, major
243
[ 7.994039] IR LIRC bridge handler initialized [ 7.994767] tda9887 15-0043: creating new instance [ 7.994795] tda9887 15-0043: tda988[5/6/7] found [ 7.995608] tuner 15-0043: Tuner 74 found with type(s) Radio TV. [ 7.997560] tuner 15-0061: Tuner -1 found with type(s) Radio TV. [ 8.035897] tveeprom 15-0050: Hauppauge model 69009, rev B2D3,
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)
[ 8.036055] tveeprom 15-0050: audio processor is CX882 (idx 33) [ 8.036085] tveeprom 15-0050: decoder processor is CX882 (idx 25) [ 8.037240] tveeprom 15-0050: has radio, has IR receiver, has no IR
transmitter
[ 8.038391] cx88[0]: hauppauge eeprom: model=69009 [ 8.042759] tuner-simple 15-0061: creating new instance [ 8.043910] tuner-simple 15-0061: type set to 78 (Philips
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
[ 8.112944] enough quality for its usage in production. [ 8.112945] Use it with care. [ 8.112945] Latest git patches (needed if you report a bug to
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
[ 8.197600] wm8775 15-001b: chip found @ 0x36 (cx88[0]) [ 8.211895] cx88/2: cx2388x dvb driver version 0.0.9 loaded [ 8.213155] cx88/2: registering cx8802 driver, type: dvb access:
shared
[ 8.213801] cx88[0]/0: registered device video0 [v4l2] [ 8.213847] cx88[0]/0: registered device vbi0 [ 8.213891] cx88[0]/0: registered device radio0 [ 8.215082] cx88_audio 0000:03:00.1: PCI INT A -> GSI 19 (level,
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]
[ 8.222053] cx88[0]/2: cx2388x based DVB/ATSC card [ 8.223339] cx8802_alloc_frontends() allocating 2 frontend(s) [ 8.272844] tuner-simple 15-0061: attaching existing instance [ 8.274126] tuner-simple 15-0061: couldn't set type to 63. Using 78
(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
[ 8.503564] fuse init (API version 7.15) [ 9.184585] EXT4-fs (sda1): re-mounted. Opts: (null) [ 9.308820] EXT4-fs (sda1): re-mounted. Opts: (null) [ 9.581725] lp0: using parport0 (interrupt-driven). [ 9.583036] lp0: console ready [ 14.900540] ATL1E 0000:01:00.0: irq 42 for MSI/MSI-X [ 20.345506] ATL1E 0000:01:00.0: eth0: NIC Link is Up<10 Mbps Full
Duplex>
[ 29.618702] NET: Registered protocol family 10 [ 29.618871] lo: Disabled Privacy Extensions [ 40.210009] eth0: no IPv6 routers present [ 308.497672] start_kdeinit (2104): /proc/2104/oom_adj is deprecated,
please use /proc/2104/oom_score_adj instead.
[ 313.497259] ata3.00: configured for UDMA/133 [ 313.497262] ata3: EH complete [ 314.195827] EXT4-fs (sda1): re-mounted. Opts: commit=0
However, VDR is only able to use the first of the two frontends,
reporting that the second frontend (DVB/T) is busy:
Nov 13 20:04:06 Nutrigrain vdr: [2426] VDR version 1.7.21 started Nov 13 20:04:06 Nutrigrain vdr: [2426] codeset is 'ISO-8859-1' - known Nov 13 20:04:06 Nutrigrain vdr: [2426] found 28 locales in ./locale Nov 13 20:04:06 Nutrigrain vdr: [2426] loading plugin: ./PLUGINS/lib/libvdr-sc.so.1.7.21 Nov 13 20:04:06 Nutrigrain vdr: [2426] cTimeMs: using monotonic clock (resolution is 1 ns) Nov 13 20:04:06 Nutrigrain vdr: [2426] loading plugin: ./PLUGINS/lib/libvdr-rotor.so.1.7.21 Nov 13 20:04:06 Nutrigrain vdr: [2426] loading /home/digitalTV/config/setup.conf Nov 13 20:04:07 Nutrigrain vdr:
[2426] unknown locale: '0'
Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/sources.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/diseqc.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/channels.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/timers.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/commands.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/svdrphosts.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/remote.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/keymacros.conf Nov 13 20:04:07 Nutrigrain vdr: [2427] video directory scanner thread started (pid=2426, tid=2427) Nov 13 20:04:07 Nutrigrain vdr: [2428] video directory scanner thread started (pid=2426, tid=2428) Nov 13 20:04:07 Nutrigrain vdr: [2426] reading EPG data from /home/digitalTV/video/epg.data Nov 13 20:04:07 Nutrigrain vdr: [2427] video directory scanner thread ended (pid=2426, tid=2427) Nov 13
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
Nutrigrain vdr: [2431] tuner on frontend 0/0 thread started (pid=2426, tid=2431) Nov 13 20:04:12 Nutrigrain vdr: [2432] section handler thread started (pid=2426, tid=2432) Nov 13 20:04:17 Nutrigrain vdr: [2426] ERROR: /dev/dvb/adapter0/frontend1: Device or resource busy Nov 13 20:04:17 Nutrigrain vdr: [2426] found 1 DVB device
I initially tried using the stock drivers that came with 2.6.37.6
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.
Any assistance in resolving this issue would be much appreciated.
Thanks,
Mark Hawes.
-- 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
-- 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:
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.
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.
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:
Hi,
I have just acquired a Hauppauge HVR 4000 hybrid DVB-S2 / DVB-T / Analogue card which I am trying to use with VDR 1.7.21 on the latest Slackware
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
[ 7.551788] i915 0000:00:02.0: setting latency timer to 64 [ 7.564218] i915 0000:00:02.0: irq 41 for MSI/MSI-X [ 7.564399] vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 7.564825] [drm] initialized overlay support [ 7.579830] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded [ 7.583007] No connectors reported connected with modes [ 7.583077] [drm] Cannot find any crtc or sizes - going 1024x768 [ 7.588874] Console: switching to colour frame buffer device 128x48 [ 7.591121] fb0: inteldrmfb frame buffer device [ 7.591144] drm: registered panic notifier [ 7.591174] No ACPI video bus found [ 7.591316] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0
on minor 0
[ 7.617097] cx88[0]: i2c init: enabling analog demod on
HVR1300/3000/4000 tuner
[ 7.702578] IR RC5(x) protocol handler initialized [ 7.728589] IR RC6 protocol handler initialized [ 7.730628] cx2388x alsa driver version 0.0.9 loaded [ 7.746096] IR JVC protocol handler initialized [ 7.749962] IR Sony protocol handler initialized [ 7.918601] IR MCE Keyboard/mouse protocol handler initialized [ 7.980484] lirc_dev: IR Remote Control driver registered, major
243
[ 7.994039] IR LIRC bridge handler initialized [ 7.994767] tda9887 15-0043: creating new instance [ 7.994795] tda9887 15-0043: tda988[5/6/7] found [ 7.995608] tuner 15-0043: Tuner 74 found with type(s) Radio TV. [ 7.997560] tuner 15-0061: Tuner -1 found with type(s) Radio TV. [ 8.035897] tveeprom 15-0050: Hauppauge model 69009, rev B2D3,
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)
[ 8.036055] tveeprom 15-0050: audio processor is CX882 (idx 33) [ 8.036085] tveeprom 15-0050: decoder processor is CX882 (idx 25) [ 8.037240] tveeprom 15-0050: has radio, has IR receiver, has no IR
transmitter
[ 8.038391] cx88[0]: hauppauge eeprom: model=69009 [ 8.042759] tuner-simple 15-0061: creating new instance [ 8.043910] tuner-simple 15-0061: type set to 78 (Philips
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
[ 8.112944] enough quality for its usage in production. [ 8.112945] Use it with care. [ 8.112945] Latest git patches (needed if you report a bug to
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
[ 8.197600] wm8775 15-001b: chip found @ 0x36 (cx88[0]) [ 8.211895] cx88/2: cx2388x dvb driver version 0.0.9 loaded [ 8.213155] cx88/2: registering cx8802 driver, type: dvb access:
shared
[ 8.213801] cx88[0]/0: registered device video0 [v4l2] [ 8.213847] cx88[0]/0: registered device vbi0 [ 8.213891] cx88[0]/0: registered device radio0 [ 8.215082] cx88_audio 0000:03:00.1: PCI INT A -> GSI 19 (level,
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]
[ 8.222053] cx88[0]/2: cx2388x based DVB/ATSC card [ 8.223339] cx8802_alloc_frontends() allocating 2 frontend(s) [ 8.272844] tuner-simple 15-0061: attaching existing instance [ 8.274126] tuner-simple 15-0061: couldn't set type to 63. Using 78
(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
[ 8.503564] fuse init (API version 7.15) [ 9.184585] EXT4-fs (sda1): re-mounted. Opts: (null) [ 9.308820] EXT4-fs (sda1): re-mounted. Opts: (null) [ 9.581725] lp0: using parport0 (interrupt-driven). [ 9.583036] lp0: console ready [ 14.900540] ATL1E 0000:01:00.0: irq 42 for MSI/MSI-X [ 20.345506] ATL1E 0000:01:00.0: eth0: NIC Link is Up<10 Mbps Full
Duplex>
[ 29.618702] NET: Registered protocol family 10 [ 29.618871] lo: Disabled Privacy Extensions [ 40.210009] eth0: no IPv6 routers present [ 308.497672] start_kdeinit (2104): /proc/2104/oom_adj is deprecated,
please use /proc/2104/oom_score_adj instead.
[ 313.497259] ata3.00: configured for UDMA/133 [ 313.497262] ata3: EH complete [ 314.195827] EXT4-fs (sda1): re-mounted. Opts: commit=0
However, VDR is only able to use the first of the two frontends,
reporting that the second frontend (DVB/T) is busy:
Nov 13 20:04:06 Nutrigrain vdr: [2426] VDR version 1.7.21 started Nov 13 20:04:06 Nutrigrain vdr: [2426] codeset is 'ISO-8859-1' - known Nov 13 20:04:06 Nutrigrain vdr: [2426] found 28 locales in ./locale Nov 13 20:04:06 Nutrigrain vdr: [2426] loading plugin: ./PLUGINS/lib/libvdr-sc.so.1.7.21 Nov 13 20:04:06 Nutrigrain vdr: [2426] cTimeMs: using monotonic clock (resolution is 1 ns) Nov 13 20:04:06 Nutrigrain vdr: [2426] loading plugin: ./PLUGINS/lib/libvdr-rotor.so.1.7.21 Nov 13 20:04:06 Nutrigrain vdr: [2426] loading /home/digitalTV/config/setup.conf Nov 13 20:04:07 Nutrigrain vdr:
[2426] unknown locale: '0'
Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/sources.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/diseqc.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/channels.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/timers.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/commands.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/svdrphosts.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/remote.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/keymacros.conf Nov 13 20:04:07 Nutrigrain vdr: [2427] video directory scanner thread started (pid=2426, tid=2427) Nov 13 20:04:07 Nutrigrain vdr: [2428] video directory scanner thread started (pid=2426, tid=2428) Nov 13 20:04:07 Nutrigrain vdr: [2426] reading EPG data from /home/digitalTV/video/epg.data Nov 13 20:04:07 Nutrigrain vdr: [2427] video directory scanner thread ended (pid=2426, tid=2427) Nov 13
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
Nutrigrain vdr: [2431] tuner on frontend 0/0 thread started (pid=2426, tid=2431) Nov 13 20:04:12 Nutrigrain vdr: [2432] section handler thread started (pid=2426, tid=2432) Nov 13 20:04:17 Nutrigrain vdr: [2426] ERROR: /dev/dvb/adapter0/frontend1: Device or resource busy Nov 13 20:04:17 Nutrigrain vdr: [2426] found 1 DVB device
I initially tried using the stock drivers that came with 2.6.37.6
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.
Any assistance in resolving this issue would be much appreciated.
Thanks,
Mark Hawes.
-- 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
-- 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
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Tue, 15 Nov 2011 14:08:24 +1100 "Hawes, Mark" MARK.HAWES@au.fujitsu.com wrote:
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.>>>>>
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.
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
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:
Hi,
I have just acquired a Hauppauge HVR 4000 hybrid DVB-S2 / DVB-T / Analogue card which I am trying to use with VDR 1.7.21 on the latest Slackware
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
[ 7.551788] i915 0000:00:02.0: setting latency timer to 64 [ 7.564218] i915 0000:00:02.0: irq 41 for MSI/MSI-X [ 7.564399] vgaarb: device changed decodes:
PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[ 7.564825] [drm] initialized overlay support [ 7.579830] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded [ 7.583007] No connectors reported connected with modes [ 7.583077] [drm] Cannot find any crtc or sizes - going 1024x768 [ 7.588874] Console: switching to colour frame buffer device 128x48 [ 7.591121] fb0: inteldrmfb frame buffer device [ 7.591144] drm: registered panic notifier [ 7.591174] No ACPI video bus found [ 7.591316] [drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0
on minor 0
[ 7.617097] cx88[0]: i2c init: enabling analog demod on
HVR1300/3000/4000 tuner
[ 7.702578] IR RC5(x) protocol handler initialized [ 7.728589] IR RC6 protocol handler initialized [ 7.730628] cx2388x alsa driver version 0.0.9 loaded [ 7.746096] IR JVC protocol handler initialized [ 7.749962] IR Sony protocol handler initialized [ 7.918601] IR MCE Keyboard/mouse protocol handler initialized [ 7.980484] lirc_dev: IR Remote Control driver registered, major
243
[ 7.994039] IR LIRC bridge handler initialized [ 7.994767] tda9887 15-0043: creating new instance [ 7.994795] tda9887 15-0043: tda988[5/6/7] found [ 7.995608] tuner 15-0043: Tuner 74 found with type(s) Radio TV. [ 7.997560] tuner 15-0061: Tuner -1 found with type(s) Radio TV. [ 8.035897] tveeprom 15-0050: Hauppauge model 69009, rev B2D3,
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)
[ 8.036055] tveeprom 15-0050: audio processor is CX882 (idx 33) [ 8.036085] tveeprom 15-0050: decoder processor is CX882 (idx 25) [ 8.037240] tveeprom 15-0050: has radio, has IR receiver, has no IR
transmitter
[ 8.038391] cx88[0]: hauppauge eeprom: model=69009 [ 8.042759] tuner-simple 15-0061: creating new instance [ 8.043910] tuner-simple 15-0061: type set to 78 (Philips
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
[ 8.112944] enough quality for its usage in production. [ 8.112945] Use it with care. [ 8.112945] Latest git patches (needed if you report a bug to
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
[ 8.197600] wm8775 15-001b: chip found @ 0x36 (cx88[0]) [ 8.211895] cx88/2: cx2388x dvb driver version 0.0.9 loaded [ 8.213155] cx88/2: registering cx8802 driver, type: dvb access:
shared
[ 8.213801] cx88[0]/0: registered device video0 [v4l2] [ 8.213847] cx88[0]/0: registered device vbi0 [ 8.213891] cx88[0]/0: registered device radio0 [ 8.215082] cx88_audio 0000:03:00.1: PCI INT A -> GSI 19 (level,
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]
[ 8.222053] cx88[0]/2: cx2388x based DVB/ATSC card [ 8.223339] cx8802_alloc_frontends() allocating 2 frontend(s) [ 8.272844] tuner-simple 15-0061: attaching existing instance [ 8.274126] tuner-simple 15-0061: couldn't set type to 63. Using 78
(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
[ 8.503564] fuse init (API version 7.15) [ 9.184585] EXT4-fs (sda1): re-mounted. Opts: (null) [ 9.308820] EXT4-fs (sda1): re-mounted. Opts: (null) [ 9.581725] lp0: using parport0 (interrupt-driven). [ 9.583036] lp0: console ready [ 14.900540] ATL1E 0000:01:00.0: irq 42 for MSI/MSI-X [ 20.345506] ATL1E 0000:01:00.0: eth0: NIC Link is Up<10 Mbps Full
Duplex>
[ 29.618702] NET: Registered protocol family 10 [ 29.618871] lo: Disabled Privacy Extensions [ 40.210009] eth0: no IPv6 routers present [ 308.497672] start_kdeinit (2104): /proc/2104/oom_adj is deprecated,
please use /proc/2104/oom_score_adj instead.
[ 313.497259] ata3.00: configured for UDMA/133 [ 313.497262] ata3: EH complete [ 314.195827] EXT4-fs (sda1): re-mounted. Opts: commit=0
However, VDR is only able to use the first of the two frontends,
reporting that the second frontend (DVB/T) is busy:
Nov 13 20:04:06 Nutrigrain vdr: [2426] VDR version 1.7.21 started Nov 13 20:04:06 Nutrigrain vdr: [2426] codeset is 'ISO-8859-1' - known Nov 13 20:04:06 Nutrigrain vdr: [2426] found 28 locales in ./locale Nov 13 20:04:06 Nutrigrain vdr: [2426] loading plugin: ./PLUGINS/lib/libvdr-sc.so.1.7.21 Nov 13 20:04:06 Nutrigrain vdr: [2426] cTimeMs: using monotonic clock (resolution is 1 ns) Nov 13 20:04:06 Nutrigrain vdr: [2426] loading plugin: ./PLUGINS/lib/libvdr-rotor.so.1.7.21 Nov 13 20:04:06 Nutrigrain vdr: [2426] loading /home/digitalTV/config/setup.conf Nov 13 20:04:07 Nutrigrain vdr:
[2426] unknown locale: '0'
Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/sources.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/diseqc.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/channels.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/timers.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/commands.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/svdrphosts.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/remote.conf Nov 13 20:04:07 Nutrigrain vdr: [2426] loading /home/digitalTV/config/keymacros.conf Nov 13 20:04:07 Nutrigrain vdr: [2427] video directory scanner thread started (pid=2426, tid=2427) Nov 13 20:04:07 Nutrigrain vdr: [2428] video directory scanner thread started (pid=2426, tid=2428) Nov 13 20:04:07 Nutrigrain vdr: [2426] reading EPG data from /home/digitalTV/video/epg.data Nov 13 20:04:07 Nutrigrain vdr: [2427] video directory scanner thread ended (pid=2426, tid=2427) Nov
13
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
Nutrigrain vdr: [2431] tuner on frontend 0/0 thread started (pid=2426, tid=2431) Nov 13 20:04:12 Nutrigrain vdr: [2432] section handler thread started (pid=2426, tid=2432) Nov 13 20:04:17 Nutrigrain vdr: [2426] ERROR: /dev/dvb/adapter0/frontend1: Device or
resource busy Nov 13 20:04:17 Nutrigrain vdr: [2426] found 1 DVB device
I initially tried using the stock drivers that came with 2.6.37.6
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.
Any assistance in resolving this issue would be much appreciated.
Thanks,
Mark Hawes.
-- To unsubscribe from this list: send the line "unsubscribe linux-media"
in the body of a message to majordomo@vger.kernel.org More majordomo
-- 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
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________ 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 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 ;).
Am 15.11.2011 11:52, schrieb Steffen Barszus:
2011/11/15 Hawes, MarkMARK.HAWES@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 ;).
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 )
Am 15.11.2011 11:52, schrieb Steffen Barszus:
2011/11/15 Hawes, MarkMARK.HAWES@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
;).
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:
-----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 )
Am 15.11.2011 11:52, schrieb Steffen Barszus:
2011/11/15 Hawes, MarkMARK.HAWES@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
;).
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.
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:
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 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:
On Wed, Nov 16, 2011 at 4:38 AM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de 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).
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.
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:
2011/11/16 Manu Abraham abraham.manu@gmail.com:
On Wed, Nov 16, 2011 at 4:38 AM, Klaus Schmidinger Klaus.Schmidinger@tvdr.de 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).
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.
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.
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:
On Wed, Nov 16, 2011 at 6:30 PM, Steffen Barszus
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.
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) ?
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:
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.
And I excuse the pun... ;-)
Lars.
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.
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:
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.
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:
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.
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@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:
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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:
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@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:
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________ 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:
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@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:
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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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.
Klaus
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 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:
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 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?
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.
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.
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:
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 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?
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.
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.
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:
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. :)
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.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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".
Klaus
Am 15.11.2011 23:29, schrieb Hawes, Mark:
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.
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.
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.
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.
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.
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.
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.
Yes, that's the way I want to try to go.
Lars.
Mark.
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
-
Hawes, Mark -
Klaus Schmidinger -
L. Hanisch -
Manu Abraham -
Mika Laitio -
Steffen Barszus -
Tomasz Bubel