<br><br><div><span class="gmail_quote">On 10/18/05, <b class="gmail_sendername">Sigmund Augdal Helberg</b> &lt;<a href="mailto:sigmund@snap.tv">sigmund@snap.tv</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Tue, 2005-10-18 at 14:39 +0200, Henrik Sjoberg wrote:<br>&gt; Hi,<br>&gt;<br>&gt; I am playing a bit with getting MythTV to talk high level CI. However, I<br>&gt; have come to a problem in the dst/dst_ca drivers. MythTV have different
<br>&gt; threads running for tuning frequency and doing ca-stuff. This makes me get<br>&gt; simultaneous frontend and ca calls device. However, in the dst driver<br>&gt; these two things both end up in i2c communiation with the card which
<br>&gt; interfere with each other.<br>&gt;<br>&gt; As you can understand this does not work good since there are no locking<br>&gt; mechanism in dst. Is this something that is to go into the driver or<br>&gt; something that should be done on a higher level (
e.g. between all<br>&gt; components in an dvb-adapter)? I guess it should be taken care of by the<br>&gt; driver, since it is the only one that knows when locking is needed, but I<br>&gt; just want to check.<br><br>I've played around to make vlc speak high level CI. I have code that I'm
<br>fairly confident makes correct capmt messages, but it only works once in<br>a while. I have all sorts of strange behaviour. Some times the system<br>gets in a state where tuning does not work (no calls report any errors,
<br>but the received mux does not change). unloading and reloading the<br>driver fixes this. Some times the dst.session struct get messed up so<br>that the dst_ca belive has_session is set while it actually is not. And<br>
even other times the cam or card or smartcard or something gets stuck in<br>a state where any call to the ca device return just garbage. This<br>sometimes solves itself after a minute or two, and other times I need a<br>cold boot to get it working again. I was under the impression that this
<br>had to be caused by a memory corrution caused by a buffer overflow in<br>the i2c trafic(because increasing the size *_buf fields in the state<br>struct stoped the has session flag from being corrupted, but perhaps<br>
this is the cause of my problems as well?</blockquote><div><br>
<br>
Few weeks back, i had fixed a possible buffer overlow situation, Are
you talking about that ? If you are not with the updated with the
latest change. Well that was the last change that i had..<br>
Maybe you can check it again, incase you are not updated with the
latest. Maybe you can try the&nbsp; patch too, to check whether it
helps you in some manner.<br>
</div></div><br>
Regards,<br>
Manu<br>
<br>