GNOME Bugzilla – Bug 724376
http streams break when paused for a while
Last modified: 2015-03-09 06:59:25 UTC
When pausing a stream for a while, it seems that after a while, the soup-component decides to disconnect; then, when we resume later, it tries to reconnect (with a range request); if the stream source does not support that, this breaks the stream (after the buffer is emptied). This is similar to bug #667175, but a bit more general, since this also applies to simply pausing a stream for a while. Is there some way to tell the component not to break the connection? I'd be happy to work on this, if someone can point me to the relevant places in the code (I presume in souphttpsrc, or perhaps in libsoup?)
Created attachment 269137 [details] python programs that demonstrates the problem this program plays a stream, then pauses for a while and then resumes; after resuming (it takes a bit of time, presumably because there's a buffer), the stream terminates: #Q output: #Q #Q pausing for 250 secs #Q go get some coffee #Q resuming... #Q ('error:', (GError('Server does not support seeking.',), 'gstsouphttpsrc.c(888): gst_soup_http_src_got_headers_cb (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:\nServer does not accept Range HTTP header, URL: http://64.202.98.133:9130')) #Q ('error:', (GError('Internal data flow error.',), 'gstbasesrc.c(2865): gst_base_src_loop (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source:\nstreaming task paused, reason error (-5)'))
This sounds like a duplicate of bug #683536, but that's supposed to be fixed in 1.2.1, so guess not.
Indeed, I'm using gstreamer1-plugins-good-1.2.3 on F20. I think what bug #683536 handles is something slightly different -- it makes httpsoupsrc not treat such break as an EOS, but instead tries to reconnect / seek using a range request; it's not really making anything persistent. To get the pause to work (as in the example program), I think the connection should actual be made persistent; perhaps on the soup-level? (There's an 'idle-timeout' property for the SoupConnection -- but from the documentation I gather that it should never time out by default; so we probably need something else)
The main problem here is that servers can decide to drop the connection if it stays idle for some time. Imagine what it would happen if they would all keep it alive forever? You can try and use timeout and idle-timeout and keep-alive to try and make it last longer, but at some point the server may decide to drop it. Of course if for your use case you have control over your server, it should work. If you are dealing with the internet, then I think there's not much left to do. http://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html http://en.wikipedia.org/wiki/HTTP_persistent_connection
Indeed, if the servers don't support it, there's not much we can do... but a few minutes should work, or? I thought about using idle-timeout before (and writing a patch to make it a property in souphttpsrc), but I concluded that idle-timeout must already be 'infinite' (0), since that's the default for sessions you get with soup_session_async_new_with_options. The keep-alive settings is interesting. I'll what that does. Thanks.
So what's left to be done in this bug here? The keep-alive setting on souphttpsrc obviously won't prevent the server from closing the connection to you either. But it tells the server to not close it immediately after the last request is finished. Instead servers will often close the connection after about a minute. Nothing is preventing them from closing the connection immediately though and that is something that needs to be handled.
one thing is the idle-timeout property; would a patch adding that to souphttpsrc be acceptable? another thing is the range-requests that are being tried on servers that don't support them, and then erroring out; I think it'd be better to check for the Accept-Ranges header, and not try the range-request if it's not supported, and getting "Forbidden"; I can handle these at a higher level, but afaics only by doing a strcmp for "Forbidden", which isn't very nice.
(In reply to comment #7) > one thing is the idle-timeout property; would a patch adding that to > souphttpsrc be acceptable? Yes > another thing is the range-requests that are being tried on servers that don't > support them, and then erroring out; I think it'd be better to check for the > Accept-Ranges header, and not try the range-request if it's not supported, and > getting "Forbidden"; I can handle these at a higher level, but afaics only by > doing a strcmp for "Forbidden", which isn't very nice. Yes, are we still not handling that correctly with latest GIT? :( Should definitely be fixed. Can you prepare a patch for that?
(In reply to comment #7) > another thing is the range-requests that are being tried on servers that don't > support them, and then erroring out; I think it'd be better to check for the > Accept-Ranges header, and not try the range-request if it's not supported, and > getting "Forbidden"; I can handle these at a higher level, but afaics only by > doing a strcmp for "Forbidden", which isn't very nice. You can check the status code returned by the server. IIRC 403 is forbidden and it is likely that there is a macro/constant for that in libsoup.
(In reply to comment #7) > one thing is the idle-timeout property; would a patch adding that to > souphttpsrc be acceptable? idle-timeout is the timeout after which *libsoup* closes the connection (which, as mentioned above, defaults to "never" in this case). libsoup is already doing everything it can to keep the connection open, so if the server wants to close it, there's nothing you can do. (Well, ok, that's not true. You could sent a dummy request like "HEAD /" every N seconds to keep the connection non-IDLE. But you certainly shouldn't do that forever.)
Okay, this seems to have been solved, partly by myself better understanding the actual problem... thanks for the help!