[Bug 701146] New: gnonlin : Don't send flush start flush stop on user demand.

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=701146
  GStreamer | gnonlin | git

           Summary: gnonlin : Don't send flush start flush stop on user
                    demand.
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gnonlin
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: mathieu.duponchelle at epitech.eu
         QAContact: gstreamer-bugs at lists.freedesktop.org
                CC: thibault.saunier at collabora.com
     GNOME version: ---


This caused a bug following that pattern:

Have two sources one after another.
seek in the first source with the flush flag.
Play.
The playback will freeze when passing from a clip to another. A WIP modified
test case is in the linked branch as well.

The bug occured that way :


1) we get a seek ->  comp->priv->user_seek_flush = TRUE
2) at the update at the end of the first clip, no_more_pads gets called
3) user_seek_flush == TRUE -> send flush_start
4) element lost state
5) pipeline updates base time

The proposed patch doesn't use the reset_time argument of flush_stop, as for
some reason the playback becomes correct but you still observe a jump on the
call to update_pipeline.

Instead, it removes all notions of user_seek_flush as we take care of that
ourselves, and the only observed use for this is to break playback ..
Tests still pass, and the observed behaviour in the updated test case is now
correct.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.