Bug 30928

Summary: [PATCH] Sometimes src-pad-added is emitted before request-resource
Product: Telepathy Reporter: George Kiagiadakis <gkiagia>
Component: tp-farsightAssignee: Olivier Crête <olivier.crete>
Status: RESOLVED WONTFIX QA Contact: Telepathy bugs list <telepathy-bugs>
Severity: normal    
Priority: medium CC: olivier.crete
Version: git master   
Hardware: Other   
OS: All   
URL: http://git.collabora.co.uk/?p=user/gkiagia/telepathy-farsight.git;a=shortlog;h=refs/heads/fix-src-pad-added
Whiteboard:
i915 platform: i915 features:

Description George Kiagiadakis 2010-10-16 15:06:40 UTC
Sometimes when I make a call from my desktop to my laptop, the src-pad-added signal is emitted too early, before the request-resource signal. This causes trouble, since I assume that request-resource should come first and I create the sink inside the closure connected to this signal.

As I've mentioned on irc, this happens because:

19:55 < gkiagia> request-resource is connected to some connection manager signal. As soon as the CM signals it, request-resource is emitted, then the TfStream is set to receiving state. In TfStream though, that only controls the input valve of the FsRtpSubStream and not its pads
19:56 < gkiagia> the src-pad-added signal is connected to the pad block callback of the rtpbin src pad
19:57 < gkiagia> as soon as the pad blocks, the callback is called and the codecbin and the conference src pad are added
19:57 < gkiagia> so it looks like they are totally unrelated to each other
19:58 < gkiagia> what happens probably is that data is received too early, so the pad gets a buffer and blocks before the CM manages to finish its work
19:59 < gkiagia> input_valve still stays closed though, but that doesn't really help :/

This patch (see URL field) fixes the issue by delaying the src-pad-added signal until the pad has received data, which is implemented by blocking the pad and emitting the signal in the pad block callback.
Comment 1 Olivier Crête 2011-04-07 11:16:48 UTC
The patch is wrong, src_pad_added should never come before request_res.. The direction change in farsight2 should ensure that.. If it does happen, it means there is a bug somewhere..

How reliably can you reproduce it ?
Comment 2 Olivier Crête 2013-09-26 00:32:20 UTC
Branch is gone.. I assume the patch is no longer needed..

Also tp-farsight is obsolete.

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.