Re: [Solved] Re: mpv flags slightly broken

[Mike Kazantsev]

Replied-to message here was sent off-list, probably by accident, so
this is the copy of the reply on the list, as it might be relevant for
anyone else bumping into this issue with recent mpv.

(apologies for repeated message, should've spotted and added ML to Cc
in when sending this reply)


On Fri, 12 Jan 2024 09:07:54 -1000
Bob Newell <bobnewell@bobnewell.net> wrote:

> > No no, I think it's totally a bug in emms-player-mpv.el, as it should:
> >
> >  A. Detect supported IPC method as unix socket correctly. It did not.
> >
> >  B. Do not require input-ipc-server mpv option, as it should pass it in
> >     emms-player-mpv-proc-init on the command line.
> >
> >  C. Work with fifo mode too, or not even have that option.  

> If there are any further details I can send, such as configurations or
> debugging output, I am happy to help, just let me know.  

I've fixed the earlier [A] issue in the git version, by removing fifo
support as mentioned, and wanted to add a few corrections to my earlier
assumptions (and faulty memory):

- mpv --input-file=... option was actually removed from mpv in
  back in 0.33.0 release (2020-11-22), so definitely should not have
  been defaulted-to like this for a while now.

- [C] is plain wrong - modern mpv doesn't support that option anymore,
  as mentioned.

- I've also removed old --input-unix-socket option support, so now emms
  technically requires mpv 0.17.0+ (released in 2016-04-11).
  Probably shouldn't be an issue, as that's release from 8y ago.

- emms-player-mpv-ipc-method value is now meaningless and ignored.
  I've added make-obsolete for it, and changed description to say that.

- Unrelated, but I've also removed internal
  emms-player-mpv-ipc-conn-emacs-26.1-workaround var, as it's also
  probably too old to be useful (and was only needed for a bug in that
  one specific minor version anyway).

Again, thanks for mentioning the issue, that fix and cleanup was long-overdue.


To avoid that long-broken fifo stuff messing things up, you can use 
emms-player-mpv.el backend code from git, which should not have it anymore.

Easiest way to replace the file you have with git version, is probably
to save just that one file from emms repository, via this link:

  https://git.savannah.gnu.org/cgit/emms.git/plain/emms-player-mpv.el

And then remove old .el/.elc file(s), put that new .el there instead:

  # rm /usr/share/emacs/site-lisp/emms/emms-player-mpv.el*
  # cp emms-player-mpv.el /usr/share/emacs/site-lisp/emms/

Paths and such can vary between distros and the way you have emms
installed - e.g. not sure where MELPA would install it, but you can
probably find/replace it easily.


With new file in place, maybe you can check why that "--input-ipc-server"
option fails (or maybe works, and only issue was that old and
unnecessary fifo fallback) - see below.


> As to (B) below, the socket was created long ago and I specify it in my
> command line options (to emms):
> 
> --input-ipc-server=/home/bnewell/.emacs.d/emms/mpv-input.sock
> 
> and this used to be fine.  But even with an explicit 'ipc-socket setting
> this no longer works.  Maybe mpv ignores this option now?  I don't know.  

Hm, why did you have that option manually set there, if you remember?

And did you also have emms-player-mpv-ipc-socket value set to that path?


If answer to latter question is "no", then I suspect it might've been
overidden by emms-supplied conflicting option after that one, and never
was actually used.
Maybe until now, if mpv devs changed how conflicting options are
handled, and that might be the cause for that issue [B] above.


Can you try removing that input-ipc-server option from both mpv
command-line parameters and its config file(s) and run emms just like that?

I.e. there should be no input-ipc-server option set by you anywhere for
mpv - let only emms do it.

If playback doesn't work that way (with something playable in playlist),
try running these elisp commands, in this order:

  (emms-stop)
  (emms-player-mpv-proc-stop)
  (setq emms-player-mpv-debug t)
  (emms-pause)
  (progn (switch-to-buffer "*Messages*") (end-of-buffer))

(see https://www.emacswiki.org/emacs/EvaluatingExpressions for various
ways to run those, but you probably know this well anyway)

What these commands should do, in order:

 - Stop playback, if any (even if not audible).
 - Stop background mpv process, if any.
 - Enable debug output for emms-player-mpv to *Messages* buffer.
 - Try starting emms/mpv playback.
 - Go to end of *Messages* buffer, where last debug-output
   from emms-player-mpv should be.

This should produce lines like these near the end of opened *Messages* buffer:

  emms-player-mpv 0.0 proc[emms-player-mpv]: start
    (mpv --quiet --really-quiet --no-audio-display --input-ipc-server=... 
--idle)
  emms-player-mpv 0.0 ipc: stop
  emms-player-mpv 0.0 ipc: init
  ...

This is where mpv starts for playback (after stopping it earlier),
and output prefixed by "emms-player-mpv" after that should probably
have some actual error info - maybe send/attach all such "emms-player-mpv"
lines from there, and I can see if I can figure out what's the cause
of the problem, probably something simple.

Also, maybe try running exact command-line that is printed there on
"proc[emms-player-mpv]: start ..." line from a terminal, and see if it
runs for you, or crashes and produces some error on stderr?

Run (setq emms-player-mpv-debug nil) or restart emacs to disable
debug-logging in *Messages* after that, when it's no longer needed.


I do suspect it's something simple specifying multiple
--input-ipc-server options manually messing things up, but if you can
follow the steps above and post answers/output to the questions there,
it should probably help fix any other potential cause of the issue.

Or more likely it should already be obvious from whatever errors you
might see during that process :)

Cheers!


-- 
Mike Kazantsev // fraggod.net