GNOME Bugzilla – Bug 334973
Cannot seek in HTTP streams
Last modified: 2008-02-15 05:24:26 UTC
Please describe the problem: Thanks for the bugfix of 333375! Now it works. However, I cannot seek back or forward... Steps to reproduce: 1. Go to http://www.nos.nl/nosjournaal/archief/index.html 2. Find a day where there are streams archived, in section "NOS Radio 1 Journaal" (there is a calendar on the right) 3. Click on any "uitzending" link 4. Open the ASX file in Totem 5. Play it 6. Move the seek cursor Actual results: The sound playback stops. The time indicator says "Playing" and the time you sought to. The play/pause button shows the pause logo. Yet, no sound plays and the time indicator does not go. If the pause button is pressed, playing resumes from where it stopped (and not from where you sought to) Expected results: After the cursor has been moved, the stream should be played from a different point Does this happen every time? Yes Other information:
We don't really support seeking over http yet, so I suppose the real bug for now is that the seek bar isn't disabled here like it should be.
gstreamer bug for providing http seeking support is bug #354590. This bug could be marked as dependent on that one. Also the bug title could be changed to "Cannot seek http sources" With a lot of talk about Online Desktop, there should not be such a big gap in playing local streams vs. http streams.
Where's the HTTP stream? The only things I can find are MMS streams, which we don't look like being able to seek in yet.
I too could not find http streams on this sites but here is a http stream that does not seek: http://www.archive.org/download/rewards_fairies_0807_librivox/rewardsandfairies_01_kipling.ogg
the same file downloaded to the disk seeks fine. The gnomevfssrc does not see the http stream as seekable even though the headers say the server does Accept-Ranges: bytes gnomevfssrc does not open the stream with GNOME_VFS_OPEN_RANDOM because of fear failing in case there is no seeking. A second try to server without random is not allowed by servers such as last.fm. Running gst-launch-0.10 gnomevfssrc location=http://www.archive.org/download/rewards_fairies_0807_librivox/rewardsandfairies_01_kipling.ogg ! oggdemux ! vorbisdec ! audioconvert ! alsasink shows the following output from basesrc: 0:00:01.909259000 26908 0x804e088 DEBUG basesrc gstbasesrc.c:2009:gst_base_src_start:<gnomevfssrc0> setting size 2346193 0:00:01.909280000 26908 0x804e088 DEBUG basesrc gstbasesrc.c:2020:gst_base_src_start:<gnomevfssrc0> format: 2, have size: 1, size: 2346193, duration: 2346193 0:00:01.909301000 26908 0x804e088 DEBUG basesrc gstbasesrc.c:2028:gst_base_src_start:<gnomevfssrc0> is seekable: 0 0:00:01.909319000 26908 0x804e088 DEBUG basesrc gstbasesrc.c:2034:gst_base_src_start:<gnomevfssrc0> is random_access: 0 Bug #354590 and the corresponding mailing list thread has all this discussed.
Ok, so this is fixed now in gnome-vfs as it actually is a gnome-vfs bug :) While the docs say that one doesn't get seeking when GNOME_VFS_OPEN_RANDOM is not given no module other than http did this in the past but instead allowed seeking always. And then the http module failed to open an URI with _OPEN_RANDOM if the server does not support seeking while instead it should just fail on seeks then. This revision fixes it: http://svn.gnome.org/viewvc/gnome-vfs?view=revision&revision=5446 No changes to gnomevfssrc are necessary at all :)