Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Klaus Schmidinger]

On 06.04.2010 14:07, Teemu Rantanen wrote:
> Hi,
> 
> the right way, of course, is to fix the driver, and make vdr check what
> device can do. I'm glad Petri had time to test it, and I hope to see the
> patch in next version of vdr. But I couldn't use the driver patch even
> if I wanted to patch kernel myself, as I actually have 3 devices with
> TDA10023 frontend, and only one of them is "reddo" :-)

Well, as I said, then the driver needs to detect which one is the "reddo"
and only clear the FE_CAN_QAM256 for that particular one.

> But i'm afraid my time for this project just run out. I'll continue
> later if/when the reddo driver patch arrives, I will test it, but until
> then I'll have to manage with the plugin, even if it crashes or not at
> exit(). I'll make an empty plugin with an empty hook, and if it still
> crashes at exit() it's not my fault :-)

I'll be glad to apply any fix to the core VDR code you can come up with.

> One more thought. Would it be possible to add vendor/product id as a
> method for cDevice (as well as the utility method for filename->id). And

First of all somebody should clarify the names.
Is it idVendor or subsystem_vendor?

> would it be possible (for a plugin) to manage device feature list and
> remove QAM256 from the reddo device. This way the plugin wouldn't have
> to actually do anything anymore when vdr is running, only fix this one
> time at plugin startup, and everything else would work 100% the same way
> before/after the driver is changed.

With a properly working driver you won't even need this at all ;-)

> Even though this isn't the right
> way, but we aren't living in a perfect world :-)

I'm afraid that would only take the pressure off of fixing the driver.

> 2010/4/5 Klaus Schmidinger  >
> 
> 
> Well, then the driver needs to make a finer distinction and *properly*
> set FE_CAN_QAM256.
> 
> 
> 
> 
> ___
> 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] Restricting a particular dvb card from tuning to channels with a selected modulation

[Teemu Rantanen]

Hi,

the right way, of course, is to fix the driver, and make vdr check what
device can do. I'm glad Petri had time to test it, and I hope to see the
patch in next version of vdr. But I couldn't use the driver patch even if I
wanted to patch kernel myself, as I actually have 3 devices with TDA10023
frontend, and only one of them is "reddo" :-)

But i'm afraid my time for this project just run out. I'll continue later
if/when the reddo driver patch arrives, I will test it, but until then I'll
have to manage with the plugin, even if it crashes or not at exit(). I'll
make an empty plugin with an empty hook, and if it still crashes at exit()
it's not my fault :-)

One more thought. Would it be possible to add vendor/product id as a method
for cDevice (as well as the utility method for filename->id). And would it
be possible (for a plugin) to manage device feature list and remove QAM256
from the reddo device. This way the plugin wouldn't have to actually do
anything anymore when vdr is running, only fix this one time at plugin
startup, and everything else would work 100% the same way before/after the
driver is changed. Even though this isn't the right way, but we aren't
living in a perfect world :-)

And thanks,


Teemu

2010/4/5 Klaus Schmidinger 

>
> Well, then the driver needs to make a finer distinction and *properly*
> set FE_CAN_QAM256.
>
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Klaus Schmidinger]

On 05.04.2010 20:55, Petri Helin wrote:
> On 04/05/2010 12:57 PM, Klaus Schmidinger wrote:
>> On 05.04.2010 00:55, Teemu Rantanen wrote:
>>   
>>> Hi,
>>>
>>> There's a new version of the patch implemented as a plugin. It seems to
>>> work, but there are few things to notice:
>>>
>>> - Plugin does not cache which devices are Reddo devices, instead it
>>> probes sysfs every time QAM256 channel is being tuned into (on any
>>> device). It would be nice if cDeviceHook added a mechanism for a hook to
>>> store context for each device. Hooking into device probe (like full
>>> feature card plugin does) would be much nicer way, but it would
>>> interfere with other plugins which need the same mechanism.
>>>  
>> The proper way of doing this is to check the modulation types
>> in cDvbDevice::ProvidesTransponder(), as in the attached patch (which
>> will
>> be part of VDR 1.7.15). If the "reddo" driver doesn't set the
>> FE_CAN_QAM_256
>> flag correctly, it needs to be fixed there.
>>
>>
> 
> I used your patch as an example and created a simple test patch for
> dvb-c (I think yours is for dvb-s(2) only) in order to test the
> approach.

You're right. I guess the attached version should cover all frontend types.

> I also disabled FE_CAN_QAM256 from the driver. After that VDR
> no longer used Reddo for QAM256 channels as expected. The approach is
> very limited: It disables QAM256 for the every TDA10023 frontend, not
> just for Reddo's,

Well, then the driver needs to make a finer distinction and *properly*
set FE_CAN_QAM256.

> and it doesn't make VDR to prefer Reddo for non QAM256
> channels, which would make sense in order to keep QAM256 channels
> available as much as possible.

First the driver needs to properly report whether a device can handle
a given modulation type. Then VDR can decide whether to use that
device for a channel requiring that modulation. *Then* we can talk
sparing such devices for recordings ;-)

