Jason Tackaberry wrote: > + # FIXME: if user calls open() and stop(), we ends up here but > + # this isn't a failed player or broken state.
OK, I see that point. I will think of a way to fix this. > + # 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). Dischi -- Any time things appear to be going better, you have overlooked something.
pgpzTcqRJlG2r.pgp
Description: PGP signature
------------------------------------------------------------------------- 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-cvslog mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freevo-cvslog
