From: Richard Ash <richard@ys...> - 2007-07-17 22:12:46
>From the point of view of the custom front-end I'm maintaining for automated=20video=20playback=20against=20a=20schedule=20in=20a=20database,=20this=20would=20be=20extremely=20useful,=20because=20I=20have=20a=20TCP/IP=20link=20between=20the=20player=20and=20the=20control=20code,=20so=20it's=20even=20easier=20to=20make=20it=20race=20under=20these=20kind=20of=20conditions,=20as=20well=20as=20being=20badly=20non-robust=20(if=20a=20stop=20event=20is=20delayed=20in=20transit=20so=20it=20shows=20up=20after=20another=20start=20event=20has=20been=20sent,=20then=20it=20gets=20applied=20to=20the=20wrong=20video,=20and=20the=20system=20gets=20very=20confused).
I was thinking along the lines of idea 2, but idea 1 would be useful for error=20handling=20and=20logging=20as=20well.
At Tue, 17 Jul 2007 12:27:10 +0200, Thibaut Mattern wrote:
> That's right. The event is not generated if the playback is
> interrupted by the frontend.
> You've currently no way to know which stream events are related to,
> and no way to synchronize the event loop with the open or stop calls.
> There is several ways to fix the problem.
> Idea 1 : Create a new event and send it when a playback is
> interrupted by the frontend. This way you could implement your counter
> idea without breaking the current xine-lib API.
> Idea 1bis : Create a new event and send it when a xine_open call succeded.
> Idea 2 : Introduce the concept of stream id, which could be a counter
> incremented by the lib each time the frontend calls xine_open (the
> behavior of xine_open could be changed to return the id instead of 1
> in case of success), then events could be tagged with this id.