Klaus
--- dvbdevice.c	2010/03/07 13:58:24	2.32
+++ dvbdevice.c	2010/04/05 20:13:05
@@ -886,12 +886,20 @@
 {
   if (!ProvidesSource(Channel->Source()))
  return false; // doesn't provide source
-  if (!cSource::IsSat(Channel->Source()))
- return DeviceHooksProvidesTransponder(Channel); // source is sufficient for non sat
   cDvbTransponderParameters dtp(Channel->Parameters());
-  if (frontendType == SYS_DVBS && dtp.System() == SYS_DVBS2)
+  if (dtp.System() == SYS_DVBS2 && frontendType == SYS_DVBS ||
+ dtp.Modulation() == QPSK && !(frontendInfo.caps & FE_CAN_QPSK) ||
+ dtp.Modulation() == QAM_16 && !(frontendInfo.caps & FE_CAN_QAM_16) ||
+ dtp.Modulation() == QAM_32 && !(frontendInfo.caps & FE_CAN_QAM_32) ||
+ dtp.Modulation() == QAM_64 && !(frontendInfo.caps & FE_CAN_QAM_64) ||
+ dtp.Modulation() == QAM_128 && !(frontendInfo.caps & FE_CAN_QAM_128) ||
+ dtp.Modulation() == QAM_256 && !(frontendInfo.caps & FE_CAN_QAM_256) ||
+ dtp.Modulation() == QAM_AUTO && !(frontendInfo.caps & FE_CAN_QAM_AUTO) ||
+ dtp.Modulation() == VSB_8 && !(frontendInfo.caps & FE_CAN_8VSB) ||
+ dtp.Modulation() == VSB_16 && !(frontendInfo.caps & FE_CAN_16VSB))
  return false; // requires modulation system which frontend doesn't provide
-  if (!Setup.DiSEqC || Diseqcs.Get(CardIndex() + 1, Channel->Source(), Channel->Frequency(), dtp.Polarization()))
+  if (!cSource::IsSat(Channel->Source()) ||
+ !Setup.DiSEqC || Diseqcs.Get(CardIndex() + 1, Channel->Source(), Channel->Frequency(), dtp.Polarization()))
  return DeviceHooksProvidesTransponder(Channel);
   return false;
 }
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Petri Helin]

On 04/05/2010 12:57 PM, Klaus Schmidinger wrote:

On 05.04.2010 00:55, Teemu Rantanen wrote:
   

Hi,

There's a new version of the patch implemented as a plugin. It seems to
work, but there are few things to notice:

- Plugin does not cache which devices are Reddo devices, instead it
probes sysfs every time QAM256 channel is being tuned into (on any
device). It would be nice if cDeviceHook added a mechanism for a hook to
store context for each device. Hooking into device probe (like full
feature card plugin does) would be much nicer way, but it would
interfere with other plugins which need the same mechanism.
 

The proper way of doing this is to check the modulation types
in cDvbDevice::ProvidesTransponder(), as in the attached patch (which will
be part of VDR 1.7.15). If the "reddo" driver doesn't set the FE_CAN_QAM_256
flag correctly, it needs to be fixed there.

   


I used your patch as an example and created a simple test patch for 
dvb-c (I think yours is for dvb-s(2) only) in order to test the 
approach. I also disabled FE_CAN_QAM256 from the driver. After that VDR 
no longer used Reddo for QAM256 channels as expected. The approach is 
very limited: It disables QAM256 for the every TDA10023 frontend, not 
just for Reddo's, and it doesn't make VDR to prefer Reddo for non QAM256 
channels, which would make sense in order to keep QAM256 channels 
available as much as possible. The patches are inline below:


--- dvbdevice.c.orig   2010-02-21 19:10:35.0 +0200
+++ dvbdevice.c   2010-04-05 17:20:06.080525344 +0300
@@ -872,8 +872,12 @@
 {
   if (!ProvidesSource(Channel->Source()))
  return false; // doesn't provide source
-  if (!cSource::IsSat(Channel->Source()))
+  if (!cSource::IsSat(Channel->Source())) {
+ cDvbTransponderParameters dtp(Channel->Parameters());
+ if (dtp.Modulation() == QAM_256 && !(frontendInfo.caps & 
FE_CAN_QAM_256))

+return false;
  return DeviceHooksProvidesTransponder(Channel); // source is 
sufficient for non sat

+  }
   cDvbTransponderParameters dtp(Channel->Parameters());
   if (frontendType == SYS_DVBS && dtp.System() == SYS_DVBS2)
  return false; // requires modulation system which frontend 
doesn't provide


--- v4l-dvb/linux/drivers/media/dvb/frontends/tda10023.c.orig  
 2010-04-05 15:28:22.605844128 +0300
+++ v4l-dvb/linux/drivers/media/dvb/frontends/tda10023.c   2010-04-05 
15:27:54.934343796 +0300

@@ -553,7 +553,7 @@
#endif
   .caps = 0x400 | //FE_CAN_QAM_4
  FE_CAN_QAM_16 | FE_CAN_QAM_32 | FE_CAN_QAM_64 |
- FE_CAN_QAM_128 | FE_CAN_QAM_256 |
+ FE_CAN_QAM_128 | //FE_CAN_QAM_256 |
  FE_CAN_FEC_AUTO
},

-Petri

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Klaus Schmidinger]

On 05.04.2010 18:14, Teemu Rantanen wrote:
> Ok, so the sysfs names of vendor/product are driver-dependent... All my
> usb devices have idVendor/idProduct even though only one of them is "Reddo".

I'm not saying that what the FuSI driver does is correct, either ;-)
Somebody with more knowledge should clarify this and fix the driver
that is faulty.

> Tried to create the hook on Initialize(), still crashes on exit().

Well, then I guess you'll need to do some debugging to find out what
really goes wrong here.

