Reply to thread

Message

<blockquote data-quote="mm1352000" data-source="post: 1128613" data-attributes="member: 82144">Yes, it's a nasty issue, but it cannot be fixed quickly and reliably with only not-null checks. It really requires locking to properly protect all access to _tsFilterInterface. Locking is necessary because this issue will only be observed when multiple threads are interacting with the tuner/sub-channel. You have one EPG grabber thread that is in the middle of tuning (in this case waiting for PMT, but it could really be anywhere in the tuning process) and another from PS that is telling the service to suspend. Handling this properly is not so straightforward. Yes it would only take 30 minutes or so to add lock () {} and if ( != null) {} around things... but you have to take time to consider the potential for deadlocks, which are especially possible due to the call backs from TsWriter.Oh, no. What I meant was that the PC was on shortly before the recording. It suspended at ~19:21 and would have remained suspended until some later time.By &quot;it&quot; you mean Windows, right?I can only tell you what I read in the log files, and what I read is that the service crashed on suspend at 19:21 and did not get restarted until 20:11. Perhaps Windows doesn't automatically restart until resume. I don't know. I didn't write the Windows code. <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile&nbsp; &nbsp; :)" loading="lazy" data-shortname=":)" />Use the time-shifting EPG grabber only, and schedule a fake recording every day?Yeah, the answer is no. I'm not going to do it.I'm not able to help you with PS[++] questions.</blockquote>

[QUOTE="mm1352000, post: 1128613, member: 82144"] Yes, it's a nasty issue, but it [B]cannot [/B]be fixed quickly and reliably with only not-null checks. It really requires locking to properly protect all access to _tsFilterInterface. Locking is necessary because this issue will only be observed when multiple threads are interacting with the tuner/sub-channel. You have one EPG grabber thread that is in the middle of tuning (in this case waiting for PMT, but it could really be anywhere in the tuning process) and another from PS that is telling the service to suspend. Handling this properly is not so straightforward. Yes it would only take 30 minutes or so to add lock () {} and if ( != null) {} around things... but you have to take time to consider the potential for deadlocks, which are especially possible due to the call backs from TsWriter. Oh, no. What I meant was that the PC was on shortly before the recording. It suspended at ~19:21 and would have remained suspended until some later time. By "it" you mean Windows, right? I can only tell you what I read in the log files, and what I read is that the service crashed on suspend at 19:21 and did not get restarted until 20:11. Perhaps Windows doesn't automatically restart until resume. I don't know. I didn't write the Windows code. :) Use the time-shifting EPG grabber only, and schedule a fake recording every day? Yeah, the answer is no. I'm not going to do it. I'm not able to help you with PS[++] questions. [/QUOTE]

Verification