On Fri, 09 Aug 2024 10:20:33 +0200, Claudio Jeker wrote:
> No. It could be but it may as well be something else.
> Is it enough to play a movie in mpv and ^Z the thing to see the problem?
I think the signal handler gets called multiple times (one for each
thread?) so multiple PIPE_STOP commands are sent down the pipe.
When you resume, it reads the next one and suspends again.
I instrumented terminal_thread() to write "suspending" and "resuming"
in response to PIPE_STOP and PIPE_CONT:
xanth [~] % /usr/ports/pobj/mpv-0.38.0/build-amd64/mpv test.mkv
(+) Video --vid=1 (*) (h264 1280x720 23.976fps)
(+) Audio --aid=1 (*) (ac3 6ch 48000Hz)
AO: [sndio] 48000Hz 5.1(alsa) (5.1) 6ch s16
VO: [gpu] 1280x720 yuv420p
AV: 00:00:03 / 01:30:53 (0%) A-V: -0.000 ct: -0.083suspending
Suspended (signal)
xanth [~] % fg
/usr/ports/pobj/mpv-0.38.0/build-amd64/mpv test.mkv
suspending
[1] + Suspended (signal) /usr/ports/pobj/mpv-0.38.0/build-amd64/mpv
test.mkv
[1] + Suspended (signal) /usr/ports/pobj/mpv-0.38.0/build-amd64/mpv
test.mkv
Suspended (signal)
The correct fix is probably to drain the pipe and only act on the
last command. It seems to work for me.
- todd
--- osdep/terminal-unix.c.orig Fri Aug 9 09:30:35 2024
+++ osdep/terminal-unix.c Fri Aug 9 09:31:10 2024
@@ -421,7 +421,8 @@
}
if (fds[1].revents & POLLIN) {
int8_t c = -1;
- (void)read(stop_cont_pipe[0], &c, 1);
+ while (read(stop_cont_pipe[0], &c, 1) == 1)
+ continue;
if (c == PIPE_STOP) {
do_deactivate_getch2();
if (isatty(STDERR_FILENO)) {
