GNOME Bugzilla – Bug 753178
souphttpsrc: error when doing GET Range request with over content size
Last modified: 2017-11-10 09:31:28 UTC
Created attachment 308675 [details] http error log VOD can not be played because of souphttpsrc error. I got two kinds of error like below and I've attached hole log messages. <souphttpsrc0> error: Requested Range Not Satisfiable or <souphttpsrc0> error: Server does not support seeking. I've tested with below command. gst-launch-1.0 souphttpsrc location="http://content.bitsontherun.com/videos/ntPYsD4L-1ahmry41.mp4" ! queue2 temp-template="/tmp/XXXXXX" ! decodebin ! autovideosink
Created attachment 308676 [details] [review] souphttpsrc: add exception handling of GET Range request souphttpsrc allow to seek behind eos in gst_soup_http_src_do_seek so I added additional handling about 416 and 200 header not to be handled as an error. According to the rfc7233, 200 can be replied depends on server. I've extracted it below. 4.4. 416 Range Not Satisfiable ... Note: Because servers are free to ignore Range, many implementations will simply respond with the entire selected representation in a 200 (OK) response. That is partly because most clients are prepared to receive a 200 (OK) to complete the task (albeit less efficiently) and partly because clients might not stop making an invalid partial request until they have received a complete representation. Thus, clients cannot depend on receiving a 416 (Range Not Satisfiable) response even when it is most appropriate.
Created attachment 308715 [details] [review] souphttpsrc: add exception handling of GET Range request revert changed file mod
What exactly do you mean with 'cannot be played'? It seems to work here with git master and I don't see any 416 replies. Do you see it in the GST_DEBUG=*soup*:9 log? Can you attach such log here and what version are you using?
Created attachment 311074 [details] soup log (level 9) I checked the issue on 03 Aug with the latest code at the moment from master. I've added new soup log with the latest master code today except queue2 patch which is uploaded by me (https://bugzilla.gnome.org/show_bug.cgi?id=753011). If you apply the queue2 patch, the issue will be hidden so you can not reproduce the issue. Thank you.
Plays fine with current master and 1.12. Closing.