Occasionally I run ffmpeg to transcode videos and this can take up to an hour.
With the latest gnome-terminal, this long-running process gets stopped when the
terminal is not visible. This can be because the frame shows another tab or
because the window is minimized and thus not visible. Using strace I found
that ffmpeg is blocked on outputting its progress report. These are the final
lines of strace output (filtered for write), before ffmpeg is suspended:
write(2, "frame=44221 fps= 12 q=31.5 size= 358656kB time=00:30:45.83
bitrate=1591.8kbits/s speed=0.503x \r", 99) = 99
write(2, "frame=44228 fps= 12 q=31.2 size= 358656kB time=00:30:46.13
bitrate=1591.5kbits/s speed=0.503x \r", 99) = 99
write(2, "frame=44235 fps= 12 q=29.0 size= 358656kB time=00:30:46.43
bitrate=1591.2kbits/s speed=0.503x \r", 99) = 99
write(2, "frame=44243 fps= 12 q=29.1 size= 358656kB time=00:30:46.75
bitrate=1591.0kbits/s speed=0.503x \r", 99
As can be seen, the write call blocks (it does not finish) and ffmpeg is
suspended.
Bringing the tab to the foreground will resume processing and the output.
Trying to reproduce this without ffmpeg, I came up with this little bash one-
liner:
i=0 ; while true ; do echo -e "Some counter $i" ; sleep .5 ; i=$(expr $i + 1) ;
if [ $(( $i % 10 )) == 0 ] ; then echo -ne "\a" ; fi ; done
This will beep every 5 seconds, so we know when the loop is still running fine.
Just start it in the terminal and then minimize the terminal (switching to
other tabs seem not to be a problem for this recipe). The beeps will stop
immediately. After waiting a little while and refocusing the window, I see that
the counter catches up to the correct value in regard to its start time, but
that the output was not consumed anymore. Probably in this case, one needs to
wait longer until a buffer fills up and then finally stops the shell loop. I
guess this is what is happening with the ffmpeg process.
But the test case should be good enough, as xterm running this one-liner
continues to beep all the time, no matter if the terminal is minimized or not.
As I did not have this problem previously, I believe it is a regression that
has entered Debian Trixie in the last few weeks / months.