I can't foreground or background mpv from terminal after suspending it with Ctrl-Z #14355
Comments
|
Can't reproduce on Linux. |
|
On Fri, Jun 14, 2024 at 08:10:14AM -0700, Guido Cella wrote:
Can't reproduce on Linux.
As I said in my report. Nor under FreeBSD with mpv 0.37 version.
…
--
Reply to this email directly or view it on GitHub:
#14355 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
--
Walter
|
|
On Fri, Jun 14, 2024 at 08:10:14AM -0700, Guido Cella wrote:
Can't reproduce on Linux.
In case you assume this is an OpenBSD issue, please note that this is
the only application I experience this issue with (and I already
mentioned the issue at ***@***.***).
…
--
Reply to this email directly or view it on GitHub:
#14355 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
--
Walter
|
|
Probably caused by something in b75b56f. But none of the developers use BSD. |
|
I forgot to mention that, as a workaround, I use this setting in mpv.conf: With that the problem desappears. |
Today I downloaded and compiled mpv 0.38.0 from source. Painfully (since I didn't find a way of downloading the diff from github) I reverted the diff from the b75b56f commit you pointed me out. Well, you nailed it, that's the change that introduced the regression. Without those changes the issue disappears. |
|
@N-R-K: Do you want to take a look into it? |
Sure, I'll look at it. But it may take me a bit. In the meanwhile, if you (@walterigle) can use gdb to step through what's going on in |
I've used gdb very rarely against core files, asked by some developer in If I did it wrong tell me which command should I use, please. $ gdb ~/Desktop/mpv-0.38.0/build/mpv Program received signal SIGTSTP, Stopped (user). Program received signal SIGTSTP, Stopped (user). Program received signal SIGTSTP, Stopped (user). Program received signal SIGTSTP, Stopped (user). |
|
I accidentally closed the issue, thanks I found how to reopen it again. :-) Guys, wouldn't be easier to use a mailing list? |
To some for sure, but for many it would become much less accessible. Anyway, it is what it is... and it's not too hard to click the "reopen" button either ;) |
|
Let's see if now I got what N-R-K asked me: (gdb) bt |
|
I think gdb was not a good suggestion. What I really wanted was some overview of what the hell is going on. Here's a quick and dirty patch that adds some logging (untested, not sure if it even compiles): diff --git a/osdep/terminal-unix.c b/osdep/terminal-unix.c
index 6f7054887..892570b68 100644
--- a/osdep/terminal-unix.c
+++ b/osdep/terminal-unix.c
@@ -437,6 +437,8 @@ static void quit_request_sighandler(int signum)
errno = saved_errno;
}
+#define LOG(MSG) (fprintf(stderr, "%d: " MSG "\n", __LINE__), fflush(stderr))
+
static MP_THREAD_VOID terminal_thread(void *ptr)
{
mp_thread_set_name("terminal/input");
@@ -461,13 +463,16 @@ static MP_THREAD_VOID terminal_thread(void *ptr)
bool is_fg = tcgetpgrp(tty_in) == getpgrp();
int r = polldev(fds, stdin_ok && is_fg ? 3 : 2, buf.len ? ESC_TIMEOUT : INPUT_TIMEOUT);
if (fds[0].revents) {
+ LOG("got death pipe activity");
do_deactivate_getch2();
break;
}
if (fds[1].revents & POLLIN) {
+ LOG("got stop/cont pipe activity");
int8_t c = -1;
(void)read(stop_cont_pipe[0], &c, 1);
if (c == PIPE_STOP) {
+ LOG("stopping");
do_deactivate_getch2();
if (isatty(STDERR_FILENO)) {
(void)write(STDERR_FILENO, TERM_ESC_RESTORE_CURSOR,
@@ -479,13 +484,16 @@ static MP_THREAD_VOID terminal_thread(void *ptr)
// effectively the same thing.
raise(SIGSTOP);
} else if (c == PIPE_CONT) {
+ LOG("continuing");
getch2_poll();
}
}
if (fds[2].revents) {
int retval = read(tty_in, &buf.b[buf.len], BUF_LEN - buf.len);
- if (!retval || (retval == -1 && errno != EINTR && errno != EAGAIN && errno != EIO))
+ if (!retval || (retval == -1 && errno != EINTR && errno != EAGAIN && errno != EIO)) {
+ LOG("breaking out");
break; // EOF/closed
+ }
if (retval > 0) {
buf.len += retval;
process_input(input_ctx, false);Not sure if it will reveal anything interesting or not, but worth a shot. |
|
Hi NRK,
On Thu, Jun 27, 2024 at 10:37:45AM -0700, NRK wrote:
I think gdb was not a good suggestion. What I really wanted was some
overview of what the hell is going on. Here's a quick and dirty patch
that adds some logging (untested, not sure if it even compiles):
I compiled mpv with your diff, I ran it, press Ctrl-Z and then tried to
fg. This is the output.
~/mpv-0.38.0$ build/mpv --no-config ~/Videos/video.mp4
(+) Video --vid=1 (*) (h264 640x480 30.000fps)
(+) Audio --aid=1 (*) (aac 2ch 48000Hz)
[vo/gpu] Disabling scaler #0 lanczos (GLSL version too old).
[vo/gpu] Disabling scaler #1 hermite (GLSL version too old).
[vo/gpu] Disabling linear/sigmoid scaling (GLSL version too old).
[vo/gpu] correct-downscaling requires non-bilinear scaler.
AO: [sndio] 48000Hz stereo 2ch s16
VO: [gpu] 640x480 yuv420p
AV: 00:00:00 / 00:04:52 (0%) A-V: -0.002426: got stop/cont pipe activity
AV: 00:00:01 / 00:04:52 (0%) A-V: -0.001430: stopping
[1] + Suspended (signal) build/mpv --no-config ~/Videos/video.mp4
~/Desktop/mpv-0.38.0[1]$ fg
build/mpv --no-config ~/Videos/video.mp4
426: got stop/cont pipe activity
430: stopping
[1] + Suspended (signal) build/mpv --no-config ~/Videos/video.mp4
… [...]
Not sure if it will reveal anything interesting or not, but worth a shot.
--
Reply to this email directly or view it on GitHub:
#14355 (comment)
You are receiving this because you modified the open/close state.
Message ID: ***@***.***>
--
Walter
|
mpv Information
Important Information
Reproduction Steps
The more similar issue I found reported is the one described in this
report in 2020:
#8120
Except for in my case pressing Enter doesn't work, I have to kill the
process.
It doesn't happen with mpv 0.38.0 under Debian testing, nor with mpv
0.37 under Freebsd 14.1. So far this only happens on OpenBSD.
Expected Behavior
mpv should leave the suspended state.
Actual Behavior
mpv stays in suspended state.
Log File
output.txt
Sample Files
No response
I carefully read all instruction and confirm that I did the following:
--log-file=output.txt.The text was updated successfully, but these errors were encountered: