After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 705076 - queue2: doesn't correctly seek backwards after seeking forwards with download buffering
queue2: doesn't correctly seek backwards after seeking forwards with download...
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: 1.1.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-07-29 13:57 UTC by Sjoerd Simons
Modified: 2013-08-28 11:12 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
proposed patch (1.87 KB, patch)
2013-07-29 13:57 UTC, Sjoerd Simons 		committed Details | Review

Description Sjoerd Simons 2013-07-29 13:57:24 UTC 
Created attachment 250369 [details] [review]
proposed patch

When seeking forwards and then backwards into a section that's not downloaded yet queue2 fails to seek backwards in buffering mode as it doesn't check whether the seek target is before the current downloading range. Simply becuase it doesn't check for this case..

This in particular showed up when doing seeks in ogg which trigger a bisection, which took, well ages.
Comment 1 Sjoerd Simons 2013-07-31 07:51:41 UTC 
(forgot to add the bugzilla link in the commit, sorry)

commit 0b068047354692442aa49bc418b398d2636facf3
Author: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Date:   Mon Jul 29 15:48:32 2013 +0200

    queue2: Fix backwards seeks into undowloaded ranges
    
    When in download buffering mode queue2 didn't check if a range offset is
    in a undownloaded range before the currently in-progress range. Causing
    seeks to an earlier offset to, well, take a while.