After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 343787 - The adder cannot handle when multiple elements tries to link at the same time
The adder cannot handle when multiple elements tries to link at the same time
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal normal
: 0.10.10
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-06-03 21:22 UTC by Tomas Groth
Modified: 2008-05-26 11:06 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
testcase (1.71 KB, text/x-csrc)
2006-07-25 13:17 UTC, Tomas Groth
Details

Description Tomas Groth 2006-06-03 21:22:05 UTC
Please describe the problem:
When multiple elemenst try to get linked to the adder very quickly after each other, the adder fails to link to them, stops the adding (dies?), and spits out the following warning and error:
GStreamer-WARNING **: Pad list changed during capsnego for element adder0
GStreamer-CRITICAL **: pad adder0:sink6 returned NULL caps from getcaps function

I don't have any simple example code since the code producing the bug is part of a larger application.


Steps to reproduce:
1. Create a pipeline with an adder and multiple audio inputs.
2. Link one of them and start the playback.
3. Link the rest of them to the adder quickly after each other.


Actual results:
This produces the warnings and errors:
GStreamer-WARNING **: Pad list changed during capsnego for element adder0
GStreamer-CRITICAL **: pad adder0:sink6 returned NULL caps from getcaps function

Expected results:
If this worked correctly the adder should link the elements to itself, without any errors

Does this happen every time?
yes

Other information:
Comment 1 Tomas Groth 2006-07-25 13:17:46 UTC
Created attachment 69576 [details]
testcase

Example code that shows the problem. Replace the mp3-file-name in the code. If it runs fine try to increase the loops in the for-loop.
Comment 2 Wim Taymans 2006-08-29 15:27:14 UTC
Following patch was commited to HEAD some time ago to handle pad list changes during negotiation. This should at least fix the warning.

        * gst/gstutils.c: (gst_pad_proxy_getcaps):
        Handle RESYNC correctly in _proxy_getcaps.

Comment 3 Wim Taymans 2006-08-29 15:35:54 UTC
can you retest with -core CVS HEAD? 
Comment 4 Tomas Groth 2006-08-31 11:51:24 UTC
The warnings no longer shows, but the bug is still there... I'd actually prefer to have the warning/error messages so that I know something is wrong...
Comment 5 Sebastian Dröge (slomo) 2008-05-26 11:06:13 UTC
The testcase works fine for me with latest CVS, even with 1000 iterations of the loop.