[Bug 766607] player: problems with unit tests
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Tue May 24 16:36:05 UTC 2016
https://bugzilla.gnome.org/show_bug.cgi?id=766607
--- Comment #12 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
(In reply to Guillaume Desmottes from comment #11)
> (In reply to Sebastian Dröge (slomo) from comment #8)
> > Comment on attachment 328384 [details] [review] [review]
> > player: don't call gst_player_set_subtitle_uri twice in test
> >
> > You mean the callback is reentrant? gst_player_set_subtitle_uri() calls the
> > callback again directly? That seems suspicious
>
> Yes. We first get STATE_CHANGED (playing) and then call
> gst_player_set_subtitle_uri(). While it's running we get a POSITION_UPDATED,
> as the state is still playing and step hasn't been incremented yet we
> re-enter the block.
> Another way to fix this could be to add a "change ==
> STATE_CHANGE_STATE_CHANGED" check before entering into the first if block.
But the signals should all come from the same thread! :) There should be no
other signals while we're in the signal handler of another one.
> (In reply to Sebastian Dröge (slomo) from comment #9)
> > Comment on attachment 328386 [details] [review] [review]
> > player: stop player and disconnect sigs in test
> >
> > Maybe we should also make GstPlayer not emit any signals after stop, other
> > than the state change signal
>
> Something like the patch I just attached?
Does it ensure that we a) get the state_changed=STOPPED signal and b) the
state_changed=BUFFERING signal next time we start playing something, and c) we
get the uri_loaded signal for the next run too?
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list