Mplayer adapter closes after mplayer quits

[GoogleCodeExporter]

What is your environment?
* OS: Linux
* Remuco version: 0.9.2
* Client device: 0.9.1
* Player: mplayer

What steps will reproduce the problem?
1. Run remuco-mplayer
2. Run mplayer
3. Close mplayer

What is the expected behavior? What happens instead?
The adapter should keep running, but it quits. I need to run remuco-mplayer
again to play more files.

Original issue reported on code.google.com by igor.con...@gmail.com on 15 Oct 2009 at 11:30

[GoogleCodeExporter]

Oben, I took the liberty to add myself as owner of this issue.
I have an idea to fix this, will commit to my fork when my "tests" are done.

Original comment by igor.con...@gmail.com on 16 Oct 2009 at 12:28

• Changed state: Accepted

[GoogleCodeExporter]

Great. Here are some ideas I had and which you might find useful.

Reading and parsing output
--------------------------
In Python you can open files with the 'U' mode (universal new line detection):
>>> f = open("statusfifo", 'rU')
Then '\r' and '\n\r' are detected as line breaks. This has the following 
advantages:
- You don't need to use a buffer with a magic size to read, just use 
f.readline()
- You don't need to use O_NONBLOCK and os.open(), the built-in open() function 
is
  just fine (there is always a new line when '\r' is considered as a line break,
  so readline() should not block)
- As a consequence, when using readline(), parsing the output should be easier.

Startup management
------------------
I had the idea to let the mplayer adapter start mplayer automatically:
$ remuco-mplayer MPLAYER_OPTIONS
Internally mplayer can be started with subprocess.Popen(), passing all
MPLAYER_OPTIONS to mplayer. The great benefit here is that we can safely setup 
the
input=file=.. option and we can directly connect to mplayer's standard output. 
And
users just need to issue a single command.

But these are just ideas, if you have other approaches, do whatever you think 
is best.

Original comment by obensonne@googlemail.com on 16 Oct 2009 at 10:35

[GoogleCodeExporter]

This issue was updated by revision bd74238cd6.

Done a few tests and it seems to be working fine. However, in one of the early
tests, the watch issued a IO_ERR when I closed mplayer, which shouldn't
happen. I haven't been able to reproduce this again.

Original comment by igor.con...@gmail.com on 19 Oct 2009 at 7:09

[GoogleCodeExporter]

As you triggered the call to start() via gobject.idle_add() it will 
_definitely_ run
after __input_event() has returned. So this should work as you intended.

Sometime I've seen the IO_ERR event too on a regular MPlayer quit. So maybe you
should just restart it in any case?

Original comment by obensonne@googlemail.com on 19 Oct 2009 at 7:57

[GoogleCodeExporter]

Revision f872e19ca2a8 is responsible for that.
I tried quite a few times to get a IO_ERR condition but was not successful. It
restarts correctly, though.

Can you test it with later clients (I haven't had the time to start my
divide-and-conquer client test here :( ) so we can have this labeled 'Fixed'?

Original comment by igor.con...@gmail.com on 25 Oct 2009 at 1:05

[GoogleCodeExporter]

Did a test, works with 0.9.2 in my environment. Thanks for working on this!

Original comment by obensonne@googlemail.com on 25 Oct 2009 at 4:21

• Changed state: Fixed