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 577315 - [souphttpsrc] timeout property has no effect
[souphttpsrc] timeout property has no effect
Status: RESOLVED NOTABUG
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-30 15:09 UTC by René Stadler
Modified: 2009-07-16 20:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Alternative timeout handling (2.07 KB, patch)
2009-07-09 18:13 UTC, Mark Nauwelaerts
none Details | Review

Description René Stadler 2009-03-30 15:09:10 UTC
The new timeout property of souphttpsrc doesn't work AFAICS.

gst-launch-0.10 -v souphttpsrc location=http://stream.wbai.org:8000/24k timeout=10 ! decodebin2 ! autoaudiosink

I tried running the above pipeline and dropped the network connection by manipulating the routing table. It's supposed to error out after 10 seconds but it doesn't.
Comment 1 Edward Hervey 2009-03-30 15:30:15 UTC
I just retested with debugging, and the property *is* being passed on to the soup session.

Bug in libsoup ?
Comment 2 Tim-Philipp Müller 2009-06-15 22:19:30 UTC
Rene: ping?
Comment 3 Mark Nauwelaerts 2009-07-09 17:54:00 UTC
It is a bug in libsoup, specifically bug #574414, which seems to be fixed in 2.27.  However, it does not seem to fix it completely, at least not so for souphttpsrc, which is now noted (along with possible patch) in bug #588177.
Comment 4 Mark Nauwelaerts 2009-07-09 18:13:01 UTC
Created attachment 138135 [details] [review]
Alternative  timeout handling

Alternatively, rather than expecting libsoup to (re)act on timeout, one might do some timeout monitoring on souphttpsrc level.  The advantage is that it does not depend on libsoup (fix) and is better aware that a timeout has actually occurred.  However, since it monitors timeout on a higher level, it might also (theoretically) timeout on a large amount of data/headers over a slow connection where there need not really be a (lower level network) timeout.
Comment 5 Sebastian Dröge (slomo) 2009-07-16 15:24:20 UTC
I think it's better to depend on the souphttpsrc patch because (as you said) implementing the timeout at our layer has some disadvantages and brings unexpected behaviour.

Do you agree? If so, please close this bug :)
Comment 6 Mark Nauwelaerts 2009-07-16 20:03:47 UTC
I assume you mean(t) the libsoup patch, in which case that is fine by me.
So closing as not (our) bug.