Re: mplayerplug-in leaving zombies

Hi Kevin,

Thanks again for your time.

On Mon, Oct 01, 2007 at 09:38:38AM -0600, Kevin DeKorte wrote:
> Forest Bond wrote:
> > As you may remember, my application uses the mplayer plug-in to display
> > television channels.  I am conducting some testing where my code
> > continuously changes the television channel on a delay loop.  The channel is
> > changed by calling Stop(), SetURL(), and then Play().
> 
> might want to try calling "quit()" instead of stop. As that should kill
> mplayer where Stop might try to pause the media. Also instead of
> "SetURL" you might try "Open" or "filename = "tv://x" where x is your
> channel.

Why are there so many different ways to do these things?

> > I find that zombie processes are not being cleaned up properly.  I'm also
> > seeing a hard lock-up on the machine after about 20 minutes or so, although
> > it is not clear to me that those zombies would cause this.
> 
> Can you tell me what version of mplayer you are using? Perhaps you need
> to update you version to make sure that it shuts down properly.

Unfortunately, this is not possibly the source of the problem.  Parent processes
are responsible for reaping their children.  Child processes cannot reap
themselves, and thus have no impact on their own zombie-hood.

> > I see a SIGCHLD signal handler in plugin-threads.cpp, however, it doesn't
> > look like it is actually being registered.  What is the status of this?
> 
> The SIGCHLD handler was unhooked in 3.45 at request from some other
> user. Apparently it was causing the browser to crash or other plugins to
> die in certain situations. Personally I have not seen this, but my usage
> is pretty basic of the plugin.

Well, it probably isn't a good idea for a plugin to register a signal handler, I
guess, since it might be trouncing the browser's signal handlers.  It would be
better to simply wait for the mplayer process to die immediately after killing
it.  mplayer doesn't take that long to die.

On the other hand, I'm not entirely clear as to why the player process is being
killed at all.  Why not keep the slave mplayer process alive for the entire
duration of the plugin instance's life?  That would certainly simplify some of
the thread/process management issues, and would also result in shorter delay
between play, stop, etc.

Also, I've found that things go bad when I do this:

mplayer.filename = 'foo';
mplayer.Play();
mplayer.filename = 'bar';

This seems to be necessary, instead:

mplayer.filename = 'foo';
mplayer.Play();
mplayer.Stop();
# delay here ...
mplayer.filename = 'bar';
mplayer.Play();

However, I see there is a slave command "loadfile" which allows changing the
mplayer URL without stopping playback.  mplayer does what you would expect and
immediately begins playing the new URL.

At the very least, it would be nice to make this feature available as a new
portion of the API.  It would be better, of course, to simplify the API a little
bit, too.  Do you have any strong feelings about this?

One last note: the interface definition mentions an Open method, but that method
doesn't exist.

Thanks,
Forest
-- 
Forest Bond
http://www.alittletooquiet.net

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

_______________________________________________
Mplayerplug-in-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mplayerplug-in-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHAmB+RO4fQQdv5AwRAmJJAJ90cj7Msyrji5m/1lroKJeKM78UbwCgytW+
aqF2oqM0TAoHZUNYZ6WEZgU=
=9+03
-----END PGP SIGNATURE-----