Reply to thread

Message: <blockquote data-quote="velis" data-source="post: 726446" data-attributes="member: 96429">OK, after a few more hours testing I think this might be a good solution. I did see some stutters, but I can't be sure if those were glitches on the network or in the filter. Logs sure didn't show anything.Included in the .rar are both sources and the .ax file.as for .ax, instructions for installation are the same as for Georgius's version.Sources are a bit of a problem since I only have VS 2008. You need to manually add the grabberthread.h and grabberthread.cpp to the project include / source files.The filter writes log to Program Data\Team MediaPortal\MediaPortal TV Server\logfile name is MPIPTVSource-date.log.This is in no way final code.This is not the same solution as Georgius' version.Use at your own risk[USER=107951]georgius[/USER]:I think this is stable, but I'm havin issues presumably with thread priorities / locking, mostly in the HD channel grabbing. Seems like even though the grabber thread doesn't take much CPU it still doesn't let the mm thread grab the buffers that are already filled. That's why you will see I allocate 200! buffers (300 KB) at the beginning of the grabber thread. This was pretty much necessary so that grabber thread doesn't have to allocate the buffers all the time.But then there's this sudden burst when the mm thread in a few milliseconds cleans out the entire buffer. It's possible the interim non-grabbing may be an issue related to waiting for a signal from mm system. Need to investigate further since I really don't like so many mini-buffers.Anyway, I think the architecture of this implementation should be pretty evident. The existing main thread source has been throughly cleaned out since all socket-related functions have been moved to the grabber thread. I also fixed logging so that the logging calls are no longer #ifdef-ed, but still generate no code when logging is disabled.Grabber thread only grabs the socket and puts anything obtained in a deque.I also maintain another deque which only stores empty buffers so that there's minimum allocation going on.The previous grabber thread (mm thread - HRESULT CMPIptvSourceStream:: DoBufferProcessingLoop(void)) now only acts as an intermediary between mm system and grabber thread.Grabber thread has elevated priority so that it presumably doesn't miss any packet. The internal grabbing loop is pretty tight IMO. A bit could be done about locking both deques, but not much really.The mm thread has normal priority and just moves the data from grabber thread's buffers into mm buffers.I could find no use for cyclic buffers. In fact I think they are dangerous (as in more stutter) should there be an overflow.This is about it for now.</blockquote>

Verification