Closed GoogleCodeExporter closed 8 years ago
I finally have both the time and tools to reproduce this. Please let me know if
you're still interested.
I'll take a closer look at it this weekend, regardless.
Original comment by igor.con...@gmail.com
on 7 Jul 2011 at 6:47
Okay, so the fix is quite simple:
diff --git a/adapter/mplayer/remuco-mplayer b/adapter/mplayer/remuco-mplayer
index e91cf2b..ebdecd0 100755
--- a/adapter/mplayer/remuco-mplayer
+++ b/adapter/mplayer/remuco-mplayer
@@ -142,7 +142,8 @@ class MplayerAdapter(remuco.PlayerAdapter):
# and the manager will call stop_pa again
remuco.PlayerAdapter.stop(self)
- os.closerange(self.fd_cmd_stream_in, self.fd_status_stream_out)
+ if self.fd_cmd_stream_in is not None:
+ os.closerange(self.fd_cmd_stream_in, self.fd_status_stream_out)
[self.fd_cmd_stream_in, self.fd_cmd_stream_out,
self.fd_status_stream_in, self.fd_status_stream_out] = [None]*4
but all it does is NOT try to close something that hasn't been opened in the
first place. The underlying problem still exists, and it probably will stay
that way until we can find a better way to talk to mplayer.
Basically, remuco-mplayer runs in either of two modes: MASTER, where it spawns
an mplayer process and talks to it via stdin/stdout; and INDEPENDENT, where it
uses named pipes (FIFO files) to work around the fact that mplayer won't export
to anything other than stdout (it does, however, have a slave mode - which we
use - to accept commands).So the trick (
http://code.google.com/p/remuco/wiki/GettingStarted#Usage ) is too 'tee'
mplayer's output so we can non-intrusively read stuff and, to avoid
megabyte-large files, we use pipes instead of regular files.
The problem with that is locking: the threads will not continue until both ends
of the pipe have been "attached", so when you send a SIGHUP to an adapter (in
your case, running in INDEPENDENT) that has never initiated the conversation,
connection will fail.
I could probably spawn yet another thread to maintain the main execution free,
it would be prettier (we would be able to actually "connect" to an adapter),
but there is little to gain: the connection is pointless because there is
nothing to control. You might as well try to connect again after mplayer has
started.
Because mplayer behaves the way it does, INDEPENDENT mode is a nothing more
than a gap-filler: it allows you to continue *controlling* it even if you can't
*poll* it (this is the case, for example, with graphical frontends like
smplayer). My use cases have mostly been with MASTER mode so far, so that itch
has been scratched enough times to make me feel comfortable.
I've committed the bugfix to my github[.com/igoralmeida/remuco]. There should
be no unstable code between that and 0.9.5, so you can try the tip/master
safely. Hopefully Oben will merge it soon.
Original comment by igor.con...@gmail.com
on 3 Aug 2011 at 1:25
[deleted comment]
Will wait for Oben's ACK before closing
Original comment by igor.con...@gmail.com
on 3 Aug 2011 at 1:27
Thanks Igor, merged.
Original comment by obensonne@googlemail.com
on 9 Aug 2011 at 7:01
Original issue reported on code.google.com by
govnotot...@gmail.com
on 25 Apr 2011 at 10:16