TSWriter deadlock potential fix. (1 Viewer)

[nimrodel50]

Thanks I will try those new versions. I will keep you updated.

 

[FreakyJ]

@doskabouter
understandable take your time nd only the best wishes to your wife!

 

[nimrodel50]

here you have the first logs.

 

[nimrodel50]

Hi I've been testing the two versions TVLibrary [remove MS extra filters] and TVLibrary [no use dsrot] and none of them are able to show any tv chanel, no singal error.

Here you have the logs of the dsrot one.

thanks.

 

[mm1352000]

Hi I've been testing the two versions TVLibrary [remove MS extra filters] and TVLibrary [no use dsrot] and none of them are able to show any tv chanel, no singal error.

Hmmm, I suspected that might be the case but can you try one thing for me.
In the tuner settings, please try to change "preferred network provider" from generic to DVBT.
http://wiki.team-mediaportal.com/1_...nfiguration/02_TV_Servers#Edit_Tuner_Settings

In relation to your first set of log files... now I'm really starting to get puzzled.
Here is the scenario.
When we tell the DirectShow graph to stop, TsWriter is receiving the stop command and appears to be stopping successfully. Evidence is:

[2013-09-11 21:42:39,101] [Log ] [3 ] [INFO ] - debug: call DVB-T stop graph
[2013-09-11 21:42:39,101] [Log ] [3 ] [INFO ] - dvbtopGraph called
[2013-09-11 21:42:39,101] [Log ] [3 ] [INFO ] - tvcard:FreeAllSubChannels
[2013-09-11 21:42:39,101] [Log ] [3 ] [INFO ] - dvbtopGraph

11-09-2013 21:42:39.101 CMpTsFilter:top()
11-09-2013 21:42:39.101 Stop streaming...
11-09-2013 21:42:39.101 Stop filter...
11-09-2013 21:42:39.101 HRESULT = 0x0

The "HRESULT... line" is the last line in the filter Stop() function before it returns. After that the filter graph manager will be trying to stop other filters. I know the graph is never successfully stopped because I don't see the debug line "debug: IMediaControl stopped! hr = 0x0 " in the TV service log.

So what is going on? I think one or more of the filters in the graph is not able to stop for some reason and yet I don't know why. The other debug TV library DLLs that I posted attempted to remove filters that may not be necessary from the graph (MPEG demuxer and BDA TIF) and/or not register the graph to try to eliminate potential causes... but obviously that didn't work (breaks tuning for this Hauppauge tuner).

I have to admit that I am really out of ideas for the moment. I don't know what is happening, why it is happening or how to debug the problem any further.
Tags to some team members that I hope might have some thoughts...
@morpheus_xx @DJBlu @Owlsroost @arion_p @misterd

 

[nimrodel50]

Thanks I will do the testing you suggest.

Hope we can get to the bottom of this.

 

[mm1352000]

I said that I had run out of ideas... and then I was inspired!
http://social.msdn.microsoft.com/Fo...491c-999c-3bfaa2f218ca/imediacontrol-deadlock

Make sure you aren't issuing any graph or filter calls in any event callbacks.

How could I have not checked this before! We don't see the problem when the timeshifting EPG grabber is used and we don't see the problem with the idle EPG grabber unless no EPG data is found. When no EPG data is found the TV service is attempting to stop the graph from inside the callback function (ie. while a sample is still being processed). That is never going to be good. I just literally cannot believe I didn't think of this before!!!
As you can probably tell, I really think I've solved the problem with the attached patch [for MP 1.5 PR] (please continue to use the previously supplied TsWriter) and I can't wait to hear your feedback...

 

[nimrodel50]

Testing right now!!

Congratulations for your finding!!

 

[DJBlu]

@mm1352000 Is it possible to get the patch file so I can add it to the jira entry. Or just commit to the bug banch.

Thanks.

 

[nimrodel50]

@mm1352000 sorry to brake the magic here but please check the logs. It seems locked again.

It seems that something else is causing another problem.