GNOME Bugzilla – Bug 771751
souphttpsrc: Server does not support seeking ( for slow network connections )
Last modified: 2018-11-03 15:11:54 UTC
This is a fork from the original rhythmbox issue ( https://bugzilla.gnome.org/show_bug.cgi?id=771533 ) There are a few bugs similar to this filed in souphttpsrc. But, I think this is a bit different. When Rhythmbox plays a internet radio stream on a slow network connection, after a few minutes the stream closes with "Server does not support seeking". Prior to that there are few instances of the stream moving to PAUSE state, due to buffering. Accept-Ranges: * The radio server supports the range request. * souphttpsrc requests a range in this case ( prior to this bug failure ) * Radio server responds with a HTTP OK. * Still 'Server does not support seeking' is given by souphttpsrc.
Normal scenario ( when radio streaming starts ): ------------------------------------------------ GET /stream HTTP/1.1 Host: s4.streammonster.com:8888 Connection: close icy-metadata: 1 User-Agent: GStreamer souphttpsrc libsoup/2.55.90 HTTP/1.0 200 OK Accept-Ranges: bytes Content-Type: audio/mpeg icy-br:128 ice-audio-info: bitrate=128 icy-description:Global Swing Broadcast and all that Jazz... icy-genre:Swing icy-name:Global Swing Broadcast icy-pub:0 icy-url:http://www.gsb.fm Server: Icecast 2.4.0-kh2 Cache-Control: no-cache, no-store Pragma: no-cache Access-Control-Allow-Origin: * Access-Control-Allow-Headers: Origin, Accept, X-Requested-With, Content-Type Access-Control-Allow-Methods: GET, OPTIONS, HEAD Connection: Close Expires: Mon, 26 Jul 1997 05:00:00 GMT icy-metaint:16000
Normal scenario ( just before souphttpsrc failing ): --------------------------------------------------- GET /stream HTTP/1.1 Host: s4.streammonster.com:8888 Connection: close icy-metadata: 1 Range: bytes=2129915- User-Agent: GStreamer souphttpsrc libsoup/2.55.90 HTTP/1.0 200 OK Accept-Ranges: bytes Content-Type: audio/mpeg icy-br:128 ice-audio-info: bitrate=128 icy-description:Global Swing Broadcast and all that Jazz... icy-genre:Swing icy-name:Global Swing Broadcast icy-pub:0 icy-url:http://www.gsb.fm Server: Icecast 2.4.0-kh2 Cache-Control: no-cache, no-store Pragma: no-cache Access-Control-Allow-Origin: * Access-Control-Allow-Headers: Origin, Accept, X-Requested-With, Content-Type Access-Control-Allow-Methods: GET, OPTIONS, HEAD Connection: Close Expires: Mon, 26 Jul 1997 05:00:00 GMT icy-metaint:16000
dev@unstable:~/Music$ gst-launch-1.0 playbin uri=http://s4.streammonster.com:8888/stream Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Redistribute latency... Prerolled, waiting for buffering to finish... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstPulseSinkClock Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... Done buffering, setting pipeline to PLAYING ... Buffering, setting pipeline to PAUSED ... ERROR: from element /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source: Server does not support seeking. Additional debug info: gstsouphttpsrc.c(1294): gst_soup_http_src_got_headers_cb (): /GstPlayBin:playbin0/GstURIDecodeBin:uridecodebin0/GstSoupHTTPSrc:source: Server does not accept Range HTTP header, URL: http://s4.streammonster.com:8888/stream, Redirect to: (NULL) Execution ended after 0:02:58.111309899 Setting pipeline to PAUSED ... Setting pipeline to READY ... Setting pipeline to NULL ... Freeing pipeline ...
Created attachment 335978 [details] Wireshark packet capture pcapng ( tcp.port == 8888 )
I just simulate a slow connection via the below command: root@unstable:~# wondershaper eth0 100 512 which changes the download speed to 100kbps and upload speed to 512 kbps. wondershaper is a frontend to 'tc' command.
This would happen if the server closes the connection at some point, and then a new connection is tried with seeking to the old position, and that fails. Is this what happens here, the server closing the connection?
(In reply to Sebastian Dröge (slomo) from comment #6) > This would happen if the server closes the connection at some point, and > then a new connection is tried with seeking to the old position, and that > fails. Is this what happens here, the server closing the connection? [1] There are 2 TCP streams here ( refer wireshark capture in #c4 ) Stream 0: https://bugzilla.gnome.org/show_bug.cgi?id=771751#c1 Stream 1: https://bugzilla.gnome.org/show_bug.cgi?id=771751#c2 Not sure, if 2 streams is normal here. [2] The second stream is the one which tries to seek. But the server responds with a OK. This sounds ok to me ( not a server closing connection ).
Created attachment 336051 [details] Wireshark http client / server conversation As shown in the attachment image, there are 2 tcp streams as already mentioned. The first tcp stream is active for 181.5 seconds, after which it is closed. The second tcp stream is active for < 1 second, after which it is closed too. In both cases, I see a FIN+ACK going from gstreamer client to the http server. I don't see any FIN / RST from the server side. So, is this gstreamer making a call on terminating the connection ?
Created attachment 336052 [details] TCP summary during failure (In reply to vrishab from comment #8) > In both cases, I see a FIN+ACK going from gstreamer client to the http > server. I don't see any FIN / RST from the server side. So, is this > gstreamer making a call on terminating the connection ? As seen in the attachment, from packets 3207 - 3233, except 3209 ( data sent by http server ) and 3213 ( syn ack by http server ), all others are gstreamer client initiated ( FIN / RST ) etc.
Can you try again with latest gstreamer master ? I think this is now fixed.
-- 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-good/issues/300.