<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 20/08/2013 18:48, Brian-Imap wrote:<br>
    </div>
    <blockquote cite="mid:52139DC4.7000005@192.168.95.249" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <div class="moz-cite-prefix">On 8/20/2013 6:28 PM, Brian-Imap
        wrote:<br>
      </div>
      <blockquote cite="mid:5213992D.9020609@192.168.95.249" type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        <div class="moz-cite-prefix">On 8/19/2013 11:10 PM, Marc wrote:<br>
        </div>
        <blockquote cite="mid:521289D8.2060405@ekass.net" type="cite">
          <meta content="text/html; charset=ISO-8859-1"
            http-equiv="Content-Type">
          <div class="moz-cite-prefix">On 19/08/2013 21:11, Brian-Imap
            wrote:<br>
          </div>
          <blockquote cite="mid:52126DC4.6080808@192.168.95.249"
            type="cite">
            <meta content="text/html; charset=ISO-8859-1"
              http-equiv="Content-Type">
            Hi,<br>
            well Its exactly what I was doing, and I cant see a
            difference. Here an example of two of the Cine S2 Tuners:<br>
            <br>
            VDR-test-cellar (SDB1): udevadm info -a -p $(udevadm info -q
            path -n /dev/dvb/adapter3/frontend0)<br>
            <br>
            Udevadm info starts with the device specified by the devpath
            and then<br>
            walks up the chain of parent devices. It prints for every
            device<br>
            found, all possible attributes in the udev rules key format.<br>
            A rule to match, can be composed by the attributes of the
            device<br>
            and the attributes from one single parent device.<br>
            <br>
              looking at device
            '/devices/pci0000:00/0000:00:0d.0/0000:02:00.0/dvb/dvb3.frontend0':<br>
                KERNEL=="dvb3.frontend0"<br>
                SUBSYSTEM=="dvb"<br>
                DRIVER==""<br>
            <br>
              looking at parent device
            '/devices/pci0000:00/0000:00:0d.0/0000:02:00.0':<br>
                KERNELS=="0000:02:00.0"<br>
                SUBSYSTEMS=="pci"<br>
                DRIVERS=="DDBridge"<br>
                ATTRS{irq}=="16"<br>
                ATTRS{subsystem_vendor}=="0xdd01"<br>
                ATTRS{broken_parity_status}=="0"<br>
                ATTRS{class}=="0x048000"<br>
                ATTRS{consistent_dma_mask_bits}=="32"<br>
                ATTRS{dma_mask_bits}=="32"<br>
                ATTRS{local_cpus}=="ff"<br>
                ATTRS{device}=="0x0003"<br>
                ATTRS{enable}=="1"<br>
                ATTRS{msi_bus}==""<br>
                ATTRS{local_cpulist}=="0-7"<br>
                ATTRS{vendor}=="0xdd01"<br>
                ATTRS{subsystem_device}=="0x0020"<br>
            <br>
              looking at parent device
            '/devices/pci0000:00/0000:00:0d.0':<br>
                KERNELS=="0000:00:0d.0"<br>
                SUBSYSTEMS=="pci"<br>
                DRIVERS=="pcieport"<br>
                ATTRS{irq}=="40"<br>
                ATTRS{subsystem_vendor}=="0x10de"<br>
                ATTRS{broken_parity_status}=="0"<br>
                ATTRS{class}=="0x060400"<br>
                ATTRS{consistent_dma_mask_bits}=="32"<br>
                ATTRS{dma_mask_bits}=="32"<br>
                ATTRS{local_cpus}=="ff"<br>
                ATTRS{device}=="0x0378"<br>
                ATTRS{enable}=="2"<br>
                ATTRS{msi_bus}=="1"<br>
                ATTRS{local_cpulist}=="0-7"<br>
                ATTRS{vendor}=="0x10de"<br>
                ATTRS{subsystem_device}=="0x0000"<br>
            <br>
              looking at parent device '/devices/pci0000:00':<br>
                KERNELS=="pci0000:00"<br>
                SUBSYSTEMS==""<br>
                DRIVERS==""<br>
            <br>
            VDR-test-cellar (SDB1): udevadm info -a -p $(udevadm info -q
            path -n /dev/dvb/adapter4/frontend0)<br>
            <br>
            Udevadm info starts with the device specified by the devpath
            and then<br>
            walks up the chain of parent devices. It prints for every
            device<br>
            found, all possible attributes in the udev rules key format.<br>
            A rule to match, can be composed by the attributes of the
            device<br>
            and the attributes from one single parent device.<br>
            <br>
              looking at device
            '/devices/pci0000:00/0000:00:0d.0/0000:02:00.0/dvb/dvb4.frontend0':<br>
                KERNEL=="dvb4.frontend0"<br>
                SUBSYSTEM=="dvb"<br>
                DRIVER==""<br>
            <br>
              looking at parent device
            '/devices/pci0000:00/0000:00:0d.0/0000:02:00.0':<br>
                KERNELS=="0000:02:00.0"<br>
                SUBSYSTEMS=="pci"<br>
                DRIVERS=="DDBridge"<br>
                ATTRS{irq}=="16"<br>
                ATTRS{subsystem_vendor}=="0xdd01"<br>
                ATTRS{broken_parity_status}=="0"<br>
                ATTRS{class}=="0x048000"<br>
                ATTRS{consistent_dma_mask_bits}=="32"<br>
                ATTRS{dma_mask_bits}=="32"<br>
                ATTRS{local_cpus}=="ff"<br>
                ATTRS{device}=="0x0003"<br>
                ATTRS{enable}=="1"<br>
                ATTRS{msi_bus}==""<br>
                ATTRS{local_cpulist}=="0-7"<br>
                ATTRS{vendor}=="0xdd01"<br>
                ATTRS{subsystem_device}=="0x0020"<br>
            <br>
              looking at parent device
            '/devices/pci0000:00/0000:00:0d.0':<br>
                KERNELS=="0000:00:0d.0"<br>
                SUBSYSTEMS=="pci"<br>
                DRIVERS=="pcieport"<br>
                ATTRS{irq}=="40"<br>
                ATTRS{subsystem_vendor}=="0x10de"<br>
                ATTRS{broken_parity_status}=="0"<br>
                ATTRS{class}=="0x060400"<br>
                ATTRS{consistent_dma_mask_bits}=="32"<br>
                ATTRS{dma_mask_bits}=="32"<br>
                ATTRS{local_cpus}=="ff"<br>
                ATTRS{device}=="0x0378"<br>
                ATTRS{enable}=="2"<br>
                ATTRS{msi_bus}=="1"<br>
                ATTRS{local_cpulist}=="0-7"<br>
                ATTRS{vendor}=="0x10de"<br>
                ATTRS{subsystem_device}=="0x0000"<br>
            <br>
              looking at parent device '/devices/pci0000:00':<br>
                KERNELS=="pci0000:00"<br>
                SUBSYSTEMS==""<br>
                DRIVERS==""<br>
            <br>
          </blockquote>
          In this case, you can write an external program witch output
          the name when you match a front end of ddbridge :<br>
          KERNEL=="dvb[0-9]*.frontend0", SUBSYSTEMS=="pci",
          DRIVERS=="DDBridge", PROGRAM="/your/program %k", NAME="%c"<br>
          <br>
          Something like :<br>
          if [ ! -a /path/frontendname1 ]; then echo frontendname1;
          exit; fi;<br>
          same with frontendname2 and frontendname3<br>
          <br>
          The kernel name of the device is available if needed (%k in
          the udev rule).<br>
          <br>
          Marc.</blockquote>
        Hi Marc,<br>
        you've lost me.  <br>
        <br>
        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 <br>
        was FE0/0 to another one within FE{1-3}/0. That means
        potentially overwriting the names of some of the other DDBridge<br>
        tuners, and then renaming them later on too.<br>
        Unfortunately the same rule will pop for all four DDBridge
        tuners, so I guess I must keep track of what I have already
        renamed.<br>
      </blockquote>
    </blockquote>
    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.<br>
    <br>
    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).<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    <blockquote cite="mid:52139DC4.7000005@192.168.95.249" type="cite">
      Or, hows about I just go in and rename the devices, same scheme
      every time.  I think that would work if I knew<br>
      how to differentiate between the 4 Cine S2 tuners, currently I
      dont know how to do that.<br>
      <br>
    </blockquote>
    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.<br>
    <br>
    Marc<br>
    <br>
    <blockquote cite="mid:52139DC4.7000005@192.168.95.249" type="cite">
      Cheers Brian<br>
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>