GNOME Bugzilla – Bug 562259
Seek in youtube streams causes errors
Last modified: 2010-04-07 12:58:06 UTC
Please describe the problem: When selecting a new video on the youtube-plugin, you can aparently forward it using the progress / time slider bar even if the back end server does not support it. This provoques 2 errors, and on retrying it, it is followed by a pop up saying 'Permission Denied'. Steps to reproduce: 1. Select a video on you tube 2. Move the bottom slider to seek to a further postion 3. Watch more application error pop-ups and eventually 'Permission denied' pop up Actual results: Application errors and video stream interupted Expected results: Video stream carries on playing Does this happen every time? yes. Other information: Totem trace: ** (totem:3253): DEBUG: Init of Python module ** (totem:3253): DEBUG: Registering Python plugin instance: YouTube+TotemPythonPlugin ** (totem:3253): DEBUG: Creating object of type YouTube+TotemPythonPlugin ** (totem:3253): DEBUG: Creating Python plugin instance ** (totem:3253): DEBUG: Init of Python module ** (totem:3253): DEBUG: Registering Python plugin instance: PythonConsolePlugin+TotemPythonPlugin ** (totem:3253): DEBUG: Creating object of type PythonConsolePlugin+TotemPythonPlugin ** (totem:3253): DEBUG: Creating Python plugin instance ** Message: Error: "http://www.youtube.com/get_video?video_id=sq7yKMjz-0c&t=OEgsToPDskKxyFd15HNPZ61kiV0GPHMW": failed to seek; server does not accept Range HTTP header gstsouphttpsrc.c(665): gst_soup_http_src_got_headers_cb (): /GstPlayBin:play/GstSoupHTTPSrc:source ** Message: Error: "http://www.youtube.com/get_video?video_id=sq7yKMjz-0c&t=OEgsToPDskKxyFd15HNPZ61kiV0GPHMW": failed to seek; server does not accept Range HTTP header gstsouphttpsrc.c(665): gst_soup_http_src_got_headers_cb (): /GstPlayBin:play/GstSoupHTTPSrc:source ** Message: Error: "http://www.youtube.com/get_video?video_id=KuaL53XyG8o&t=OEgsToPDskJGn0GprUhe1nUeNabXkHOY": Forbidden gstsouphttpsrc.c(904): gst_soup_http_src_parse_status (): /GstPlayBin:play/GstSoupHTTPSrc:source: 403 Forbidden ** (totem:3253): DEBUG: Finalizing Python plugin instance ** (totem:3253): DEBUG: Finalizing Python plugin instance
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of 524771 ***
Reopening that one. Either we should: - override the seeking as mentioned in bug 524771 comment 12 - or fix Totem to disallow seeking when we see the server doesn't support it first time I think that's fixable within Totem itself.
Created attachment 123815 [details] [review] Disable seeking after a seek error Adds a seek-error signal to both BVW backends (although nothing emits the signal in the xine backend), which is emitted on a seek error and disables seeking in that stream from then onwards. The code in totem.c simply resets the stream.
We already have a way to propagate the current time (through the ticks) and whether a stream is seekable. We just need to make sure this particular stream won't be seekable again.
Created attachment 123822 [details] [review] Disable seeking after a seek error (updated) Dropped the signal.
What's the point of stopping the playback here? It should just disable the seekability, and put the slider back where it was.
I just get internal data flow errors if I do anything except stop the stream: ** Message: Error: Internal data flow error. gstbasesrc.c(2296): gst_base_src_loop (): /GstPlayBin:play/GstSoupHTTPSrc:source: streaming task paused, reason error (-5) I suppose it might be possible to work around the EOS sent by gstbasesrc.c:2297, and the fact that it pauses the pad, but that's getting nasty.
And that's fixed with the work for download buffering in Totem 2.30.x. Current master has a fix for non-fast-start FLV files as well.