[vdr] Deactivate a Tuner

Marc vdr2 at ekass.net
Mon Aug 19 23:10:48 CEST 2013


On 19/08/2013 21:11, Brian-Imap wrote:
> On 8/18/2013 8:15 PM, Marc wrote:
>> On 18/08/2013 19:27, 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==""
>>>
>> You can use this command :
>> udevadm info -a -p $(udevadm info -q path -n /dev/your/path)
>>
>> to get the complete tree and watch if you can differentiate your 
>> front end with one or more attributes of the subsystems.
>>
>> Marc.
>>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> vdr mailing list
>>> vdr at linuxtv.org
>>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>>
>>
>>
>> _______________________________________________
>> vdr mailing list
>> vdr at linuxtv.org
>> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
> 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==""
>
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.
>
> 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
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.linuxtv.org/pipermail/vdr/attachments/20130819/467f8fcd/attachment.html>


More information about the vdr mailing list