> Haven't tried your patch, because as far as I know the driver claims it
> can do QAM256, and even if that was disabled today it would take some
> time to get into all linux distributions... Btw it even claims to
> support QAM256 on the product package, but it still doesn't work. I
> guess that's the reason they are so inexpensive here...

At any rate, these things *must* be fixed in the driver!
Even if it takes a while for a fix to get into the main kernel source.

Klaus

> 2010/4/5 Klaus Schmidinger  >
> 
> On 05.04.2010 12:43, Teemu Rantanen wrote:
> > Hi,
> >
> > I tried also without delete cDeviceHook but it still crashed...
> 
> Please try creating the cReddoDeviceHook in
> cPluginDisableReddoQAM256::Initialize(),
> as suggested in PLUGINS.html.
> 
> > Well, the fixes are basically available in the plugin, as I copied the
> > probe method (and modified slightly to suit the plugin). Those are:
> > - The sysfs filenames are idVendor (subsystem_vendor) and idProduct
> > (subsystem_device)
> 
> This is what I get here:
> 
> r...@video:/home/kls/vdr/VDR > ls -l
> /sys/class/dvb/dvb0.frontend0/device/subsystem_*
> -r--r--r-- 1 root root 4096 2010-04-05 16:25
> /sys/class/dvb/dvb0.frontend0/device/subsystem_device
> -r--r--r-- 1 root root 4096 2010-04-05 16:25
> /sys/class/dvb/dvb0.frontend0/device/subsystem_vendor
> 
> r...@video:/home/kls/vdr/VDR > ls -l
> /sys/class/dvb/dvb0.frontend0/device/id*
> ls: cannot access /sys/class/dvb/dvb0.frontend0/device/id*: No such
> file or directory
> 
> Maybe a bug in the driver?
> 
> > - You need to set strtoul() base as 16 as the files don't have 0x in
> > front of the hex
> 
> r...@video:/home/kls/vdr/VDR > cat
> /sys/class/dvb/dvb0.frontend0/device/subsystem_device
> 0x
> r...@video:/home/kls/vdr/VDR > cat
> /sys/class/dvb/dvb0.frontend0/device/subsystem_vendor
> 0x13c2
> 
> Maybe the "reddo" driver behaves differently than the FuSi driver?
> 
> > What about making this an utility method in VDR? Give device file name
> > and return id...
> 
> Will do.
> 
> 
> Have you tried whether it works with my patch?
> In that case you wouldn't even need the whole plugin.
> 
> Klaus
> 
> 
> 
> 
> ___
> 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] Restricting a particular dvb card from tuning to channels with a selected modulation

[Teemu Rantanen]

Ok, so the sysfs names of vendor/product are driver-dependent... All my usb
devices have idVendor/idProduct even though only one of them is "Reddo".

Tried to create the hook on Initialize(), still crashes on exit().

Haven't tried your patch, because as far as I know the driver claims it can
do QAM256, and even if that was disabled today it would take some time to
get into all linux distributions... Btw it even claims to support QAM256 on
the product package, but it still doesn't work. I guess that's the reason
they are so inexpensive here...


Teemu

2010/4/5 Klaus Schmidinger 

> On 05.04.2010 12:43, Teemu Rantanen wrote:
> > Hi,
> >
> > I tried also without delete cDeviceHook but it still crashed...
>
> Please try creating the cReddoDeviceHook in
> cPluginDisableReddoQAM256::Initialize(),
> as suggested in PLUGINS.html.
>
> > Well, the fixes are basically available in the plugin, as I copied the
> > probe method (and modified slightly to suit the plugin). Those are:
> > - The sysfs filenames are idVendor (subsystem_vendor) and idProduct
> > (subsystem_device)
>
> This is what I get here:
>
> r...@video:/home/kls/vdr/VDR > ls -l
> /sys/class/dvb/dvb0.frontend0/device/subsystem_*
> -r--r--r-- 1 root root 4096 2010-04-05 16:25
> /sys/class/dvb/dvb0.frontend0/device/subsystem_device
> -r--r--r-- 1 root root 4096 2010-04-05 16:25
> /sys/class/dvb/dvb0.frontend0/device/subsystem_vendor
>
> r...@video:/home/kls/vdr/VDR > ls -l
> /sys/class/dvb/dvb0.frontend0/device/id*
> ls: cannot access /sys/class/dvb/dvb0.frontend0/device/id*: No such file or
> directory
>
> Maybe a bug in the driver?
>
> > - You need to set strtoul() base as 16 as the files don't have 0x in
> > front of the hex
>
> r...@video:/home/kls/vdr/VDR > cat
> /sys/class/dvb/dvb0.frontend0/device/subsystem_device
> 0x
> r...@video:/home/kls/vdr/VDR > cat
> /sys/class/dvb/dvb0.frontend0/device/subsystem_vendor
> 0x13c2
>
> Maybe the "reddo" driver behaves differently than the FuSi driver?
>
> > What about making this an utility method in VDR? Give device file name
> > and return id...
>
> Will do.
>
>
> Have you tried whether it works with my patch?
> In that case you wouldn't even need the whole plugin.
>
> Klaus
>
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Klaus Schmidinger]

On 05.04.2010 12:43, Teemu Rantanen wrote:
> Hi,
> 
> I tried also without delete cDeviceHook but it still crashed...

Please try creating the cReddoDeviceHook in 
cPluginDisableReddoQAM256::Initialize(),
as suggested in PLUGINS.html.

