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,


2010/4/5 Klaus Schmidinger <klaus.schmidin...@tvdr.de>

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

Reply via email to