On Fri, Aug 09, 2024 at 10:20:33AM +0200, Claudio Jeker wrote:
> On Fri, Aug 09, 2024 at 08:18:55AM +0200, Walter Alejandro Iglesias wrote:
> > On Thu, Aug 08, 2024 at 09:06:30PM +0200, Claudio Jeker wrote:
> > > On Thu, Aug 08, 2024 at 09:31:47AM -0600, Todd C. Miller wrote:
> > > > You might try changing that raise(SIGSTOP) in terminal_thread() to
> > > > kill(getpid(), SIGSTOP).  You want to stop the entire process, not
> > > > just the terminal thread.
> > > > 
> > > > Prior to that commit, each thread that received SIGTSTP would be
> > > > stopped.  After the commit, only the terminal thread will be stopped.
> > > 
> > > In OpenBSD SIGSTOP is always process level. It will stop all threads but
> > > the handling of SIGSTOP is currently subtly broken.
> > 
> > Can I conclude from this that mpv developers did nothing wrong?  Should
> > I let them know about this and close the issue I opened in github?
> 
> 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?

The problem is that after ^Z you cannot make mpv leave its suspended
state.

  $ mpv --no-config video.mp4		# Press ^Z and then:
  $ fg
  mpv --no-config video.mp4
  [1] + Suspended (signal)   mpv --no-config video.mp4
  $ bg
  [1] mpv --no-config video.mp4 
  [1] + Running              mpv --no-config video.mp4
  $ jobs
  [1] + Suspended (signal)   mpv --no-config video.mp4

It doesn't matter what message fg bg or jobs print, mpv remains
suspended (unresponsive).  To close mpv (at least the only way I found
so far) you have to kill the process:

  $ kill %1

Using SIGCONT (what seems they use in mpv code) does not work.  This
does not wake it up:

  $ kill -SIGCONT %1

Finally, there is a workaround.  Using the GUI mode:

  $ mpv --no-config --profile=builtin-pseudo-gui video.mp4

Using this mpv works as expected.


> 
> -- 
> :wq Claudio
> 

-- 
Walter