> Well, the fixes are basically available in the plugin, as I copied the
> probe method (and modified slightly to suit the plugin). Those are:
> - The sysfs filenames are idVendor (subsystem_vendor) and idProduct
> (subsystem_device)

This is what I get here:

r...@video:/home/kls/vdr/VDR > ls -l 
/sys/class/dvb/dvb0.frontend0/device/subsystem_*
-r--r--r-- 1 root root 4096 2010-04-05 16:25 
/sys/class/dvb/dvb0.frontend0/device/subsystem_device
-r--r--r-- 1 root root 4096 2010-04-05 16:25 
/sys/class/dvb/dvb0.frontend0/device/subsystem_vendor

r...@video:/home/kls/vdr/VDR > ls -l /sys/class/dvb/dvb0.frontend0/device/id*
ls: cannot access /sys/class/dvb/dvb0.frontend0/device/id*: No such file or 
directory

Maybe a bug in the driver?

> - You need to set strtoul() base as 16 as the files don't have 0x in
> front of the hex

r...@video:/home/kls/vdr/VDR > cat 
/sys/class/dvb/dvb0.frontend0/device/subsystem_device
0x
r...@video:/home/kls/vdr/VDR > cat 
/sys/class/dvb/dvb0.frontend0/device/subsystem_vendor
0x13c2

Maybe the "reddo" driver behaves differently than the FuSi driver?

> What about making this an utility method in VDR? Give device file name
> and return id...

Will do.


Have you tried whether it works with my patch?
In that case you wouldn't even need the whole plugin.

Klaus

> 2010/4/5 Klaus Schmidinger  >
> 
> From PLUGINS.html:
> 
>  A plugin that creates a derived cDeviceHook ...
>  shall not delete this object. It will be automatically deleted when the
>  program ends
> 
> I have added a similar note to device.h now.
> 
> > ...
> > - The sysfs probe code in full feature card plugin is buggy :-)
> 
> Would you mind posting a patch that fixes this?
> 
> Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Teemu Rantanen]

Hi,

I tried also without delete cDeviceHook but it still crashed...

Well, the fixes are basically available in the plugin, as I copied the probe
method (and modified slightly to suit the plugin). Those are:
- The sysfs filenames are idVendor (subsystem_vendor) and idProduct
(subsystem_device)
- You need to set strtoul() base as 16 as the files don't have 0x in front
of the hex

What about making this an utility method in VDR? Give device file name and
return id...


Teemu

2010/4/5 Klaus Schmidinger 

> From PLUGINS.html:
>
>  A plugin that creates a derived cDeviceHook ...
>  shall not delete this object. It will be automatically deleted when the
>  program ends
>
> I have added a similar note to device.h now.
>
> > ...
> > - The sysfs probe code in full feature card plugin is buggy :-)
>
> Would you mind posting a patch that fixes this?
>
> Klaus
>
>
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Klaus Schmidinger]

On 05.04.2010 00:55, Teemu Rantanen wrote:
> Hi,
> 
> There's a new version of the patch implemented as a plugin. It seems to
> work, but there are few things to notice:
> 
> - Plugin does not cache which devices are Reddo devices, instead it
> probes sysfs every time QAM256 channel is being tuned into (on any
> device). It would be nice if cDeviceHook added a mechanism for a hook to
> store context for each device. Hooking into device probe (like full
> feature card plugin does) would be much nicer way, but it would
> interfere with other plugins which need the same mechanism.

The proper way of doing this is to check the modulation types
in cDvbDevice::ProvidesTransponder(), as in the attached patch (which will
be part of VDR 1.7.15). If the "reddo" driver doesn't set the FE_CAN_QAM_256
flag correctly, it needs to be fixed there.

> - VDR crashes at very late in exit() when clearing some list (most
> likely cDeviceHook list), but I couldn't find a way to avoid that

>From PLUGINS.html:

  A plugin that creates a derived cDeviceHook ...
  shall not delete this object. It will be automatically deleted when the
  program ends

I have added a similar note to device.h now.

> ...
> - The sysfs probe code in full feature card plugin is buggy :-)

Would you mind posting a patch that fixes this?

Klaus

> The plugin is available here:
> 
> http://tvr.dy.fi/vdr/vdr-disablereddoqam256-0.0.1.tgz
--- dvbdevice.c	2010/03/07 13:58:24	2.32
+++ dvbdevice.c	2010/04/04 11:15:25	2.33
@@ -889,7 +889,16 @@
   if (!cSource::IsSat(Channel->Source()))
  return DeviceHooksProvidesTransponder(Channel); // source is sufficient for non sat
   cDvbTransponderParameters dtp(Channel->Parameters());
-  if (frontendType == SYS_DVBS && dtp.System() == SYS_DVBS2)
+  if (dtp.System() == SYS_DVBS2 && frontendType == SYS_DVBS ||
+ dtp.Modulation() == QPSK && !(frontendInfo.caps & FE_CAN_QPSK) ||
+ dtp.Modulation() == QAM_16 && !(frontendInfo.caps & FE_CAN_QAM_16) ||
+ dtp.Modulation() == QAM_32 && !(frontendInfo.caps & FE_CAN_QAM_32) ||
+ dtp.Modulation() == QAM_64 && !(frontendInfo.caps & FE_CAN_QAM_64) ||
+ dtp.Modulation() == QAM_128 && !(frontendInfo.caps & FE_CAN_QAM_128) ||
+ dtp.Modulation() == QAM_256 && !(frontendInfo.caps & FE_CAN_QAM_256) ||
+ dtp.Modulation() == QAM_AUTO && !(frontendInfo.caps & FE_CAN_QAM_AUTO) ||
+ dtp.Modulation() == VSB_8 && !(frontendInfo.caps & FE_CAN_8VSB) ||
+ dtp.Modulation() == VSB_16 && !(frontendInfo.caps & FE_CAN_16VSB))
  return false; // requires modulation system which frontend doesn't provide
   if (!Setup.DiSEqC || Diseqcs.Get(CardIndex() + 1, Channel->Source(), Channel->Frequency(), dtp.Polarization()))
  return DeviceHooksProvidesTransponder(Channel);
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Teemu Rantanen]

