Thread: [Mplayerplug-in-devel] mplayerplug-in leaving zombies
Brought to you by:
kdekorte
From: Forest B. <fo...@al...> - 2007-10-01 14:44:07
|
Hi, As you may remember, my application uses the mplayer plug-in to display television channels. I am conducting some testing where my code continuous= ly changes the television channel on a delay loop. The channel is changed by calling Stop(), SetURL(), and then Play(). I find that zombie processes are not being cleaned up properly. I'm also s= eeing 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. I see a SIGCHLD signal handler in plugin-threads.cpp, however, it doesn't l= ook like it is actually being registered. What is the status of this? Thanks again for your time. -Forest --=20 Forest Bond http://www.alittletooquiet.net |
From: Kevin D. <kde...@gm...> - 2007-10-01 15:39:03
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forest Bond wrote: > Hi, > > 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. > > 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. > > 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. Kevin - -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHARRx6w2kMH0L1dERAsY6AJ9DpeRWpQRfcGbnHjE9qd3TDo6wbQCdFv+5 ylMwwh4Q08FyiPPlZdRNKFU= =BVzU -----END PGP SIGNATURE----- |
From: Forest B. <fo...@al...> - 2007-10-02 15:15:24
|
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 chann= el is > > changed by calling Stop(), SetURL(), and then Play(). >=20 > 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 =3D "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 al= so > > seeing a hard lock-up on the machine after about 20 minutes or so, alth= ough > > it is not clear to me that those zombies would cause this. >=20 > 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 proc= esses 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? >=20 > 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 handl= er, 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 kill= ing 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 b= eing 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 =3D 'foo'; mplayer.Play(); mplayer.filename =3D 'bar'; This seems to be necessary, instead: mplayer.filename =3D 'foo'; mplayer.Play(); mplayer.Stop(); # delay here ... mplayer.filename =3D '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 l= ittle bit, too. Do you have any strong feelings about this? One last note: the interface definition mentions an Open method, but that m= ethod doesn't exist. Thanks, Forest --=20 Forest Bond http://www.alittletooquiet.net |
From: Kevin D. <kde...@gm...> - 2007-10-03 12:14:36
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forest Bond wrote: > 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? Compatibility with different plugins. And also how some of this stuff works. > 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. The main reason is this. When a media file is over in mplayer "-idle" mode. Mplayer doesn't say that the file is over. It just quits sending output. I've asked them to add this feature or even to add a property that can be queried to see if the file is complete. But so far no good. > > 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(); > Have you tried "quit()" instead of "Stop()"? They actually do different things. > 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? The API is derived from the various plugins we emulate. All those methods are there for a reason. If you would like something added, send a patch, I'll review it and most likely include it. Kevin - -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHA4ek6w2kMH0L1dERAr2PAJ92aUeS7EnayUft30osNM5j8hK3zwCfeNuE FXL7ps2YC/ghx4xo4rzAdJ8= =qzTN -----END PGP SIGNATURE----- |
From: Forest B. <fo...@al...> - 2007-10-03 13:15:09
|
Hi Kevin, On Wed, Oct 03, 2007 at 06:14:28AM -0600, Kevin DeKorte wrote: > Forest Bond wrote: > > 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 displ= ay > >>> television channels. I am conducting some testing where my code > >>> continuously changes the television channel on a delay loop. The cha= nnel 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 =3D "tv://x" where x is your > >> channel. > >=20 > > Why are there so many different ways to do these things? >=20 > Compatibility with different plugins. And also how some of this stuff wor= ks. Ok, that makes some sense, although I suspect things could be simplified at least a little bit, maybe. > > 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 en= tire > > 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. >=20 > The main reason is this. When a media file is over in mplayer "-idle" > mode. Mplayer doesn't say that the file is over. It just quits sending > output. I've asked them to add this feature or even to add a property > that can be queried to see if the file is complete. But so far no good. There is such a property: ---------------------------------------------------------------------------= ----- get_property filename ANS_filename=3Dtest.mpg ---------------------------------------------------------------------------= ----- But after the file has finished playing: ---------------------------------------------------------------------------= ----- get_property filename ---------------------------------------------------------------------------= ----- > > Also, I've found that things go bad when I do this: > >=20 > > mplayer.filename =3D 'foo'; > > mplayer.Play(); > > mplayer.filename =3D 'bar'; > >=20 > > This seems to be necessary, instead: > >=20 > > mplayer.filename =3D 'foo'; > > mplayer.Play(); > > mplayer.Stop(); > > # delay here ... > > mplayer.filename =3D 'bar'; > > mplayer.Play(); > >=20 >=20 > Have you tried "quit()" instead of "Stop()"? They actually do different > things. Yes, I believe I tried it. Both require a delay that is much too long for = my application. Using the loadfile command to mplayer reduces that delay significantly (a power of ten or more, rough estimate). What do quit and Stop do differently? Thanks, Forest --=20 Forest Bond http://www.alittletooquiet.net |
From: Kevin D. <kde...@gm...> - 2007-10-03 14:38:08
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forest Bond wrote: >> The main reason is this. When a media file is over in mplayer "-idle" >> mode. Mplayer doesn't say that the file is over. It just quits sending >> output. I've asked them to add this feature or even to add a property >> that can be queried to see if the file is complete. But so far no good. > > There is such a property: > > -------------------------------------------------------------------------------- > get_property filename > ANS_filename=test.mpg > -------------------------------------------------------------------------------- > > But after the file has finished playing: > > -------------------------------------------------------------------------------- > get_property filename > > -------------------------------------------------------------------------------- Hum, I'll have to look into that... However going with that method will require a massive reorganization of the code to make it work. >> Have you tried "quit()" instead of "Stop()"? They actually do different >> things. > > Yes, I believe I tried it. Both require a delay that is much too long for my > application. Using the loadfile command to mplayer reduces that delay > significantly (a power of ten or more, rough estimate). > > What do quit and Stop do differently? It depends, for streaming media they do the same thing, the tell mplayer to 'quit'. I think tv:// is considered streaming in your case. And this should be immediate, mplayer should not hang or become a zombie. If it is you may want to try compiling the SVN version of mplayer. For non-streaming media quit tells mplayer to quit, stop tells mplayer to seek to position 0 and pause. Kevin - -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHA6ky6w2kMH0L1dERAu0lAKCAJjMdtP0OTc1lqJ0mTjiMacgmBACfWnZK Pt8TaLVCiRUXLX+18TuLsA8= =Y+8i -----END PGP SIGNATURE----- |
From: Forest B. <fo...@al...> - 2007-10-02 15:17:49
|
Hi, In my recent reply to this thread, I complained of method Open being missin= g. That is not the case; I'm trying to figure out what I had been trying to remember when I mistakenly made that claim. In any case, please disregard the error. Thanks, Forest --=20 Forest Bond http://www.alittletooquiet.net |
From: Kevin D. <kde...@gm...> - 2007-10-03 14:48:58
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forest Bond wrote: > There is such a property: > > -------------------------------------------------------------------------------- > get_property filename > ANS_filename=test.mpg > -------------------------------------------------------------------------------- > > But after the file has finished playing: > > -------------------------------------------------------------------------------- > get_property filename > > -------------------------------------------------------------------------------- This check is no good, since mplayer does not respond to the command. If mplayer gave back ANS_filename= Then it would be a good check, but a no response is not suitable for me. I need something where I can determine reliably from mplayer that nothing is loaded. And a non-response is not it. Kevin - -- Get my public GnuPG key from http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7D0BD5D1 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHA6vU6w2kMH0L1dERAuErAKCA3JDbO/ESy0Ta8p//jxaD1+9ZVQCdGvDx NepqOcuSwRuSa/mffU2Xr/o= =JpIr -----END PGP SIGNATURE----- |
From: Forest B. <fo...@al...> - 2007-10-03 16:35:35
|
Hi, On Wed, Oct 03, 2007 at 08:48:52AM -0600, Kevin DeKorte wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Forest Bond wrote: > > There is such a property: > >=20 > > -----------------------------------------------------------------------= --------- > > get_property filename > > ANS_filename=3Dtest.mpg > > -----------------------------------------------------------------------= --------- > >=20 > > But after the file has finished playing: > >=20 > > -----------------------------------------------------------------------= --------- > > get_property filename > >=20 > > -----------------------------------------------------------------------= --------- >=20 > This check is no good, since mplayer does not respond to the command. If > mplayer gave back >=20 > ANS_filename=3D >=20 > Then it would be a good check, but a no response is not suitable for me. >=20 > I need something where I can determine reliably from mplayer that > nothing is loaded. And a non-response is not it. mplayer does send a response, it's just that the response is a blank line. = This is not good enough because you read from the sub-process independently of y= our writes. If you were using libexpect [1] (or equivalent), things would be different. [1] http://www.tcl.tk/man/expect5.31/libexpect.3.html -Forest --=20 Forest Bond http://www.alittletooquiet.net |