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

  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
  

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 <Klaus.Schmidinger@tvdr.de>

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

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 <Klaus.Schmidinger@tvdr.de
> <mailto:Klaus.Schmidinger@tvdr.de>>
> 
> 
>     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