On Thu, 2006-11-30 at 18:06 +0100, Dirk Meyer wrote:
> > + # FIXME: if user calls stop() on a playing video, then open(),
> > + # then play(), we could end up here, because stop() does not
> > affect
> > + # state in xine backend until child acknowledges, but open()
> > + # sets state to STATE_OPENING immediately. So we go from
> > + # STATE_OPENING to STATE_IDLE.
>
> I don't understand. If the user calls stop() will stop the player. The
> player itself will stay in STATE_PLAYING until it stops. If we call
> open() later, the open() function will see that the player is still
> running and will call stop() again and wait for the player to
> stop. One problem could be that we stop() a player more than once and
> that could cause problems (not sure of that). But we wait for
> STATE_OPENING until the old player is stopped (see required_states in
> _open which is the real open function).
Right, that's the problem -- stop is being called more than once. The
user calls stop() on a playing video, and then calls open(). It happens
like this:
1. Video is playing, so state is STATE_PLAYING.
2. User calls stop()
3. IPC stop command issued to child, state still STATE_PLAYING
4. User calls open()
5. open() checks state and sees it's STATE_PLAYING, so calls
stop(). So a second stop ipc command issued to child.
6. Child responds to first stop command, and IPCs back to the
parent play_stopped. Parent sets STATE_IDLE.
7. STATE_IDLE is a sufficient state for _open() so it gets called.
State gets set to STATE_OPENING. Meanwhile child is currently
processing the second stop IPC we issued in step 5.
8. Child handles second stop in step 5, and sends play_stopped IPC
to parent. Now it begins working on the open() IPC from step 7.
From the child's perspective, the sequence of commands is fine.
9. Parent receives play_stopped IPC from child. State is set to
STATE_IDLE. So we go from STATE_OPENING to STATE_IDLE and the
parent thinks something is wrong, so kills the child (which is
presently doing the open issued in 7.)
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Freevo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freevo-devel
