Hi, I now a have a 4 Tuner Cine S2 setup that I want to run with 3 cables, I want to keep the fourth cable for a test VDR. Reading about this I only see how to do it together with the Dynamite Plugin, is that correct that I must use that Plugin to get it to work for VDR?
I am currently running a plain VDR setup on Ubuntu, with very few plugins and had no need for the Dynamite Plugin up till now.
Cheers Brian
Le jeudi 08 août 2013 "Brian-Imap" Brian_Dorling@t-online.de a écrit:
use adapter_nr option for fixing device number.
like mine:
cat /etc/modprobe.d/dvb.conf options dvb-usb-dib0700 adapter_nr=0 options dvb-usb-tbsqboxs2 adapter_nr=1 options dvb-usb-ttusb2 adapter_nr=2
lsmod |grep dvb_ <-- to get used modules for your DVB devices...
Am 08.08.2013 16:23, schrieb Brian-Imap:
If it's one bridge with 4 tuners, I doubt their order will change.
You may want to read about "device bonding", where you split one cable on two tuners so they share polarisation and band, but may be tuned to different transponders.
But I'm a cable user, I don't know much about it, just that there are some people out there who use it successfully. :)
Regards, Lars.
On 8/8/2013 10:22 PM, Lars Hanisch wrote:
Hi, thanks for the tips, unfotunately I ended up needing to keep using a FF Card for a short while.
So I followed the CT tip and added a TT C-2300 Cable FF card that is not connected to cable at all. That part seems to work really well.
Using the -D parameter in VDR I limited VDR to using the first 4 DVB Devices and this is what it gave me:
Aug 11 11:09:31 localhost vdr: [936] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK ("STV090x Multistandard") Aug 11 11:09:31 localhost vdr: [936] frontend 1/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 ("ST STV0297 DVB-C") Aug 11 11:09:31 localhost vdr: [936] frontend 2/0 provides DVB-S,DVB-S2,DSS with QPSK ("STV090x Multistandard") Aug 11 11:09:31 localhost vdr: [936] frontend 4/0 provides DVB-S,DVB-S2,DSS with QPSK ("STV090x Multistandard")
So tuners 1-3 of the Cine S2 and Duoflex are now in use. DBV device 1 provides nothing but MPEG output.
I guess I'll keep an eye on the DVB device ordering for a while to see how it goes.
Cheers Brian
On 8/11/2013 11:43 AM, Brian-Imap wrote:
Hi, well the DVB device numbering is not consistent:
"VDR-Test-Cellar(SDA2): 15:25 [995] frontend 3/0 provides DVB-S,DVB-S2,DSS with QPSK (""STV090x Multistandard"")" "VDR-Test-Cellar(SDA2): 15:25 [995] frontend 2/0 provides DVB-S,DVB-S2,DSS with QPSK (""STV090x Multistandard"")" "VDR-Test-Cellar(SDA2): 15:25 [995] frontend 1/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 (""ST STV0297 DVB" "VDR-Test-Cellar(SDA2): 15:25 [995] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK (""STV090x Multistandard"")"
"VDR-Test-Cellar(SDA2): 05:10 [1018] frontend 3/0 provides DVB-S,DVB-S2,DSS with QPSK (""STV090x Multistandard"")" "VDR-Test-Cellar(SDA2): 05:10 [1018] frontend 2/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 (""ST STV0297 DV" "VDR-Test-Cellar(SDA2): 05:10 [1018] frontend 1/0 provides DVB-S,DVB-S2,DSS with QPSK (""STV090x Multistandard"")" "VDR-Test-Cellar(SDA2): 05:10 [1018] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK (""STV090x Multistandard"")"
"VDR-Test-Cellar(SDA2): 06:52 [1080] frontend 3/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 (""ST STV0297 DV" "VDR-Test-Cellar(SDA2): 06:52 [1080] frontend 2/0 provides DVB-S,DVB-S2,DSS with QPSK (""STV090x Multistandard"")" "VDR-Test-Cellar(SDA2): 06:52 [1080] frontend 1/0 provides DVB-S,DVB-S2,DSS with QPSK (""STV090x Multistandard"")" "VDR-Test-Cellar(SDA2): 06:52 [1080] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK (""STV090x Multistandard"")"
"VDR-Test-Cellar(SDA2): 19:16 [1015] frontend 3/0 provides DVB-S,DVB-S2,DSS with QPSK (""STV090x Multistandard"")" "VDR-Test-Cellar(SDA2): 19:16 [1015] frontend 2/0 provides DVB-S,DVB-S2,DSS with QPSK (""STV090x Multistandard"")" "VDR-Test-Cellar(SDA2): 19:16 [1015] frontend 1/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 (""ST STV0297 DV" "VDR-Test-Cellar(SDA2): 19:16 [1015] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK (""STV090x Multistandard"")"
Up till now it has not been a problem, the one without a cable must be 4/0. Still I am wondering if this can be controlled? Before VDR start unload the DVB drivers, then load DVBTTPCI first and give it a short delay and then load DDBridge maybe? Still, then is it then guaranteed that DDBridge will number its 4 tuners correctly?
Cheers Brian
On 8/15/2013 9:08 PM, Brian-Imap wrote:
Hi, so I tried to look for some kind of info to help me identify the tuners, this is the most interesting bit I guess:
VDR-test-cellar (SDB1): udevadm info --query=all --name=/dev/dvb/adapter1/frontend0 --attribute-walk looking at device '/devices/pci0000:00/0000:00:0d.0/0000:02:00.0/dvb/dvb1.frontend0': KERNEL=="dvb1.frontend0" SUBSYSTEM=="dvb" DRIVER==""
VDR-test-cellar (SDB1): udevadm info --query=all --name=/dev/dvb/adapter0/frontend0 --attribute-walk looking at device '/devices/pci0000:00/0000:00:0d.0/0000:02:00.0/dvb/dvb0.frontend0': KERNEL=="dvb0.frontend0" SUBSYSTEM=="dvb" DRIVER==""
VDR-test-cellar (SDB1): udevadm info --query=all --name=/dev/dvb/adapter2/frontend0 --attribute-walk looking at device '/devices/pci0000:00/0000:00:0d.0/0000:02:00.0/dvb/dvb2.frontend0': KERNEL=="dvb2.frontend0" SUBSYSTEM=="dvb" DRIVER==""
VDR-test-cellar (SDB1): udevadm info --query=all --name=/dev/dvb/adapter3/frontend0 --attribute-walk looking at device '/devices/pci0000:00/0000:00:06.0/0000:01:06.0/dvb/dvb3.frontend0': KERNEL=="dvb3.frontend0" SUBSYSTEM=="dvb" DRIVER==""
VDR-test-cellar (SDB1): udevadm info --query=all --name=/dev/dvb/adapter4/frontend0 --attribute-walk looking at device '/devices/pci0000:00/0000:00:0d.0/0000:02:00.0/dvb/dvb4.frontend0': KERNEL=="dvb4.frontend0" SUBSYSTEM=="dvb" DRIVER==""
At the moment I cannot find anything to identify the 4 Tuners on the Cine S2, the FF on 01:06 is easy. I got hit by tuning problems a few days ago as the tuner without a cable was given FE3/0. The FF got FE4/0 at that time. I'm wondering if the DDBridge driver will always number in the correct order.
So I guess I'll try to make the FF FE0/0, and hope that the DDBRidge driver will do the rest.
Cheers Brian
On 8/18/2013 8:15 PM, Marc wrote:
Hi, well Its exactly what I was doing, and I cant see a difference. Here an example of two of the Cine S2 Tuners:
VDR-test-cellar (SDB1): udevadm info -a -p $(udevadm info -q path -n /dev/dvb/adapter3/frontend0)
Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:0d.0/0000:02:00.0/dvb/dvb3.frontend0': KERNEL=="dvb3.frontend0" SUBSYSTEM=="dvb" DRIVER==""
looking at parent device '/devices/pci0000:00/0000:00:0d.0/0000:02:00.0': KERNELS=="0000:02:00.0" SUBSYSTEMS=="pci" DRIVERS=="DDBridge" ATTRS{irq}=="16" ATTRS{subsystem_vendor}=="0xdd01" ATTRS{broken_parity_status}=="0" ATTRS{class}=="0x048000" ATTRS{consistent_dma_mask_bits}=="32" ATTRS{dma_mask_bits}=="32" ATTRS{local_cpus}=="ff" ATTRS{device}=="0x0003" ATTRS{enable}=="1" ATTRS{msi_bus}=="" ATTRS{local_cpulist}=="0-7" ATTRS{vendor}=="0xdd01" ATTRS{subsystem_device}=="0x0020"
looking at parent device '/devices/pci0000:00/0000:00:0d.0': KERNELS=="0000:00:0d.0" SUBSYSTEMS=="pci" DRIVERS=="pcieport" ATTRS{irq}=="40" ATTRS{subsystem_vendor}=="0x10de" ATTRS{broken_parity_status}=="0" ATTRS{class}=="0x060400" ATTRS{consistent_dma_mask_bits}=="32" ATTRS{dma_mask_bits}=="32" ATTRS{local_cpus}=="ff" ATTRS{device}=="0x0378" ATTRS{enable}=="2" ATTRS{msi_bus}=="1" ATTRS{local_cpulist}=="0-7" ATTRS{vendor}=="0x10de" ATTRS{subsystem_device}=="0x0000"
looking at parent device '/devices/pci0000:00': KERNELS=="pci0000:00" SUBSYSTEMS=="" DRIVERS==""
VDR-test-cellar (SDB1): udevadm info -a -p $(udevadm info -q path -n /dev/dvb/adapter4/frontend0)
Udevadm info starts with the device specified by the devpath and then walks up the chain of parent devices. It prints for every device found, all possible attributes in the udev rules key format. A rule to match, can be composed by the attributes of the device and the attributes from one single parent device.
looking at device '/devices/pci0000:00/0000:00:0d.0/0000:02:00.0/dvb/dvb4.frontend0': KERNEL=="dvb4.frontend0" SUBSYSTEM=="dvb" DRIVER==""
looking at parent device '/devices/pci0000:00/0000:00:0d.0/0000:02:00.0': KERNELS=="0000:02:00.0" SUBSYSTEMS=="pci" DRIVERS=="DDBridge" ATTRS{irq}=="16" ATTRS{subsystem_vendor}=="0xdd01" ATTRS{broken_parity_status}=="0" ATTRS{class}=="0x048000" ATTRS{consistent_dma_mask_bits}=="32" ATTRS{dma_mask_bits}=="32" ATTRS{local_cpus}=="ff" ATTRS{device}=="0x0003" ATTRS{enable}=="1" ATTRS{msi_bus}=="" ATTRS{local_cpulist}=="0-7" ATTRS{vendor}=="0xdd01" ATTRS{subsystem_device}=="0x0020"
looking at parent device '/devices/pci0000:00/0000:00:0d.0': KERNELS=="0000:00:0d.0" SUBSYSTEMS=="pci" DRIVERS=="pcieport" ATTRS{irq}=="40" ATTRS{subsystem_vendor}=="0x10de" ATTRS{broken_parity_status}=="0" ATTRS{class}=="0x060400" ATTRS{consistent_dma_mask_bits}=="32" ATTRS{dma_mask_bits}=="32" ATTRS{local_cpus}=="ff" ATTRS{device}=="0x0378" ATTRS{enable}=="2" ATTRS{msi_bus}=="1" ATTRS{local_cpulist}=="0-7" ATTRS{vendor}=="0x10de" ATTRS{subsystem_device}=="0x0000"
looking at parent device '/devices/pci0000:00': KERNELS=="pci0000:00" SUBSYSTEMS=="" DRIVERS==""
Thanks for the suggestions though.
So now I'm looking for other ideas. Hows about blacklisting DDBridge and then modprobeing it before VDR starts? That way the FF will get FE0/0, and I assume the Cine S2 tuners will enumerate in ascending order.
Cheers Brian
On 19/08/2013 21:11, Brian-Imap wrote:
In this case, you can write an external program witch output the name when you match a front end of ddbridge : KERNEL=="dvb[0-9]*.frontend0", SUBSYSTEMS=="pci", DRIVERS=="DDBridge", PROGRAM="/your/program %k", NAME="%c"
Something like : if [ ! -a /path/frontendname1 ]; then echo frontendname1; exit; fi; same with frontendname2 and frontendname3
The kernel name of the device is available if needed (%k in the udev rule).
Marc.
On 8/19/2013 11:10 PM, Marc wrote:
Hi Marc, you've lost me.
If FE0/0 is a DDBridge tuner, and I make the FF card tuner FE0/0, then I still need to rename the DDBridge Tuner that was FE0/0 to another one within FE{1-3}/0. That means potentially overwriting the names of some of the other DDBridge tuners, and then renaming them later on too. Unfortunately the same rule will pop for all four DDBridge tuners, so I guess I must keep track of what I have already renamed.
Or I'm missing something about the logic to be used here.
Take this example: Aug 11 11:09:31 localhost vdr: [936] frontend 0/0 provides DVB-S,DVB-S2,DSS with QPSK ("STV090x Multistandard") Aug 11 11:09:31 localhost vdr: [936] frontend 1/0 provides DVB-C with QAM16,QAM32,QAM64,QAM128,QAM256 ("ST STV0297 DVB-C") Aug 11 11:09:31 localhost vdr: [936] frontend 2/0 provides DVB-S,DVB-S2,DSS with QPSK ("STV090x Multistandard") Aug 11 11:09:31 localhost vdr: [936] frontend 4/0 provides DVB-S,DVB-S2,DSS with QPSK ("STV090x Multistandard")
1. Rename FE1/0 to FE0/0 2. Rename FE0/0 .... I'm renaming the PCI device so it should rename the "Old" FE0/0 to FE 1/0 3. Rename FE2/0 to FE2/0. Should be OK, actually renaming the third DVB device to FE2/0. 4. Rename fourth DVB device to FE3/0
In this case the FF could be in any position
Cheers Brian
Serial number, assuming that field is used correctly in that device.
On Tue, Aug 20, 2013 at 9:48 AM, Brian-Imap Brian_Dorling@t-online.dewrote:
On 20/08/2013 18:48, Brian-Imap wrote:
That's what the external program is intended for. It will be launched for every tuner of the ddbridge. The example I give is basic, if the node of the first front end isn't already created, then echo the name of the first front end. If not, test the second node and do the same thing for all the 4 fronts end. Maybe you can use a better logic by passing some parameters.
Of course, this is possible only if the tuners of the ddbridge keep the same order but if would be weird if the driver doesn't use the same order every time (no module loading order at this level).
You still need a rule for the FF card because there are more node created for each adapter. Without a rule the number of this card could change too despite the rule for the ddbridge.
To avoid overwriting when a new tuner (without a udev rule) is added, perhaps you can start numbering at 10 or more if vdr can handle it.
That's a more standard way but according to the output of udevadm, there is only an empty DRIVER field after the ddbridge, nothing to write the rule witch differentiate the tuners.
Marc
Cheers Brian
On 20/08/2013 19:45, Marc wrote:
One more thing. Meanwhile, you can use the solution of blacklisting the dvb modules and manually load them before starting vdr. This solution should works but is not very stable: the modules name could change from time to time and you have to take care to not start vdr before all the front end are fully initialized.
Marc.
-
Arthur -
Brian-Imap -
Infonux -
Lars Hanisch -
Marc -
VDR User