[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