Re: [vdr] Feature request for VDR => multi editing
OK ! I understood, sorry for the mismatch... Karim ... BTW: you should have started an all new thread for this, not "reply" to "VDR needs some way to detect new tuners on runtime..." and simply change the subject. Now these two threads are intertwinded... :-( Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Deactivate a Tuner
On 20/08/2013 19:45, Marc wrote:
On 20/08/2013 18:48, Brian-Imap 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.
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.
Or, hows about I just go in and rename the devices, same scheme every
time. I think that would work if I knew
how to differentiate between the 4 Cine S2 tuners, currently I dont
know how to do that.
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
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.
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Deactivate a Tuner
Serial number, assuming that field is used correctly in that device.
On Tue, Aug 20, 2013 at 9:48 AM, Brian-Imap wrote:
> On 8/20/2013 6:28 PM, Brian-Imap wrote:
>
> On 8/19/2013 11:10 PM, Marc wrote:
>
> 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/pci:00/:00:0d.0/: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/pci:00/:00:0d.0/: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/pci:00/:00:0d.0/: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/pci:00/:00:06.0/: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/pci:00/:00:0d.0/: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
> listvdr@linuxtv.orghttp://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
>
>
>
> ___
> vdr mailing
> listvdr@linuxtv.orghttp://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/pci:00/:00:0d.0/:02:00.0/dvb/dvb3.frontend0':
> KERNEL=="dvb3.frontend0"
> SUBSYSTEM=="dvb"
> DRIVER==""
>
> looking at parent device '/devices/pci:00/:00:0d.0/:02:00.0':
> KERNELS==":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/pci:00/:00:0d.0':
> KERNELS==":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}=="0x"
>
> looking at parent device '/devices/pci:00':
> KERNELS=="pci: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
Re: [vdr] Deactivate a Tuner
On 20/08/2013 18:48, Brian-Imap wrote:
On 8/20/2013 6:28 PM, Brian-Imap wrote:
On 8/19/2013 11:10 PM, Marc wrote:
On 19/08/2013 21:11, Brian-Imap 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/pci:00/:00:0d.0/:02:00.0/dvb/dvb3.frontend0':
KERNEL=="dvb3.frontend0"
SUBSYSTEM=="dvb"
DRIVER==""
looking at parent device
'/devices/pci:00/:00:0d.0/:02:00.0':
KERNELS==":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/pci:00/:00:0d.0':
KERNELS==":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}=="0x"
looking at parent device '/devices/pci:00':
KERNELS=="pci: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/pci:00/:00:0d.0/:02:00.0/dvb/dvb4.frontend0':
KERNEL=="dvb4.frontend0"
SUBSYSTEM=="dvb"
DRIVER==""
looking at parent device
'/devices/pci:00/:00:0d.0/:02:00.0':
KERNELS==":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/pci:00/:00:0d.0':
KERNELS==":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}=="0x"
looking at parent device '/devices/pci:00':
KERNELS=="pci: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.
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.
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
Re: [vdr] Deactivate a Tuner
On 8/20/2013 6:28 PM, Brian-Imap wrote:
On 8/19/2013 11:10 PM, Marc wrote:
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/pci:00/:00:0d.0/: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/pci:00/:00:0d.0/: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/pci:00/:00:0d.0/: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/pci:00/:00:06.0/: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/pci:00/:00:0d.0/: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@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
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/pci:00/:00:0d.0/:02:00.0/dvb/dvb3.frontend0':
KERNEL=="dvb3.frontend0"
SUBSYSTEM=="dvb"
DRIVER==""
looking at parent device
'/devices/pci:00/:00:0d.0/:02:00.0':
KERNELS==":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/pci:00/:00:0d.0':
KERNELS==":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}=="0x"
looking at parent device '/devices/pci:00':
KERNELS=="pci: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/pci:00/:00:0d.0/:02:00.0/dvb/dvb4.frontend0':
KERNEL=="dvb4.frontend0"
SUBSYSTEM=="dvb"
DRIVER==""
looking at parent dev
Re: [vdr] Deactivate a Tuner
On 8/19/2013 11:10 PM, Marc wrote:
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/pci:00/:00:0d.0/: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/pci:00/:00:0d.0/: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/pci:00/:00:0d.0/: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/pci:00/:00:06.0/: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/pci:00/:00:0d.0/: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@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
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/pci:00/:00:0d.0/:02:00.0/dvb/dvb3.frontend0':
KERNEL=="dvb3.frontend0"
SUBSYSTEM=="dvb"
DRIVER==""
looking at parent device
'/devices/pci:00/:00:0d.0/:02:00.0':
KERNELS==":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/pci:00/:00:0d.0':
KERNELS==":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}=="0x"
looking at parent device '/devices/pci:00':
KERNELS=="pci: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/pci:00/:00:0d.0/:02:00.0/dvb/dvb4.frontend0':
KERNEL=="dvb4.frontend0"
SUBSYSTEM=="dvb"
DRIVER==""
looking at parent device
'/devices/pci:00/:00:0d.0/00
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On Tue, Aug 20, 2013 at 1:20 AM, Manuel Reimer wrote: >NUMADAPTERS=3 > >>while [[ `find /dev/dvb -name 'adapter*' | wc -l` -lt $NUMADAPTERS >> ]]; do sleep 1; done >>runvdr ... >> >> could be used to count the number of adapters, and check that number in >> a loop >> against the expected number of adapters. >> > > This works for *one* system and only if the user manually sets the number > of adapters. How could this be done in a "automagic" way to allow users to > just plug the tuner and reboot? > I don't think you can automate that in a very reliable way, especially if you're using usb dvb devices and/or devices with field values that aren't set correctly. The only reliable way is to have the user define how many dvb devices are expected to init, and then wait for that to happen during boot. Something like: dvbcount=3 until (($dvbcount == $(ls -d /dev/dvb/adapter* |wc -l))); do sleep 1; done Additionally I would add a timeout if you plan on doing this during boot: dvbcount=3 timeout=60 until (($dvbcount == $(ls -d /dev/dvb/adapter* |wc -l) || timeout == 0)); do sleep 1; ((timeout--)); done ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channel IDs - DVB-C and IPTV
Hey Michael, glad to here that you got it work. So after using correct SID, NID and TID, still no EPG from EIT? Since you may not be the only user in Austria, using A1TV's IPTV channels, you may post the proven channel.conf entries with correct SID, NID and TID at vdr-portal.de. === Kind regards fnu > -Original Message- > From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf > Of Michael Frank > Sent: Tuesday, August 20, 2013 12:03 PM > To: VDR Mailing List > Subject: Re: [vdr] Channel IDs - DVB-C and IPTV > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > @fnu > > Thank you Frank for your kind help. Analyzing the streams was the first > step towards success. > > Finally I found the reason why RID would not work with my IPTV-Channels. > It's very simple: apparently SVDRP does not like an NID of zero. As soon > as you set it to 1 the RID can be used as well. > > The import of EPG-data from epgdata.com is now working fine for my IPTV- > Channels from a1tv. > > Thanky again > > Kind regards > Michael > > > Am 2013-08-19 17:35, schrieb fnu: > > Hey Michael, > > > > since I dealt somewhat intensiv with IPTV channels the last days, > > German T-Home Entertain, see vdr-portal, I was able to check this > quickly. > > > > DVB-S/S2: > > === > > vdr2-vdr:/home/vdr> svdrpsend lstc 1 > > 220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:12:24 2013; > > UTF-8 > > 250 1 Das Erste > > HD;ARD:11494:HC23M5O35S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3;51 > > 06=deu > > @106:5104;5105=deu:0:10301:1:1019:0 > > 221 vdr2 closing connection > > === > > vdr2-vdr:/home/vdr> svdrpsend lstc S19.2E-1-1019-10301-0 > > 220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:30:30 2013; > > UTF-8 > > 250 1 Das Erste > > HD;ARD:11494:HC23M5O35S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3;51 > > 06=deu > > @106:5104;5105=deu:0:10301:1:1019:0 > > 221 vdr2 closing connection > > === > > IPTV: > > === > > vdr2-vdr:/home/vdr> svdrpsend lstc 120 > > 220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:13:16 2013; > > UTF-8 > > 250 120 Das Erste > > HD;IPTV:110:S=0|P=0|F=UDP|U=239.35.10.1|A=1:I:0:256=27:257=deu@3;2 > > 58=AC3 > > @106:259:0:10301:1:10301:0 > > 221 vdr2 closing connection > > === > > vdr2-vdr:/home/vdr> svdrpsend lstc I-1-10301-10301-0 > > 220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:13:24 2013; > > UTF-8 > > 250 120 Das Erste > > HD;IPTV:110:S=0|P=0|F=UDP|U=239.35.10.1|A=1:I:0:256=27:257=deu@3;2 > > 58=AC3 > > @106:259:0:10301:1:10301:0 > > 221 vdr2 closing connection > > === > > > > So SVDRP does work proberly here. > > > > I also read this RID hint to give channels a unique touch, but I think > > it might be the better idea to find out correct SID, NID, TID for > > these channels and leave RID=0. I needed to do this, to get the few > > EPG info out of that streams. Luckily I had strong support by plugin's > > author, Rolf Ahrenberg, thanks again for that here. > > > > In short do something like this, I did show my own example from above: > > > > === > > #/> /usr/bin/multicat -u -d 162000 @23.35.10.1:1 ./dump.ts === > > Dump 1min of that stream, 81=5min, 162000=1min, > > 81000=30sek === Check the dump: > > === > > #/> dvbsnoop -s ts -if ./dump.ts -tssubdecode -hexdumpbuffer 0x12 | > > grep -m1 > > -A8 Service_ID | grep _ID > > === > > You will get something like this, that shows SID, NID and TID: > > === > > Service_ID: 10301 (0x283d) [= --> refers to PMT program_number] > > Transport_stream_ID: 10301 (0x283d) > > Original_network_ID: 1 (0x0001) [= Astra Satellite Network 19,2-E | > > Soci-t- Europ-enne des Satellites] > > === > > === > > Kind regards > > Frank > > > >> -Original Message- > >> From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On > >> Behalf Of Michael Frank > >> Sent: Monday, August 19, 2013 4:52 PM > >> To: VDR Mailing List > >> Subject: [vdr] Channel IDs - DVB-C and IPTV > >> > > Hello, > > > > I have a VDR (2.0.2) setup with yaVDR's distribution using a Sundtek > > stick to watch DVB-C. Additionally I want to add a part of a1tv > > (Austrian IPTV) to the setup. While watching IPTV does not pose any > > problems, getting the EPG into these IPTV-Channels does. > > > > a1tv does not provide EPG via the data stream so I added epgdata.com > > service to the VDR. This again is working fine as far as the DVB-C > > Channels are concerned. As for the IPTV it does not work at all. > > > > So, finally, here is the problem: > > > > In order to get EPG data into a channel one has to map a given > > Channel- EPG-ID with VDR's Channel-ID. Unfortunately many channels of > > a1tv provide the same Channel-ID on VDR. So I tried to modify the RID > > of these channels to get a unique Channel-ID (as mentioned in the > > manual files). Whem sending the EPG to VDR via PUTE the command does > > not accept the RID-extended Channel-ID. > > > > Example for DVB-C (working): > > someone@htpc-vdr:~$ svdrpsend lstc 50
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On Tue, 20 Aug 2013 10:12:25 +0200 Klaus Schmidinger wrote: > I wouldn't like to add a dependency to libudev. Why not? ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Channel IDs - DVB-C and IPTV
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 @fnu Thank you Frank for your kind help. Analyzing the streams was the first step towards success. Finally I found the reason why RID would not work with my IPTV-Channels. It's very simple: apparently SVDRP does not like an NID of zero. As soon as you set it to 1 the RID can be used as well. The import of EPG-data from epgdata.com is now working fine for my IPTV-Channels from a1tv. Thanky again Kind regards Michael Am 2013-08-19 17:35, schrieb fnu: > Hey Michael, > > since I dealt somewhat intensiv with IPTV channels the last days, German > T-Home Entertain, see vdr-portal, I was able to check this quickly. > > DVB-S/S2: > === > vdr2-vdr:/home/vdr> svdrpsend lstc 1 > 220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:12:24 2013; UTF-8 > 250 1 Das Erste > HD;ARD:11494:HC23M5O35S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3;5106=deu > @106:5104;5105=deu:0:10301:1:1019:0 > 221 vdr2 closing connection > === > vdr2-vdr:/home/vdr> svdrpsend lstc S19.2E-1-1019-10301-0 > 220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:30:30 2013; UTF-8 > 250 1 Das Erste > HD;ARD:11494:HC23M5O35S1:S19.2E:22000:5101=27:5102=deu@3,5103=mis@3;5106=deu > @106:5104;5105=deu:0:10301:1:1019:0 > 221 vdr2 closing connection > === > IPTV: > === > vdr2-vdr:/home/vdr> svdrpsend lstc 120 > 220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:13:16 2013; UTF-8 > 250 120 Das Erste > HD;IPTV:110:S=0|P=0|F=UDP|U=239.35.10.1|A=1:I:0:256=27:257=deu@3;258=AC3 > @106:259:0:10301:1:10301:0 > 221 vdr2 closing connection > === > vdr2-vdr:/home/vdr> svdrpsend lstc I-1-10301-10301-0 > 220 vdr2 SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 17:13:24 2013; UTF-8 > 250 120 Das Erste > HD;IPTV:110:S=0|P=0|F=UDP|U=239.35.10.1|A=1:I:0:256=27:257=deu@3;258=AC3 > @106:259:0:10301:1:10301:0 > 221 vdr2 closing connection > === > > So SVDRP does work proberly here. > > I also read this RID hint to give channels a unique touch, but I think it > might be the better idea to find out correct SID, NID, TID for these > channels and leave RID=0. I needed to do this, to get the few EPG info out > of that streams. Luckily I had strong support by plugin's author, Rolf > Ahrenberg, thanks again for that here. > > In short do something like this, I did show my own example from above: > > === > #/> /usr/bin/multicat -u -d 162000 @23.35.10.1:1 ./dump.ts > === > Dump 1min of that stream, 81=5min, 162000=1min, 81000=30sek > === > Check the dump: > === > #/> dvbsnoop -s ts -if ./dump.ts -tssubdecode -hexdumpbuffer 0x12 | grep -m1 > -A8 Service_ID | grep _ID > === > You will get something like this, that shows SID, NID and TID: > === > Service_ID: 10301 (0x283d) [= --> refers to PMT program_number] > Transport_stream_ID: 10301 (0x283d) > Original_network_ID: 1 (0x0001) [= Astra Satellite Network 19,2-E | > Soci-t- Europ-enne des Satellites] > === > === > Kind regards > Frank > >> -Original Message- >> From: vdr-boun...@linuxtv.org [mailto:vdr-boun...@linuxtv.org] On Behalf >> Of Michael Frank >> Sent: Monday, August 19, 2013 4:52 PM >> To: VDR Mailing List >> Subject: [vdr] Channel IDs - DVB-C and IPTV >> > Hello, > > I have a VDR (2.0.2) setup with yaVDR's distribution using a Sundtek > stick to watch DVB-C. Additionally I want to add a part of a1tv > (Austrian IPTV) to the setup. While watching IPTV does not pose any > problems, getting the EPG into these IPTV-Channels does. > > a1tv does not provide EPG via the data stream so I added epgdata.com > service to the VDR. This again is working fine as far as the DVB-C > Channels are concerned. As for the IPTV it does not work at all. > > So, finally, here is the problem: > > In order to get EPG data into a channel one has to map a given Channel- > EPG-ID with VDR's Channel-ID. Unfortunately many channels of a1tv > provide the same Channel-ID on VDR. So I tried to modify the RID of > these channels to get a unique Channel-ID (as mentioned in the manual > files). Whem sending the EPG to VDR via PUTE the command does not accept > the RID-extended Channel-ID. > > Example for DVB-C (working): > someone@htpc-vdr:~$ svdrpsend lstc 50 > 220 htpc-vdr SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 16:41:33 2013; > UTF-8 > 250 50 > HSE24;UPC:33:C0M256:C:6900:4201=2:4211=deu@3:4301:0:4012:1537:4:0 > 221 htpc-vdr closing connection > someone@htpc-vdr:~$ svdrpsend lstc C-1537-4-4012-0 > 220 htpc-vdr SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 16:43:54 2013; > UTF-8 > 250 50 > HSE24;UPC:33:C0M256:C:6900:4201=2:4211=deu@3:4301:0:4012:1537:4:0 > 221 htpc-vdr closing connection > someone@htpc-vdr:~$ > > Example for IPTV: > someone@htpc-vdr:~$ svdrpsend lstc 53 > 220 htpc-vdr SVDRP VideoDiskRecorder 2.0.2; Mon Aug 19 16:45:19 2013; > UTF-8 > 250 53 SF 1 HD;A1 Telekom > Austria:8160:S=1|P=0|F=UDP|U=239.2.24.27|A=8208:I:27500:32=27:34=ola@3;3 > 3=deu@106:41:0:1:0:0:17 > 221 htpc-vdr closing connection > someone@htpc-vdr:~$ svdrpsend lstc
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On 20.08.2013 10:42, Klaus Schmidinger wrote: > On 20.08.2013 10:20, Manuel Reimer wrote: > >On 08/20/2013 10:12 AM, Klaus Schmidinger wrote: > >>>So my question to Klaus: Is there something like this planned or would > >>>a patch be accepted which adds a feature like this? As far as I know a > >>>new dependency (libudev) would be needed. > >> > >>I wouldn't like to add a dependency to libudev. > > > >So how could an alternative approach look like? Maybe it could work with > >"inotify" to see when new devices are added below /dev, but I think this > >will also require new dependencies. > > > >The easiest way may be: Call the existing code for finding the tuners not > >only once but every X seconds. > > > >> NUMADAPTERS=3 > >> while [[ `find /dev/dvb -name 'adapter*' | wc -l` -lt $NUMADAPTERS > >>]]; do sleep 1; done > >> runvdr ... > >> > >>could be used to count the number of adapters, and check that number in > >>a loop > >>against the expected number of adapters. > > > >This works for *one* system and only if the user manually sets the number of > >adapters. How could this be done in a "automagic" way to allow users to just > >plug the tuner and reboot? > > As I wrote before, VDR needs all devices to be ready when it starts, otherwise > any configuration parameters that refer to "device numbers" might not work. You say "All devices have to be there, because there can be configuration by device-number". Me thinks, why configuration by device-number? Configuration by index isn't always the best, there could be a configuration by name/UID or something link that. Sure you get different problems, so it's a judgement call what set of problems is the lesser evil. For e.g. where you could formerly just swap a card and it still "just worked", you then would have to configure something. BUT adding another card would not mangle the configuration regardless of the new card getting ordered before the older card or not. I think a named configuration is a requirement for proper "hotplugability", USB devices for e.g. are inherently hotplugable. It's basically the same thing we nowadays have with networking. In the past the first found NIC was eth0. Assuming there is only 1 NIC in a computer, in the past it "just worked" when you swapped the NIC. Nowadys you have to do something, because by default udev will (re-)name it eth1 and eth0 goes MIA. BUT adding a second NIC is guranteed to not mangle eth0, even if the kernel would initially name it eth0, udev will fix that. So there is pro/contra for index vs. name based configuration, i personally prefer name base configuration. It's usually easier to debug and behaves deterministicly. Especially as device-discoverty/-initialization is NOT guranteed to be deterministic and/or long-term stable. Which means even if something works(/is deterministic) with kernel X, there is no guarantee that X+1 with behave identical. And when implemented with aliases like "device0" (or aliased in such a way (if possible) that current configuration files are still valid) the configuration by index would still be possible, so the user could even choose which set of problems they want (I.E. Into which foot they prefer to shoot themselves). ;-) -- Matthias ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On 20.08.2013 10:20, Manuel Reimer wrote: On 08/20/2013 10:12 AM, Klaus Schmidinger wrote: So my question to Klaus: Is there something like this planned or would a patch be accepted which adds a feature like this? As far as I know a new dependency (libudev) would be needed. I wouldn't like to add a dependency to libudev. So how could an alternative approach look like? Maybe it could work with "inotify" to see when new devices are added below /dev, but I think this will also require new dependencies. The easiest way may be: Call the existing code for finding the tuners not only once but every X seconds. NUMADAPTERS=3 while [[ `find /dev/dvb -name 'adapter*' | wc -l` -lt $NUMADAPTERS ]]; do sleep 1; done runvdr ... could be used to count the number of adapters, and check that number in a loop against the expected number of adapters. This works for *one* system and only if the user manually sets the number of adapters. How could this be done in a "automagic" way to allow users to just plug the tuner and reboot? As I wrote before, VDR needs all devices to be ready when it starts, otherwise any configuration parameters that refer to "device numbers" might not work. So I guess you'll have to figure out some way of waiting for all devices to be ready before starting VDR. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On 08/20/2013 10:12 AM, Klaus Schmidinger wrote: So my question to Klaus: Is there something like this planned or would a patch be accepted which adds a feature like this? As far as I know a new dependency (libudev) would be needed. I wouldn't like to add a dependency to libudev. So how could an alternative approach look like? Maybe it could work with "inotify" to see when new devices are added below /dev, but I think this will also require new dependencies. The easiest way may be: Call the existing code for finding the tuners not only once but every X seconds. NUMADAPTERS=3 while [[ `find /dev/dvb -name 'adapter*' | wc -l` -lt $NUMADAPTERS ]]; do sleep 1; done runvdr ... could be used to count the number of adapters, and check that number in a loop against the expected number of adapters. This works for *one* system and only if the user manually sets the number of adapters. How could this be done in a "automagic" way to allow users to just plug the tuner and reboot? Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On 19.08.2013 23:19, Manuel Reimer wrote: Hello, with event based init systems (in my case systemd) it seems to become a big issue to startup VDR. If you install VDR on a SSD device, then startup gets *really* fast. Sometimes that fast, that VDR starts before all devices are initialized. I've asked in the systemd mailinglist, if there is any way to get around this: http://lists.freedesktop.org/archives/systemd-devel/2013-August/012716.html The result: The "daemon" (VDR) needs some way to detect devices while runtime. So my question to Klaus: Is there something like this planned or would a patch be accepted which adds a feature like this? As far as I know a new dependency (libudev) would be needed. I wouldn't like to add a dependency to libudev. Besides, VDR assumes that all devices are "there" when it starts, mostly because some configuration details (like device bonding or DiSEqC) rely on the fact that the devices appear in a given, reproducible sequence. "udev" rules can be used to assign particular adapter numbers to the devices. Maybe there is also some mechanism to make it wait until all devices have been initialized. As a very simple approach something like NUMADAPTERS=3 while [[ `find /dev/dvb -name 'adapter*' | wc -l` -lt $NUMADAPTERS ]]; do sleep 1; done runvdr ... could be used to count the number of adapters, and check that number in a loop against the expected number of adapters. Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Feature request for VDR => multi editing
On 08/20/2013 09:49 AM, Klaus Schmidinger wrote: BTW: you should have started an all new thread for this, not "reply" to "VDR needs some way to detect new tuners on runtime..." and simply change the subject. Now these two threads are intertwinded... :-( X-Mailer: Microsoft Office Outlook 12.0 That says it all. AFAIK threaded view is impossible with this MUA. Greetings, Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Feature request for VDR => multi editing
On 19.08.2013 23:52, Karim wrote: Hi Klaus, I record many movies, shows and series with VDR => then I make a lot of editing. Unfortunately, VDR allows only one editing at a time. Is it possible to improve this feature ? I mean VDR could store all demands in a queue, and launch them one by one, until the last editing. This should improve greatly the usability of VDR ! This is on my list. BTW: you should have started an all new thread for this, not "reply" to "VDR needs some way to detect new tuners on runtime..." and simply change the subject. Now these two threads are intertwinded... :-( Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On 08/20/2013 09:40 AM, André Weidemann wrote: Add a line like this after loading the required modules: /sbin/modprobe dvb /sbin/udevadm settle --timeout=30 then start up vdr. Everything should be fine since udevadm only returns after all actions regarding the module load are settled. This is *wrong*. It works on HDD drives but may fail on SSD drives as the system may boot up faster than the DVB devices need to initialize. udevadm settle only waits for the stuff, the system *currently* knows. A slow tuner may be found after "udevadm settle". Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] VDR needs some way to detect new tuners on runtime...
On 19.08.2013 23:19, Manuel Reimer wrote: Hello, with event based init systems (in my case systemd) it seems to become a big issue to startup VDR. If you install VDR on a SSD device, then startup gets *really* fast. Sometimes that fast, that VDR starts before all devices are initialized. There might be an easier way to get around this. I assume you load your module in the runvdr or a similar script at boot time?! Add a line like this after loading the required modules: /sbin/modprobe dvb /sbin/udevadm settle --timeout=30 then start up vdr. Everything should be fine since udevadm only returns after all actions regarding the module load are settled. Regards André ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Feature request for VDR => multi editing
On ma, 2013-08-19 at 23:52 +0200, Karim wrote: > Hi Klaus, > > I record many movies, shows and series with VDR => then I make a lot of > editing. > Unfortunately, VDR allows only one editing at a time. > > Is it possible to improve this feature ? I mean VDR could store all demands > in a queue, and launch them one by one, until the last editing. I wrote such a patch ~10 years ago. Last version is for vdr 1.6.0, I have no idea if it applies to latest versions: http://phivdr.dyndns.org/vdr/vdr-1.6.0-CutterQueue_and_CutterAutoDelete.patch I think it was later added to some other patch set, maybe google can find more recent version. > This should improve greatly the usability of VDR ! > > Thank you ! > > Regards. > Karim > > > ___ > 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
Re: [vdr] VDR needs some way to detect new tuners on runtime...
Manuel Reimer writes: > Hello, > > with event based init systems (in my case systemd) it seems to become > a big issue to startup VDR. > > If you install VDR on a SSD device, then startup gets *really* > fast. Sometimes that fast, that VDR starts before all devices are > initialized. > > I've asked in the systemd mailinglist, if there is any way to get > around this: > > http://lists.freedesktop.org/archives/systemd-devel/2013-August/012716.html > > The result: The "daemon" (VDR) needs some way to detect devices while > runtime. > > So my question to Klaus: Is there something like this planned or would > a patch be accepted which adds a feature like this? As far as I know a > new dependency (libudev) would be needed. Hi, You should be able to achieve this using the dynamite patch and plugin. I would definitey love to see its features merged in main vdr btw :) -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
