Reply to thread

Message: <blockquote data-quote="velis" data-source="post: 725948" data-attributes="member: 96429">Georgius,I'm currently testing your new filter (the release version) and so far it works well.I find it strange though: Actually <a href="https://forum.team-mediaportal.com/submit-code-patches-mediaportal-tv-server-etc-325/mpiptvsource-losing-packets-75287/#post553495" target="_blank">I'm the author</a> of current SVN version and it was all well until version 1.1. It is only lately that it started skipping. Actually so much that I was bugging my provider about this without verifying on their own STB... Turns out their STB didn't skip <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite11" alt=":rolleyes:" title="Roll Eyes    :rolleyes:" loading="lazy" data-shortname=":rolleyes:" />Now, fortunately you turned up and fixed the problem for me <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite8" alt=":D" title="Big Grin    :D" loading="lazy" data-shortname=":D" />Now, what about that missing signal stuff - playback of a static clip when no signal? <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite7" alt=":p" title="Stick Out Tongue    :p" loading="lazy" data-shortname=":p" />--------------------------------------------------------------------------------------------------------------Edit: After some 15 minutes, my TV just froze <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite3" alt=":(" title="Frown    :(" loading="lazy" data-shortname=":(" /> I went checking and I saw you have the same problems I had (100% CPU usage, etc.) please read the thread I linked to above carefully because inside it you will find many pitfalls this filter has.Basics:Use Select() to drop CPU usage, but be careful how you use it (recvfrom() + select() + recvfrom() - there must be very little code in between these calls.Don't use Sleep - 0 doesn't drop CPU usage, anything higher causes dropped packets.Suggestion:The actual reader thread should have top priority and do nothing but the three calls + fetching the next buffer from a buffer pool + putting the full buffers into another pool. *Only* in case the buffer pool is empty should it malloc another buffer.The main thread should be responsible for creating new buffers for the buffer pool + fetching filled buffers from reader thread + passing buffers to mm (dshow) system. It should lock both buffer lists minimally or not at all if possible.</blockquote>

Verification