Hi,<div><br></div><div>the right way, of course, is to fix the driver, and make vdr check what device can do. I&#39;m glad Petri had time to test it, and I hope to see the patch in next version of vdr. But I couldn&#39;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 &quot;reddo&quot; :-)</div>
<div><br></div><div>But i&#39;m afraid my time for this project just run out. I&#39;ll continue later if/when the reddo driver patch arrives, I will test it, but until then I&#39;ll have to manage with the plugin, even if it crashes or not at exit(). I&#39;ll make an empty plugin with an empty hook, and if it still crashes at exit() it&#39;s not my fault :-)</div>
<div><br></div><div>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-&gt;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&#39;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&#39;t the right way, but we aren&#39;t living in a perfect world :-)</div>
<div><br></div><div>And thanks,</div><div><br></div><div><br></div><div>Teemu</div><div><br><div class="gmail_quote">2010/4/5 Klaus Schmidinger <span dir="ltr">&lt;<a href="mailto:Klaus.Schmidinger@tvdr.de">Klaus.Schmidinger@tvdr.de</a>&gt;</span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"><br></div>Well, then the driver needs to make a finer distinction and *properly*<br>
set FE_CAN_QAM256.<br>
<div class="im"><br></div></blockquote></div></div>