[gstreamer-bugs] [Bug 607226] Disallow setting the playbin uri property in state >= PAUSED

[GStreamer (bugzilla.gnome.org)]

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

--- Comment #7 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2010-02-04 14:54:30 UTC ---
> This breaks applications

Which applications in which versions? Please be specific.


> (apparently including some patches to make banshee do
> gapless).

"patches"? Well, given that playbin2's API is still declared unstable I'm not
so bothered about "patches" being broken here tbh, but if it would seriously
break existing apps as distributed, that wouldn't be so nice I guess.


> We could warn if you change the uri while about-to-finish isn't being
> processed, but not disallow it.

We should decide what API we want to support, and then implement that while the
API can still be changed. We should only warn if we don't want to allow the
property being used like this.


> We should NOT use a thread-private variable for this - it should be perfectly
> ok to (as banshee does) block the thread processing about-to-finish until the
> main thread sets the next URI.

I agree. Why does it do things like that btw?


> But really, it's ok to change the URI at any time - it has had clear
> semantics in the past (sets the next URI to play), and
> there's no need to change those.

It has worked in the past like that (minus the issues Sjoerd reported, at
least), that doesn't necessarily mean there were 'clear semantics'. I don't
think this was ever documented to work like that.


I think using GObject properties like this is extremely screwy API. However,
alternatives don't seem to be much nicer either, and we don't have a playlist
API, so I guess the best course of action is to allow this for now and revert
the patch.

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