GNOME Bugzilla – Bug 640811
discoverer async api does not work (as expected)
Last modified: 2018-05-04 11:36:28 UTC
I have switched from using the sync API to the async API in discoverer. I have a file-browser in in the selection callback I start discovering the selected file. When I do it like this: gst_discoverer_stop (self->priv->dc); gst_discoverer_discover_uri_async (self->priv->dc, uri); gst_discoverer_start (self->priv->dc); _discover_uri_async() starts discovering immediately, it does not emit the ::discovered() signal and _start() blocks. Using the API like this works, but is not obvious for me: gst_discoverer_stop (self->priv->dc); gst_discoverer_start (self->priv->dc); gst_discoverer_discover_uri_async (self->priv->dc, uri); Two goals for this bug: - clarify the docs - ensure it does not hang. I am not sure whats the intention of the "can_run" in _discover_uri_async(). If I ensure that _discover_uri_async() won't call _start() everything is fine.
I saw the same problem using gstreamer-plugins-base-0.10.32-1.fc15.x86_64. It did not hang though, but there was no discovery done whatsoever.
Created attachment 185199 [details] [review] don't start discoverer when adding uris
Okay, from the gst-discoverer tool I seem to understand the intendet use of the API in the async mode. One should: - run the discoverer - when the mainloop runs, call gst_discoverer_discover_uri_async() for one or more files - stop the discoverer when done or otherwise desired The not so obvious part is that gst_discoverer_discover_uri_async() will start the discoverer if it wasn't running and the list of uris was empty. Shall we just document that or change the implict bahaviour?
I started adding unit test for discoverer as well, lets hope Edward can clarify his intent here.
It does work that way now. Must have been fixed in the past 7 years.