Summary: | mplayer-1.0_pre7 process still lives after closing the player window. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Ivan Yosifov <iyosifov> |
Component: | [OLD] Unspecified | Assignee: | Gentoo Media-video project <media-video> |
Status: | RESOLVED NEEDINFO | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Catch SIGPIPE |
Description
Ivan Yosifov
2005-07-22 08:43:36 UTC
(In reply to comment #0) > 3) Check for mplayers again. > > obelix@home ~ $ pgrep -l mplayer > 20755 mplayer > 20756 mplayer > obelix@home ~ $ > > Two of them. Is this normal ? Let's trace them. Yes, it is normal whe you have a cache, -nocache works > 6) Close the movie by clicking on the X in the upper right corner. This is method is only supported when using -vo sdl or gmplayer. Unfortunately some Window Managers think they are especially bright and do something (I was told they just deleted the window) that in the end leads to MPlayer crashing and so the other instance stays around (IMHO that's just like people switching off their PC by pulling the plug - just so you know, my fluxbox version here simply does not show the X) > --- SIGPIPE (Broken pipe) @ 0 (0) --- Hmmm... I guess we could catch SIGPIPE just like SIGKILL and the others, that might make the situation a bit better... > 8) Observe that the second has gone into an infinte loop repeatedly printing: No surprise, it still waits for the other to read from it.. The wm in question is metacity 2.10.2. I am a Gnome user. > Hmmm... I guess we could catch SIGPIPE just like SIGKILL and the others, that > might make the situation a bit better... You mean catch the SIGPIPE in one process and kill both ? I guess this will solve the issue. > Unfortunately some Window Managers think they are especially bright and do > something (I was told they just deleted the window) that in the end leads to > MPlayer crashing and so the other instance stays around I think you should catch all catchable signals that lead to termination ( I guess this means almost all of them, except SIGKILL and few others ) and make sure both processes are terminated. Even if mplayer really crashes ( due to a bug, not due to clicking the X ) the other instance should not stay around. > I think you should catch all catchable signals that lead to termination ( I > guess this means almost all of them, except SIGKILL and few others ) and make It catches most, but getting all and making sure that it still compiles is not that easy (MinGW is especially annoying here). Anyway, it now (CVS) catches also SIGPIPE and SIGHUP, so this particular problem should be fixed (though it still isn't the "gentle" way to quit MPlayer). > sure both processes are terminated. Even if mplayer really crashes ( due to a > bug, not due to clicking the X ) the other instance should not stay around. The other cases were already taken care of (since a long time already). > Anyway, it now (CVS) catches also SIGPIPE and SIGHUP, so this particular
> problem should be fixed (though it still isn't the "gentle" way to quit
> MPlayer).
Great ! Thanks a lot.
Unless you are going to make a new (pre)release soon, can you please post the
patch against mplayer-1.0_pre7 ?
Created attachment 64457 [details, diff]
Catch SIGPIPE
This will stop some effects, but e.g. dpms and the screensaver still won't get
reenabled when you close MPlayer by clicking the close button.
> but e.g. dpms and the screensaver still won't get reenabled
Why not ? What is the problem with reenabling them ?
> > but e.g. dpms and the screensaver still won't get reenabled
> Why not ? What is the problem with reenabling them ?
As I understand it, when MPlayer gets the SIGPIPE it has lost the connection to
the X server, so it simply can't tell X to enable these again...
Hmm... this is a serious problem. A few things come to mind: 1) When the player window is focused I can press q to quit, can't you attach a handler to the close event that quits gracefuly ? 2) You can call "xscreensaver-command -restart" on exit. This will restart the xscreensaver process and restart the idle-timer and clear any disabled-flags off dpms and the screensaver. 3) Can't you reastablish the connection to X to reenable dpms and screensaver ? (In reply to comment #8) > Hmm... this is a serious problem. A few things come to mind: > > 1) When the player window is focused I can press q to quit, can't you attach a > handler to the close event that quits gracefuly ? gmplayer does it, so yes it is possible. But I don't see a chance this will be done by any of the MPlayer developers (thus the bugzilla entry for MPlayer is WONTFIX, but we sure accept patches...) > 2) You can call "xscreensaver-command -restart" on exit. This will restart the > xscreensaver process and restart the idle-timer and clear any disabled-flags off > dpms and the screensaver. > 3) Can't you reastablish the connection to X to reenable dpms and screensaver ? Not acceptable in an exception/trap/fault handler IMHO. > > 2) You can call "xscreensaver-command -restart" on exit.
> Not acceptable in an exception/trap/fault handler IMHO.
Can't "xscreensaver-command -restart" be called before exit without putting in
an exception/trap/fault handler ?
We need just to make sure it is called before exit. For example, I am using the
following script wrapper to do it:
/usr/bin/mplayer "$@"
xscreensaver-command -restart
I have called this mplayer and put it before the real mplayer in my $PATH, as a
workaround.
Cleaning out old bugs, please reopen if still present in newer versions. Thanks Ivan |