Hi,

There's a new version of the patch implemented as a plugin. It seems to
work, but there are few things to notice:

- Plugin does not cache which devices are Reddo devices, instead it probes
sysfs every time QAM256 channel is being tuned into (on any device). It
would be nice if cDeviceHook added a mechanism for a hook to store context
for each device. Hooking into device probe (like full feature card plugin
does) would be much nicer way, but it would interfere with other plugins
which need the same mechanism.

- VDR crashes at very late in exit() when clearing some list (most likely
cDeviceHook list), but I couldn't find a way to avoid that

- You may get syslog messages about trying to tune into QAM256 channel
if/when EPG is being updated on the background.

- The sysfs probe code in full feature card plugin is buggy :-)


The plugin is available here:

http://tvr.dy.fi/vdr/vdr-disablereddoqam256-0.0.1.tgz


Teemu


2010/4/3 VDR User 

> Klaus added the ability to limit satellites to certain dvb card in
> VDR-1.7.13.  However, a lot of users have the need to do device
> limiting at the transponder level, which VDR still can't do (and
> likely will never do I think, unfortunately).  But, Klaus also added
> device hooks in VDR-1.7.13 as well:
>
> - Implemented cDeviceHook to allow plugins more control over which device
> can
>  provide which transponder (thanks to Reinhard Nissl).
>
> This means that a plugin can be written that DOES provide device
> limiting at the transponder level!  Rnissl, as a test for the device
> hook patch, threw together a quick skeleton plugin using hardcoded
> values and it worked great.  To finish the plugin, it would just need
> support for a conf file where you define which
> transponder:polarity:satellite & devices you want to limit them to.  I
> assume this file would be read into a table stored in memory, and then
> referenced during a channel change for live tv or recording.
>
> If Rnissl see's this, maybe he'll elaborate further.
>
> Cheers,
> Derek
>
> ___
> 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] Restricting a particular dvb card from tuning to channels with a selected modulation

[Teemu Rantanen]

I see... I actually noticed cDeviceHook but couldn't figure out if it could
be used or not as there was no reference anywhere for it.

This patch could be very nicely implemented fully in a plugin. I'll try
that...

Thanks,


Teemu

2010/4/3 VDR User 

> Klaus added the ability to limit satellites to certain dvb card in
> VDR-1.7.13.  However, a lot of users have the need to do device
> limiting at the transponder level, which VDR still can't do (and
> likely will never do I think, unfortunately).  But, Klaus also added
> device hooks in VDR-1.7.13 as well:
>
> - Implemented cDeviceHook to allow plugins more control over which device
> can
>  provide which transponder (thanks to Reinhard Nissl).
>
> This means that a plugin can be written that DOES provide device
> limiting at the transponder level!  Rnissl, as a test for the device
> hook patch, threw together a quick skeleton plugin using hardcoded
> values and it worked great.  To finish the plugin, it would just need
> support for a conf file where you define which
> transponder:polarity:satellite & devices you want to limit them to.  I
> assume this file would be read into a table stored in memory, and then
> referenced during a channel change for live tv or recording.
>
> If Rnissl see's this, maybe he'll elaborate further.
>
> Cheers,
> Derek
>
> ___
> 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] Restricting a particular dvb card from tuning to channels with a selected modulation

[VDR User]

Klaus added the ability to limit satellites to certain dvb card in
VDR-1.7.13.  However, a lot of users have the need to do device
limiting at the transponder level, which VDR still can't do (and
likely will never do I think, unfortunately).  But, Klaus also added
device hooks in VDR-1.7.13 as well:

- Implemented cDeviceHook to allow plugins more control over which device can
  provide which transponder (thanks to Reinhard Nissl).

This means that a plugin can be written that DOES provide device
limiting at the transponder level!  Rnissl, as a test for the device
hook patch, threw together a quick skeleton plugin using hardcoded
values and it worked great.  To finish the plugin, it would just need
support for a conf file where you define which
transponder:polarity:satellite & devices you want to limit them to.  I
assume this file would be read into a table stored in memory, and then
referenced during a channel change for live tv or recording.

If Rnissl see's this, maybe he'll elaborate further.

Cheers,
Derek

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Teemu Rantanen]

Hi,

I bought a Reddo dvb-c usb card last week and wanted to make it a backup
card without a risk of it accidentally tuning into QAM256 channel and
spitting out garbage. It seems to be quite good value for money in Finland
if you want dvb-c usb card and don't need QAM256.

I followed this conversation through but as it seems there is no support for
not using QAM256 in the driver nor in the VDR I decided to make a short
patch for VDR.

**WARNING** This patch was written in quite short time and it's not a good
example of clean code, but it works (for me) and will be useful for anyone
with Reddo card having QAM256 channels. It will be obsolete if/when QAM256
disable is done "the right way" (by asking the driver), but until then...
Please try it out and let me know if there is a problem with it.

