[gstreamer-bugs] [Bug 553874] New: query_position broken during seek

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=553874

  GStreamer | gstreamer (core) | Ver: 0.10.18
           Summary: query_position broken during seek
           Product: GStreamer
           Version: 0.10.18
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: marcus.brinkmann at ruhr-uni-bochum.de
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


Please describe the problem:
When I query the position of a playbin while a seek occurs, there is a race
condition that the actual position returned is 0, even if the seek is from one
non-null position to another, for example from 3 seconds to 5 seconds.  This
occurs irregardless if the pipeline is paused or playing during the whole
operation.

The race window seems to be located after a state change from PAUSED to PAUSED
with pending PAUSED.  The attached example program illustrates the problem. 
The race is reliably hit in 0.10.18, but also occurs in 0.10.20, although the
window seems smaller.

Other possibilities beside a race condition: It may be that the query_position
call is supposed to fail.  In this case, it should return FALSE instead of
TRUE.  That the function returns TRUE and position 0 may be a different bug. 
Furthermore, if the function is supposed to fail while there are pending state
changes, this should be clearly documented.  I could not find any restriction
on query_position in the documentation of it or that of the pending state.


Steps to reproduce:
1. Run the attached example program on an ogg file that is at least 10 seconds
long.  Also try it with the initial state being PLAYING instead of PAUSING. 
The output and expected output is detailed in a comment in the source. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=553874.