[Bug 769894] New: validate: Race when checking whether some actions have completed

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=769894

            Bug ID: 769894
           Summary: validate: Race when checking whether some actions have
                    completed
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: major
          Priority: Normal
         Component: gst-devtools
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: bilboed at bilboed.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

This race happens quite quickly with the GES scrubbing validate tests. The core
reason is because of the way GES timeline posts its own ASYNC messages and
handles seeks asynchronously.

Note : This is *not* an issue in GES.

Take the following scenario (the direction of the seek doesn't matter):
pause, playback-time=0.0
seek, playback-time=0.0, start="duration - 0.5", flags=accurate+flush

* The pause action is executed
* The pipeline prerolls
* The STATE_CHANGED message (READY=>PAUSED) is posted on the bus from a
streaming thread
* The ASYNC_DONE message is posted on the bus from a streaming thread
* The main thread pops out the STATE_CHANGED message from the bus
** The pause action is marked as done
** The next action is executed (flushing seek)
** ges-pipeline posts ASYNC_START and returns TRUE for the seek event
* The main thread pops out the next message (ASYNC_DONE from the initial
preroll)
** it checks for the current action, sees that it's a seek, and marks it as
done
 .. but the seek wasn't executed by then

The visible result of this is seeing such scenarios failing with:
"event: position after a seek is wrong : Reported position after accurate seek
in PAUSED state should be exactly what the user asked for"

Because validate checks the position after it *thinks* the seek event was
executed ... but it wasn't really.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.