The patch is available here:

http://tvr.dy.fi/vdr/vdr-1.7.14-DisableReddoQAM256.diff


Teemu


2009/10/29 Petri Helin 

> Hi,
>
> I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi box),
> which works very well with the current Linux driver excluding channels with
> QAM-256 modulation. Would it be easy to check FE_CAN_QAM_256 in vdr before
> trying to use a device to tune to a particular channel? In such a case I
> could deactivate FE_CAN_QAM_256 in the drivers. I am using VDR 1.7.9, if it
> makes a difference.
>
> Of course at the moment the proper solution would be to modify the
> channels.conf to se a preselected card to tune to a particular channel, but
> in this case there are two drawbacks with it. 1) I have more than one card
> that I can use for QAM-256 channels and would like to use them all, and 2)
> channels woth QAM-256 are also encrypted and I have yet to figure out how to
> set both the CA code and the number of the card in the "Conditional access"
> parameter in the channels.conf.
>
> Actually now that I think of it... How about separating the explicit card
> selection and conditional access by introducing a new paremeter in the
> channels.conf that could be used to preselect the card(s) that can tune to
> the selected channel?
>
>
> -Petri
>
> ___
> 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] Restricting a particular dvb card from tuning to channels?with a selected modulation

[Michael Mauch]

VDR User wrote:

> I believe the best way to handle this situation is by allowing the
> user control over what devices may be used to tune what channels.  VDR
> can't be smart enough to figure it out due to incorrect & bad design
> in v4l.  Another strong reason to allow this to be configured at the
> user-level is what if the the user has 2 devices...both able to tune a
> channel but the signal is weak.  Tuner 1 can tune it fine but tuner 2
> has problems because of the weak signal.  VDR is simply going to ask a
> free tuner 'can you tune this?', whereas the best scenario would be
> for the user to say 'use tuner 1 for this channel'.
> 
> I can think of two ways to better deal with this; adding a new field
> in channels.conf, 

Doesn't the CA field in channels.conf already allow this?

   Conditional access
  A hexadecimal  integer  defining  how  this  channel  can  be
  accessed:

    Free To Air
  0001...000F   explicitly requires the device with the given number

I don't know if it works if you specify more than one device, but it
certainly works to specify only one device.

Regards...
Michael


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[VDR User]

On Fri, Oct 30, 2009 at 12:11 AM, Theunis Potgieter
 wrote:
> Does the sourcecap patch not address this whole issue? Even if source
> cap or something similar is applied, how will VDR be able to tune to a
> 8psk turbo-fec type channel if v4l2 does not provide any support for
> it? It shouldn't be VDR's responsibility surely? unless 8psk turbo-fec
> becomes part of the new dvb-plugin archtitecture of future VDR.

Turbo fec isn't specified in the stream or in v4l, it's only reported
as 8psk.  I may be wrong but doesn't sourcecaps only assign devices to
orbital positions?  What happens about all the orbital positions that
contain both qpsk and 8psk turbo?  It was suggested that you make a
fake orbital position for those with 8psk turbo transponders, then
change your channels.conf & sources.conf accordingly.

Consider the following:

dvb devices being used: budget dvb-s, genpix dvb-s (supporting turbo
fec), twinhan dvb-s/s2

sat1 tp1 (qpsk) dvb-s
sat1 tp2 (8psk turbo) dvb-s

sat2 tp1 (qpsk) dvb-s
sat2 tp2 (8psk turbo) dvb-s
sat2 tp3 (qpsk) dvb-s

sat3 tp1 (8psk) dvb-s2

If you say sat1 should use the genpix because it has an 8psk turbo fec
tp then you restrict the budget and twinhan ability to tune the qpsk
on tp1. Same for sat2.
If you want to tune sat3 tp1 by asking the devices 'are you s2
capable?' then you get a false hit by the genpix, which lies about
being s2 capable (so it can provide 8psk).
If you use sourcecaps and create a fake orbital position for sat1 tp2
and sat2 tp2 then it works but requires the user to create fake data
and do more work.

You can see simply doing a capability query is not good enough because
it can return unreliable results.  This isn't VDR's fault, it's v4l &
drivers but it can still be easily addressed within VDR which giving
the user other advantages such as assigning certain devices to certain
channels/transponders because they (maintain) lock better.

Now consider you just simply add support for an optional file called
override.conf (or whatever).  This file could look like this:

:
100:1,3 means for channel 100 use only devices 1 and 3.
101:2 means for channel 101 use only device 2.

You could also add support for orbital positions with:
:
S100.0:2,3 means for orbital position S100.0 use only devices 2 and 3.
S109.0:3 means for orbital position S109.0 use only device 3.

So you see, simply doing a capability query is not enough because it
can be unreliable.  Using sourcecaps can solve the problem but
requires non-existent orbital positions to be created and maintained
in both channels.conf and sources.conf.  By adding an override.conf,
you can give full control to the user by using one simple _optional_
file.  This seems like the easiest & best with the most flexibility
for the user.  It solves _everyones_ needs and doesn't require false
data, patching, etc.  As mentioned before you can also write a simple
shell script to auto-generate the override.conf for you.  I know Klaus
doesn't like to add files but if the file is optional and adding
support for it means satisfying everyones needs, I can't see a good
argument against it.  Especially when the alternative requires at
least some users to add fake data in their channels.conf+sources.conf.

Best regards,
Derek

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Theunis Potgieter]

