Hi! I encountered this bug while removing the video stream (and the video stream only) in a fsrtpsession in empathy. The problem happens while the farstream session is destroyed, there is some kind of race, when the nicesrc element transition changes from PLAYING to PAUSED to READY, and still handles buffers, without an attached sink, causing the not-linked error in the basesrc gst element. This error being fatal for the pipeline, the connection is unexpectedly closed in the client.
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.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.