Bug 100565

Created attachment 130674 [details]
gdb session

The nicesrc70:src thread stops in gstbasesrc.c:2950, when the "streaming stopped, reason not-linked" error is generated. At the same time, the main thread is locked while changing the nicesrc state from PAUSED to READY.

Created attachment 130675 [details]
GST related log file (edited)

the interesting part of the log is just before the jump from timestamp 0:15:17 to 12:04:29 (this gap is because empathy-call remained stopped in the debugger for quite a long time, before continuing), following the nicesrc70 element.

I reassign this bug to the Farstream product instead.

Created attachment 130701 [details] [review]
rtp: stop the transmitter before unlinking its sink (stream destroy case)

This patch seems to work for me, by stopping the nicesrc element, before removing it from the bin.

Comment on attachment 130701 [details] [review]
rtp: stop the transmitter before unlinking its sink (stream destroy case)

Review of attachment 130701 [details] [review]:
-----------------------------------------------------------------

That may result in a EOS event being sent downstream which may break other FsStreams connected to the same FsSession


And the patch subject is wrong, your unlinking the source there..

Created attachment 131729 [details] [review]
nice transmitter: Flush source before stopping

Maybe we should just send a flush to the source first. Here is a patch that does just that. Let me know if this helps.

Created attachment 131920 [details]
gstreamer pipeline dot file when reaching gstbasesrc.c:2950

Created attachment 131923 [details]
gstreamer pipeline dot file when reaching gstbasesrc.c:2950 (the good one)

Created attachment 131924 [details]
gdb backtrace matching previous dot file

The patch from comment #6 doesn't help. 

What seems interesting in this backtrace compared to the backtrace from bug #100586 is that fs_rtp_stream_dispose() is called *before* fs_rtp_session_dispose(), which explains why the conference bin is not stopped, and the removal of the nicesrc88 element from the bin91 GstBin causes this not-linked error.

The other (working) call stack should be fs_rtp_session_dispose() --> fs_stream_destroy() --> fs_rtp_stream_dispose() --> fs_stream_transmitter_stop(), and in that case the gst-src transmitters would stopped first.

The junction point where the behaviour diverges is in call-content.c:2363 in telepathy-farstream. When the stream is not destroyed there, the session is destroyed in _tf_call_content_destroy().

I wonder if the order of destruction should not be forced in _tf_call_content_destroy() ?

Created attachment 131951 [details] [review]
flush source before unlinking

Would it be correct to send the flush event before removing the nice source and not after ?

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/farstream/farstream/issues/4.