<div dir="ltr">This file decodes just fine for me with tsdecrypt - no glitches whatsoever.<div><br></div><div>Discontinuities are only seen in the EMM PID 0x30, but they do not affect tsdecrypt in any way (unless maybe you feed them as well to the oscam?). This means this is not a switch issue (no way it garbles EMMs only).</div>
<div><br></div><div>I'd suggest you move the EMM to a separate process and see how it goes, and also remove it from the channel input stream.</div><div><br></div><div><br><div><br></div></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">2013/4/12 Georgi Chorbadzhiyski <span dir="ltr"><<a href="mailto:gf@unixsol.org" target="_blank">gf@unixsol.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 4/12/13 12:08 AM, JULIAN GARDNER wrote:<br>
> udp, and it is causing problems as every now and then the glitching messes up the decode and no keys come back from oscam.<br>
><br>
> joolz<br>
> ps How are you, have not spoken since january<br>
<br>
</div>It is not unheard of to have udp packets received in the wrong order,<br>
some switches do that.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Georgi Chorbadzhiyski<br>
<a href="http://georgi.unixsol.org/" target="_blank">http://georgi.unixsol.org/</a><br>
<a href="http://github.com/gfto/" target="_blank">http://github.com/gfto/</a><br>
</font></span></blockquote></div><br></div>