remuco-mplayer fails with android client

[GoogleCodeExporter]

What is your environment?
* OS:Linux Mint 10 Julia
* Remuco version:0.9.4
* Client device:android
* Player:mplayer

What steps will reproduce the problem?
1.run remuco-mplayer
2.try to connect using android client (with wi-fi connection and server's ip)
3.connection failed with no error messages
4.stop remuco-mplayer with ctrl+c
5.error message reported into log:

2011-04-26 00:07:55,604 [  ERROR] [     net.py  419] failed to set up bluetooth 
server ((2, 'No such file or directory'))
2011-04-26 00:07:55,614 [   INFO] [     net.py  422] created wifi server
2011-04-26 00:07:55,614 [WARNING] [remuco-mplayer  349] statusfifo file already 
exists. this is not a problem, but you might end up with a big file if 
/home/user/.cache/remuco/mplayer.statusfifo is not a FIFO.
2011-04-26 00:08:53,388 [   INFO] [ manager.py   46] received signal 2
2011-04-26 00:08:53,389 [  ERROR] [ manager.py   61] failed to start player 
adapter ([Errno 4] Interrupted system call: 
'/home/god/.cache/remuco/mplayer.cmdfifo')
2011-04-26 00:08:53,389 [   INFO] [ manager.py   73] stop player adapter
2011-04-26 00:08:53,391 [  ERROR] [ manager.py   77] ** BUG ** an integer is 
required
Traceback (most recent call last):
  File "/usr/lib/pymodules/python2.6/remuco/manager.py", line 75, in _stop_pa
    pa.stop()
  File "/usr/bin/remuco-mplayer", line 145, in stop
    os.closerange(self.fd_cmd_stream_in, self.fd_status_stream_out)
TypeError: an integer is required

What is the expected behavior? What happens instead?

1. errors should be reported right away
2. graceful shutdown expected
3. oh, and it should actually work :)

Additional information:
netstat report python binding to correct port, but connection silently fails - 
no error message of any kind is displayed on android client or remuco server.

Original issue reported on code.google.com by govnotot...@gmail.com on 25 Apr 2011 at 10:16

[GoogleCodeExporter]

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

• Changed state: Chatting

[GoogleCodeExporter]

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

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Will wait for Oben's ACK before closing

Original comment by igor.con...@gmail.com on 3 Aug 2011 at 1:27

• Changed state: Accepted

[GoogleCodeExporter]

Thanks Igor, merged.

Original comment by obensonne@googlemail.com on 9 Aug 2011 at 7:01

• Changed state: Fixed
• Added labels: Component-MPlayer