Reply to thread

Message

<blockquote data-quote="mm1352000" data-source="post: 1025243" data-attributes="member: 82144">Looks like the same old symptoms. I find it interesting that the deadlock only seems to manifest on transponders when no EPG data is found.&nbsp;New patch for MP 1.5 PR is attached. This version adds a new lock which is shared between all input pin instances. The lock must be acquired when each sample is Receive()'d and when the filter is Stop()'d. Additionally, once the lock is acquired in Receive(), there is a new check to confirm that the filter is running before sample processing is allowed to proceed. All this effectively means pins must finish processing their last sample before the filter can stop, and once the filter is stopped the pins will reject samples properly.&nbsp;I did this because I think the deadlock is occurring in the pin Inactive() method (called from CBaseFilter:<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite5" alt=":confused:" title="Confused&nbsp; &nbsp; :confused:" loading="lazy" data-shortname=":confused:" />top()). Inactive() attempts to Decommit() the pin allocator which in turn attempts to acquire the lock on the allocator. It won't be able to acquire the allocator if the upstream filter is trying to use it to prepare a new sample for TsWriter.&nbsp;Note: in order to reduce my workload I'm not going to be providing patches for MP 1.4 or MP 1.3. Sorry. I hope you can understand and will be willing to upgrade to test.</blockquote>

[QUOTE="mm1352000, post: 1025243, member: 82144"] Looks like the same old symptoms. I find it interesting that the deadlock only seems to manifest on transponders when no EPG data is found. New patch for MP 1.5 PR is attached. This version adds a new lock which is shared between all input pin instances. The lock must be acquired when each sample is Receive()'d and when the filter is Stop()'d. Additionally, once the lock is acquired in Receive(), there is a new check to confirm that the filter is running before sample processing is allowed to proceed. All this effectively means pins must finish processing their last sample before the filter can stop, and once the filter is stopped the pins will reject samples properly. I did this because I think the deadlock is occurring in the pin Inactive() method (called from CBaseFilter::Stop()). Inactive() attempts to Decommit() the pin allocator which in turn attempts to acquire the lock on the allocator. It won't be able to acquire the allocator if the upstream filter is trying to use it to prepare a new sample for TsWriter. Note: in order to reduce my workload I'm not going to be providing patches for MP 1.4 or MP 1.3. Sorry. I hope you can understand and will be willing to upgrade to test. [/QUOTE]

Verification