On 30/10/2009, abbe normal <1abenor...@gmail.com> wrote:
> hello guys
>
>  yes i do think this is a good idea...
>  as with different tuners they could be used for other lnbs like c -band and 
> ku
>  i could only use my s2/s card for services on a c and ku setup then
>  tune and record from different types of services...
>  then each tuner could live on a fixed satellite if you wanted
>
>
>  On 10/29/09, Timothy D. Lenz  wrote:
>  > There is the isue whereone tunner might be connected to an LNB on a rotor
>  > and another to a fixed. Knowing how the tunner can tune
>  > wouldn't help then.
>  >
>  > - Original Message -
>  > From: "Klaus Schmidinger" 
>  > To: 
>  > Sent: Thursday, October 29, 2009 1:13 AM
>  > Subject: Re: [vdr] Restricting a particular dvb card from tuning to 
> channels
>  > with a selected modulation
>  >
>  >
>  >> On 10/28/09 23:15, Petri Helin wrote:
>  >> > Hi,
>  >> >
>  >> > I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi
>  >> > box), which works very well with the current Linux driver excluding
>  >> > channels with QAM-256 modulation. Would it be easy to check
>  >> > FE_CAN_QAM_256 in vdr before trying to use a device to tune to a
>  >> > particular channel? In such a case I could deactivate FE_CAN_QAM_256 in
>  >> > the drivers. I am using VDR 1.7.9, if it makes a difference.
>  >>
>  >> Checking the frontend capabilities is certainly the right thing to do,
>  >> and I will see that this gets implemented.
>  >>
>  >> Klaus
>  >>
>  >> ___

Does the sourcecap patch not address this whole issue? Even if source
cap or something similar is applied, how will VDR be able to tune to a
8psk turbo-fec type channel if v4l2 does not provide any support for
it? It shouldn't be VDR's responsibility surely? unless 8psk turbo-fec
becomes part of the new dvb-plugin archtitecture of future VDR.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[abbe normal]

hello guys

yes i do think this is a good idea...
as with different tuners they could be used for other lnbs like c -band and ku
i could only use my s2/s card for services on a c and ku setup then
tune and record from different types of services...
then each tuner could live on a fixed satellite if you wanted

On 10/29/09, Timothy D. Lenz  wrote:
> There is the isue whereone tunner might be connected to an LNB on a rotor
> and another to a fixed. Knowing how the tunner can tune
> wouldn't help then.
>
> - Original Message -
> From: "Klaus Schmidinger" 
> To: 
> Sent: Thursday, October 29, 2009 1:13 AM
> Subject: Re: [vdr] Restricting a particular dvb card from tuning to channels
> with a selected modulation
>
>
>> On 10/28/09 23:15, Petri Helin wrote:
>> > Hi,
>> >
>> > I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi
>> > box), which works very well with the current Linux driver excluding
>> > channels with QAM-256 modulation. Would it be easy to check
>> > FE_CAN_QAM_256 in vdr before trying to use a device to tune to a
>> > particular channel? In such a case I could deactivate FE_CAN_QAM_256 in
>> > the drivers. I am using VDR 1.7.9, if it makes a difference.
>>
>> Checking the frontend capabilities is certainly the right thing to do,
>> and I will see that this gets implemented.
>>
>> Klaus
>>
>> ___
>> 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
>

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Timothy D. Lenz]

There is the isue whereone tunner might be connected to an LNB on a rotor and 
another to a fixed. Knowing how the tunner can tune
wouldn't help then.

- Original Message - 
From: "Klaus Schmidinger" 
To: 
Sent: Thursday, October 29, 2009 1:13 AM
Subject: Re: [vdr] Restricting a particular dvb card from tuning to channels 
with a selected modulation


> On 10/28/09 23:15, Petri Helin wrote:
> > Hi,
> >
> > I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi
> > box), which works very well with the current Linux driver excluding
> > channels with QAM-256 modulation. Would it be easy to check
> > FE_CAN_QAM_256 in vdr before trying to use a device to tune to a
> > particular channel? In such a case I could deactivate FE_CAN_QAM_256 in
> > the drivers. I am using VDR 1.7.9, if it makes a difference.
>
> Checking the frontend capabilities is certainly the right thing to do,
> and I will see that this gets implemented.
>
> Klaus
>
> ___
> 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] Restricting a particular dvb card from tuning to channels with a selected modulation

[VDR User]

On Thu, Oct 29, 2009 at 1:13 AM, Klaus Schmidinger
 wrote:
> On 10/28/09 23:15, Petri Helin wrote:
>> Hi,
>>
>> I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi
>> box), which works very well with the current Linux driver excluding
>> channels with QAM-256 modulation. Would it be easy to check
>> FE_CAN_QAM_256 in vdr before trying to use a device to tune to a
>> particular channel? In such a case I could deactivate FE_CAN_QAM_256 in
>> the drivers. I am using VDR 1.7.9, if it makes a difference.
>
> Checking the frontend capabilities is certainly the right thing to do,
> and I will see that this gets implemented.

This still doesn't resolve a major problem for North Americans.  The
situation is that the 2 biggest dvb-s providers use a modified
modulation, 8psk turbo-fec.  There is only one device that is capable
of tuning this but unfortunately the device has to pretend to be a
dvb-s2 device to do so.  Apparently the v4l guys (from what I was
told) didn't want to allow 8psk turbo-fec in dvb-s because it's a
non-standard modulation.  So the problem becomes that VDR sees a dvb-s
stream and the frontend of say a nexus-s will say its capable of
receiving it, even though that dvb-s stream may contain the 8psk
turbo-fec which a nexus-s can not tune.

