Closed GoogleCodeExporter closed 9 years ago
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
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
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
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
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
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
Original issue reported on code.google.com by
igor.con...@gmail.com
on 15 Oct 2009 at 11:30