Reply to thread

Message

<blockquote data-quote="mm1352000" data-source="post: 994222" data-attributes="member: 82144">@<a href="https://forum.team-mediaportal.com/members/djblu.54957/" target="_blank">DJBlu</a>Looks like you've made some excellent progress with this issue.Having said that, personally I don't understand how your changes are solving the problem.Are you able to explain a little?&nbsp;My perspective is this...The deadlock at GetNewSubChannel() (which is calling CMpTs::AddChannel()) is obviously blocking on the m_Lock declared in CMpTs.We can see who/what is holding the lock by reading/comparing logs very carefully. I've attached such a sample with the epg.log, tv.log and TsWriter.log stitched together. Compare the output of the last successful EPG grab (for &quot;ANTENA 3&quot;):&nbsp;&nbsp;...with the failure:&nbsp;&nbsp;Note that thread 18 in the second section is locking in CMpTsFilter:<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(). There is no &quot;Pausegraph&quot; entry.This is telling me that for some reason the filter is refusing to stop.&nbsp;Here's the corresponding function:[code]STDMETHODIMP CMpTsFilter::Stop(){&nbsp; CAutoLock cObjectLock(m_pLock);&nbsp; &nbsp; LogDebug(&quot;CMpTsFilter::Stop()&quot;);&nbsp; return CBaseFilter::Stop();}[/code]&nbsp;Quite simple really.We can tell that m_pLock is the same lock as is used for CMpTs::AddChannel() by examining the constructor of CMpTs, the constructor of CMpTsFilter and the declaration of CBaseFilter in amfilter.h:&nbsp;&nbsp;What I don't understand is why 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() is blocking.&nbsp;Note that the example above is about as single-threaded as TV Server can get. Sequential tunes, over and over again... then we get this.&nbsp;mm</blockquote>

[QUOTE="mm1352000, post: 994222, member: 82144"] @[URL='https://forum.team-mediaportal.com/members/djblu.54957/']DJBlu[/URL] Looks like you've made some excellent progress with this issue. Having said that, personally I don't understand how your changes are solving the problem. Are you able to explain a little? My perspective is this... The deadlock at GetNewSubChannel() (which is calling CMpTs::AddChannel()) is obviously blocking on the m_Lock declared in CMpTs. We can see who/what is holding the lock by reading/comparing logs very carefully. I've attached such a sample with the epg.log, tv.log and TsWriter.log stitched together. Compare the output of the last successful EPG grab (for "ANTENA 3"): ...with the failure: Note that thread 18 in the second section is locking in CMpTsFilter::Stop(). There is no "Pausegraph" entry. This is telling me that for some reason the filter is refusing to stop. Here's the corresponding function: [code]STDMETHODIMP CMpTsFilter::Stop() { CAutoLock cObjectLock(m_pLock); LogDebug("CMpTsFilter::Stop()"); return CBaseFilter::Stop(); }[/code] Quite simple really. We can tell that m_pLock is the same lock as is used for CMpTs::AddChannel() by examining the constructor of CMpTs, the constructor of CMpTsFilter and the declaration of CBaseFilter in amfilter.h: What I don't understand is why CBaseFilter::Stop() is blocking. Note that the example above is about as single-threaded as TV Server can get. Sequential tunes, over and over again... then we get this. mm [/QUOTE]

Verification