[gstreamer-bugs] [Bug 338827] [patch] gnomevfssrc should use async api to not block on network problems

[GStreamer (bugzilla.gnome.org)]

Do not reply to this via email (we are currently unable to handle email
responses and they get discarded).  You can add comments to this bug at
http://bugzilla.gnome.org/show_bug.cgi?id=338827

  GStreamer | gst-plugins-base | Ver: HEAD CVS


René Stadler changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mail at renestadler.de




------- Comment #5 from René Stadler  2006-10-08 03:47 UTC -------
This bug seems to cause problems in rhythmbox (see backtrace in #313049 comment
#76).  It should also cause problems for any other app using gnomevfssrc.  As
the bug had no activity for almost six months and the provided solution seems
to be unusable, I'll restate the problem a bit.

The culprit is the start () GstBaseSrc vfunc implementation of gnomevfssrc. 
According to the documentation "subclasses should open resources and prepare to
produce data".  This effectively gets called by gst_element_set_state (), which
must not block.  For a network source, "preparing to produce data" usually
means to establish a network connection, which is obviously not guaranteed to
be an instantaneous operation.  Therefore, this breaks the semantics of
gst_element_set_state (), causing terrible problems for applications.

A very simple method to reproduce the problem is using the netcat program like
this: "nc -l -p 10000 localhost".  This simulates a TCP server that eats all
data sent to it but never sends anything back.
"gst-launch-0.10 gnomevfssrc location=http://localhost:10000 ! fakesink" will
then hang while setting the state to PAUSED (literally, that is to say in
gst_element_set_state ()).


-- 
Configure bugmail: http://bugzilla.gnome.org/userprefs.cgi?tab=email