[Bug 735663] New: dashdemux: synchronize with the download loop thread before signalling it

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=735663
  GStreamer | gst-plugins-bad | git

           Summary: dashdemux: synchronize with the download loop thread
                    before signalling it
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: george.kiagiadakis at collabora.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=284805)
 View: https://bugzilla.gnome.org/attachment.cgi?id=284805
 Review: https://bugzilla.gnome.org/review?bug=735663&attachment=284805

[PATCH] dashdemux: synchronize with the download loop thread to  signal it to
continue

There is an issue when dashdemux is working with local files that sometimes the
downloader src element (filesrc) manages to download the whole file before the
"download loop" thread (which has set filesrc to PLAYING) manages to reach its
g_cond_wait() call where it waits for filesrc to send EOS (or ERROR). In that
case, the g_cond_signal() doesn't have any effect and afterwards the "download
loop" thread enters g_cond_wait() and waits forever.

This patch solves the issue by locking the mutex associated with the GCond
before g_cond_signal(), which ensures that g_cond_wait() has been reached.

-- 
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.