I believe the best way to handle this situation is by allowing the
user control over what devices may be used to tune what channels.  VDR
can't be smart enough to figure it out due to incorrect & bad design
in v4l.  Another strong reason to allow this to be configured at the
user-level is what if the the user has 2 devices...both able to tune a
channel but the signal is weak.  Tuner 1 can tune it fine but tuner 2
has problems because of the weak signal.  VDR is simply going to ask a
free tuner 'can you tune this?', whereas the best scenario would be
for the user to say 'use tuner 1 for this channel'.

I can think of two ways to better deal with this; adding a new field
in channels.conf, adding a tuneroverride.conf

By adding a new field.. If the value is "*" then it means any device
may tune it.  If its an integer, then the values listed represent
which devices should be used.  For example:
:*:   use any device
:2,3: use only device 2 or device 3

By using a tuneroverride.conf you can specify which devices to use
with certain channels.  If the channel isn't contained in
tuneroverride.conf then VDR just uses it's own logic to figure it out
(the capability check).  The good thing about this method is you can
create a simple shell script to auto-generate the tuneroverride.conf
file using key indicators in the channels.conf...  The file structure
would be very simple:

:

This is really the only way to satisfy _everyones needs_, by
ultimately allowing the user to control device priorities.  PLEASE
take this into serious consideration as it's been a long standing
problem that's only getting worse with more and more transponders move
to 8psk turbo-fec.

Best regards,
Derek

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Petri Helin]

On Thu, Oct 29, 2009 at 10:13 AM, Klaus Schmidinger
 wrote:
> On 10/28/09 23:15, Petri Helin wrote:
>> Hi,
>>
>> I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi
>> box), which works very well with the current Linux driver excluding
>> channels with QAM-256 modulation. Would it be easy to check
>> FE_CAN_QAM_256 in vdr before trying to use a device to tune to a
>> particular channel? In such a case I could deactivate FE_CAN_QAM_256 in
>> the drivers. I am using VDR 1.7.9, if it makes a difference.
>
> Checking the frontend capabilities is certainly the right thing to do,
> and I will see that this gets implemented.
>
> Klaus
>

Thanks!

-Petri

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Klaus Schmidinger]

On 10/28/09 23:15, Petri Helin wrote:
> Hi,
> 
> I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi
> box), which works very well with the current Linux driver excluding
> channels with QAM-256 modulation. Would it be easy to check
> FE_CAN_QAM_256 in vdr before trying to use a device to tune to a
> particular channel? In such a case I could deactivate FE_CAN_QAM_256 in
> the drivers. I am using VDR 1.7.9, if it makes a difference.

Checking the frontend capabilities is certainly the right thing to do,
and I will see that this gets implemented.

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Theunis Potgieter]

On 29/10/2009, Petri Helin  wrote:
> Hi,
>
>  I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi box), 
> which works very well with the current Linux driver excluding channels with 
> QAM-256 modulation. Would it be easy to check FE_CAN_QAM_256 in vdr before 
> trying to use a device to tune to a particular channel? In such a case I 
> could deactivate FE_CAN_QAM_256 in the drivers. I am using VDR 1.7.9, if it 
> makes a difference.
>
>  Of course at the moment the proper solution would be to modify the 
> channels.conf to se a preselected card to tune to a particular channel, but 
> in this case there are two drawbacks with it. 1) I have more than one card 
> that I can use for QAM-256 channels and would like to use them all, and 2) 
> channels woth QAM-256 are also encrypted and I have yet to figure out how to 
> set both the CA code and the number of the card in the "Conditional access" 
> parameter in the channels.conf.
>
>  Actually now that I think of it... How about separating the explicit card 
> selection and conditional access by introducing a new paremeter in the 
> channels.conf that could be used to preselect the card(s) that can tune to 
> the selected channel?
>
>
>  -Petri

Is this not related to the sourcecap patch?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[VDR User]

I have 3 dvb-s cards in one of my boxes.  2 of those cards are able to
tune all channels in my channels.conf.  1 of them can only tune some.
So, the problem is there seems to be no way to specify something like
'use device X,Y,Z' for a certain channel in channels.conf...  I had
raised this issue before but it seems there's no plans to address the
issue.  Big problem for users in this situation.  I'm constantly
losing recordings because of this as well.  :(

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[vdr] Restricting a particular dvb card from tuning to channels with a selected modulation

[Petri Helin]

Hi,

I have an USB DVB-C card (Reddo dvb-c, actually a relabelled Tongshi 
box), which works very well with the current Linux driver excluding 
channels with QAM-256 modulation. Would it be easy to check 
FE_CAN_QAM_256 in vdr before trying to use a device to tune to a 
particular channel? In such a case I could deactivate FE_CAN_QAM_256 in 
the drivers. I am using VDR 1.7.9, if it makes a difference.


Of course at the moment the proper solution would be to modify the 
channels.conf to se a preselected card to tune to a particular channel, 
but in this case there are two drawbacks with it. 1) I have more than 
one card that I can use for QAM-256 channels and would like to use them 
all, and 2) channels woth QAM-256 are also encrypted and I have yet to 
figure out how to set both the CA code and the number of the card in the 
"Conditional access" parameter in the channels.conf.


Actually now that I think of it... How about separating the explicit 
card selection and conditional access by introducing a new paremeter in 
the channels.conf that could be used to preselect the card(s) that can 
tune to the selected channel?



-Petri

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr