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 :-)

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.