GNOME Bugzilla – Bug 403122
mmssrc: blocking read() causes totem to lock up when switching streams or n shutdown
Last modified: 2018-11-03 13:03:03 UTC
Please describe the problem: Opening a particular mms stream seems to make totem unresponsive. In the first case, opening the stream then quitting totem fails to return control to the console. In the second case opening the stream twice causes totem to stop updating it's UI. Steps to reproduce: 1. Run the following: totem mms://mrcstr1.swan.ac.uk/vc_address 2. Go to Movie -> Open Location and type mms://mrcstr1.swan.ac.uk/vc_address and click the open button. Actual results: User interface freezes. Expected results: Video to play? Interface to remain responsive. Does this happen every time? Yes this happens every time. Other information: gstreamer0.10-alsa 0.10.10-1ubuntu1 gstreamer0.10-esd 0.10.4-0ubuntu3 gstreamer0.10-ffmpeg 0.10.1-2ubuntu1 gstreamer0.10-gnomevfs 0.10.10-1ubuntu1 gstreamer0.10-plugins-bad 0.10.3+cvs20060918-0ubuntu1 gstreamer0.10-plugins-bad-multiverse 0.10.3+cvs20060918-1 gstreamer0.10-plugins-base 0.10.10-1ubuntu1 gstreamer0.10-plugins-base-apps 0.10.10-1ubuntu1 gstreamer0.10-plugins-good 0.10.4-0ubuntu3 gstreamer0.10-plugins-ugly 0.10.4-0ubuntu3 gstreamer0.10-plugins-ugly-multiverse 0.10.4-2 gstreamer0.10-tools 0.10.10-1ubuntu2 gstreamer0.10-x 0.10.10-1ubuntu1 libgstreamer-plugins-base0.10-0 0.10.10-1ubuntu1 libgstreamer0.10-0 0.10.10-1ubuntu2 libgstreamer0.10-0-dbgsym 0.10.10-1ubuntu2 totem-gstreamer 2.16.2-0ubuntu3 Using gst-launch-0.10 playbin uri="mms://mrcstr1.swan.ac.uk/vc_address" outputs: Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Might be a dup of bug #353116
This isn't a duplicate of 353116. What's happening here is two things: a) the server seems to be slightly broken: it sends only a few bytes of data (not even a complete ASF header) and then just stops sending data, but also doesn't send an error or close the connection. No idea what's up with that. I get the same behaviour with mplayer, xine and VLC. b) GStreamer's base source class, which the MMS source plugin is based on, currently works in a way that will wait for the streaming thread to return before it can shut down. In this case the streaming thread is blocked in a read() call waiting for either more data to arrive or for the connection to be closed (or time out). This is what causes the display freeze. Not very good, but also not quickly fixable with the way libmms/mmssrc currently work. Not sure what to do about this without rewriting mmssrc so that all blocking calls are done in yet another thread. Moving to GStreamer. It's possible to get the same problem without a broken server, namely when the connect() blocks for a long time.
The _unlock function is supposed to unlock the blocking read. It's just pretty impossible to implement this if libmms does not support it. Also starting another thread is not a good idea since it will just sit and hang there forever.
Hi, I've been working on mms support in gstreamer lately, see: bug 469930 libmms has the capability to provide your own io functions, these could use select or the likes to implement shorther then default tcp timeouts. Also these could be used to provide a non-blocking unlock function by using a messaging fd and adding that to the select like the base file (or was it tcp) source does. Does this sound like a plan?
*** Bug 568478 has been marked as a duplicate of this bug. ***
*** Bug 588486 has been marked as a duplicate of this bug. ***
That stream returns a 404. Can you provide a new stream ? Also, it's tempting to close this bug considering the amount of changes that went in over the past years.
> That stream returns a 404. Can you provide a new stream ? > > Also, it's tempting to close this bug considering the amount of changes that > went in over the past years. This problem is not related to any specific MMS stream. The bug should stay open until we have a completely async mmssrc (which I've been meaning to do for ever).
*** Bug 642388 has been marked as a duplicate of this bug. ***
Anyone knowledgeable about libmms and mmssrc knows if this bug is still valid ?
It's still valid.
Still valid :)
-- 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/gstreamer/gst-plugins-bad/issues/2.