Discussion:
[emms-help] emms-player-mpv ipc-error: connection-error
Mike Kazantsev
2018-06-06 20:28:47 UTC
Permalink
On Mon, 4 Jun 2018 17:37:52 +0500
On Mon, 04 Jun 2018 13:59:15 +0300
I have the same problem on my work and home computer, both have Ubuntu 18.10.
...
Given such signal exit, suspect that it might be some kind of bug in
that specific mpv build.
...
Will add more logging first though and report back.
Might be able to reproduce it here in a VM as well, given that it's a
stock distro, which should be easy to spin up.
Have tried to get same error in qemu/kvm on latest Ubuntu 18.10 iso from
http://cdimage.ubuntu.com/daily-live/pending/ (latest is 2018-06-06 07:51 atm).
Pre-release version, since I think release for 18.10 should only be in october.

Did "apt install emacs emms mpv", copying over emms-player-mpv.el from
current git to ~/.emacs.d/lisp/, and using following emacs config:

(require 'emms)
(add-to-list 'load-path "/home/mk-fg/.emacs.d/lisp")
(require 'emms-player-mpv)
(setq-default
emms-player-list '(emms-player-mpv)
emms-player-mpv-debug t)

(defmacro iwrapm (func &rest args)
`(lambda () (interactive) (,func ,@args)))

(global-set-key (read-kbd-macro "<f5>")
(iwrapm switch-to-buffer "*Messages*"))
(global-set-key (read-kbd-macro "<f6>")
(iwrapm emms-play-url "http://www.ibiblio.org/wcpe/wcpe.pls"))
(global-set-key (read-kbd-macro "<f7>") 'emms)
(global-set-key (read-kbd-macro "<f8>") 'emms-add-directory)

Pressing F5 and F6 in sequence opened Message buffer there and started
playing specified playlist without any issues.

mpv there seem to be same version as you use - 0.27.2, though it reports
"ffmpeg version: 3.4.2-2build1" instead of simply "3.4.2-2" in your
--version output.
Package versions: mpv 0.27.2-1ubuntu1, libav* 3.4.2-2build1.

So doesn't look like it's due to distro-specific mpv build, at least at
this point.


I'd suggest to:

- Run "apt upgrade" - see if maybe some libs on your machines were
updated roughly at the same time and had some issue that's resolved
in the repos by now.

- Run mpv with socket option without emacs:

mpv --quiet --really-quiet --no-audio-display --idle \
--input-ipc-server=/home/reich/.emacs.d/emms-player-mpv-ipc.sock

See if it crashes - probably should, as emacs does same thing.

- If it does crash, re-run it as "strace -f -s16384 ... 2>mpv-strace.log",
where ... is the same command, check or attach mpv-strace.log to an
email here, which might help to see what mpv does last before the
crash in rough syscall outlines.

- If that doesn't help, or you have a bit more time on your hands,
install gdb (GNU debugger) package, and run same command as "gdb
-args ...", use "r" command in prompt there to start mpv, then
"bt full" to see the backtrace once it crashes.

Which might show which libs you need to install *-dbg packages for
to see more useful info (with function names and arguments in
there), then repeat the process.


Looks like either some issue specific to your setup (but shared on two
machines somehow), or maybe some faulty lib dependency in pre-release
18.10, either of which seem unlikely to be common.

So other than that workaround with 'file and looking more into the cause
on these systems as described above, can't think of anything else to suggest.
--
Mike Kazantsev // fraggod.net
Bob Newell
2018-06-08 19:58:52 UTC
Permalink
I had a sort-of similar problem with my emms/mpv installation for
termux. After the last update:

(1) Nothing played out of the box but the 'file workaround quickly fixed that.

(2) I had to modify my volume-control code to reflect a different file
name for the command drop file, but once I did that everything was
back to 100% operation.

--
Bob Newell
Honolulu, Hawai`i

Sent via Linux Mint 17.
Mike Kazantsev
2018-06-08 21:14:40 UTC
Permalink
On Fri, 8 Jun 2018 09:58:52 -1000
Post by Bob Newell
I had a sort-of similar problem with my emms/mpv installation for
(1) Nothing played out of the box but the 'file workaround quickly fixed that.
(2) I had to modify my volume-control code to reflect a different file
name for the command drop file, but once I did that everything was
back to 100% operation.
Can you enable and check debug output in *Messages* as suggested along
with that workaround, and see if it looks like similar crash, with mpv
exiting on signal?

And if so, maybe you can run mpv with strace or gdb, as suggested in
the latest mail in that thread?

Can be entirely separate issue too, of course.
--
Mike Kazantsev // fraggod.net
Bob Newell
2018-06-09 01:24:14 UTC
Permalink
I changed my Termux setup back to generic (not using 'file) and ... this
time it worked! Surely the previous problem must have been that I had
custom code which was based on an EMMS older release, and that must have
caused a malfunction; in other words, user error. But I took the
opportunity to simplify my code while making it compatible, and all issues
went away.

So I can't offer you any useful insights other than the usual caveat about
users (such as myself) needing to ensure there isn't a 'mixed'
installation,.

The upside, though, is that the new emms-mpv is obviously solid, and is
working perfectly on my Android tablet termux installation. Volume control,
seeking, etc. ... all perfect.

Bob Newell
Honolulu
Mike Kazantsev
2018-06-09 02:14:02 UTC
Permalink
On Fri, 8 Jun 2018 15:24:14 -1000
Post by Bob Newell
I changed my Termux setup back to generic (not using 'file) and ... this
time it worked! Surely the previous problem must have been that I had
custom code which was based on an EMMS older release, and that must have
caused a malfunction; in other words, user error.
Don't think such breaking changes in emacs packages are always user
error, as sometimes such breakages can be avoided.

In case of emms-player-mpv guess it gotta be that emms
started/stopped state changes are no longer synchronous with start/stop
commands, which I don't really know if maybe a misfeature.

On one hand it neither blocks emacs until mpv responds nor assumes
player state changes at any point (e.g. sends emms-player-started as
soon as mpv binary is found, like it was before), on the other it can
break existing user code and require more complex two-step handling of
start/stop stuff.

It might be easy to work around by doing either of "bad" things
mentioned above - either blocking or just assuming mpv state without
waiting for it.

If anyone has strong opinion on whether it should be strictly
synchronous and/or strictly compatible that way - let me know.
Post by Bob Newell
The upside, though, is that the new emms-mpv is obviously solid, and is
working perfectly on my Android tablet termux installation. Volume control,
seeking, etc. ... all perfect.
Great.
Hopefully should eat a bit less into battery that way too, as it won't
need to restart whole mpv between each track in non-'file mode anymore.

As you've mentioned --input-file path and volume earlier, note that
behavior wrt both of these should also change:

- --input-file won't be used at all, unless you add it to
emms-player-mpv-parameters list.

- Software volume level (if used, should be mpv default) should stay
persistent until emacs restart, as mpv won't be restarted between
playlist entries either, keeping all such settings.
--
Mike Kazantsev // fraggod.net
Konstantin Reich
2018-06-18 19:11:50 UTC
Permalink
Mike,

Thank you for your help. Recently, i was behind the curve and was not able to answer.

I run
Post by Mike Kazantsev
mpv --quiet --really-quiet --no-audio-display --idle \
--input-ipc-server=/home/reich/.emacs.d/emms-player-mpv-ipc.sock some.mp3
and do not get any error. mpv plays file normally.


I used emacs -Q with loaded emms from the directory ~/.emacs.d/elpa/emms-......

and your config. Got the same error.


Maybe the problem me using emacs 26?
Post by Mike Kazantsev
On Mon, 4 Jun 2018 17:37:52 +0500
 On Mon, 04 Jun 2018 13:59:15 +0300
 > I have the same problem on my work and home computer, both have Ubuntu 18.10.
...
 Given such signal exit, suspect that it might be some kind of bug in
 that specific mpv build.
...
 Will add more logging first though and report back.
 Might be able to reproduce it here in a VM as well, given that it's a
 stock distro, which should be easy to spin up.
Have tried to get same error in qemu/kvm on latest Ubuntu 18.10 iso from
http://cdimage.ubuntu.com/daily-live/pending/ (latest is 2018-06-06 07:51 atm).
Pre-release version, since I think release for 18.10 should only be in october.
Did "apt install emacs emms mpv", copying over emms-player-mpv.el from
  (require 'emms)
  (add-to-list 'load-path "/home/mk-fg/.emacs.d/lisp")
  (require 'emms-player-mpv)
  (setq-default
    emms-player-list '(emms-player-mpv)
    emms-player-mpv-debug t)
  (defmacro iwrapm (func &rest args)
  (global-set-key (read-kbd-macro "<f5>")
    (iwrapm switch-to-buffer "*Messages*"))
  (global-set-key (read-kbd-macro "<f6>")
    (iwrapm emms-play-url "http://www.ibiblio.org/wcpe/wcpe.pls"))
  (global-set-key (read-kbd-macro "<f7>") 'emms)
  (global-set-key (read-kbd-macro "<f8>") 'emms-add-directory)
Pressing F5 and F6 in sequence opened Message buffer there and started
playing specified playlist without any issues.
mpv there seem to be same version as you use - 0.27.2, though it reports
"ffmpeg version: 3.4.2-2build1" instead of simply "3.4.2-2" in your
--version output.
Package versions: mpv 0.27.2-1ubuntu1, libav* 3.4.2-2build1.
So doesn't look like it's due to distro-specific mpv build, at least at
this point.
 - Run "apt upgrade" - see if maybe some libs on your machines were
   updated roughly at the same time and had some issue that's resolved
   in the repos by now.
     mpv --quiet --really-quiet --no-audio-display --idle \
      --input-ipc-server=/home/reich/.emacs.d/emms-player-mpv-ipc.sock
   See if it crashes - probably should, as emacs does same thing.
 - If it does crash, re-run it as "strace -f -s16384 ... 2>mpv-strace.log",
   where ... is the same command, check or attach mpv-strace.log to an
   email here, which might help to see what mpv does last before the
   crash in rough syscall outlines.
 - If that doesn't help, or you have a bit more time on your hands,
   install gdb (GNU debugger) package, and run same command as "gdb
   -args ...", use "r" command in prompt there to start mpv, then
   "bt full" to see the backtrace once it crashes.
   Which might show which libs you need to install *-dbg packages for
   to see more useful info (with function names and arguments in
   there), then repeat the process.
Looks like either some issue specific to your setup (but shared on two
machines somehow), or maybe some faulty lib dependency in pre-release
18.10, either of which seem unlikely to be common.
So other than that workaround with 'file and looking more into the cause
on these systems as described above, can't think of anything else to suggest.
--
Mike Kazantsev // fraggod.net
Mike Kazantsev
2018-06-19 04:20:48 UTC
Permalink
On Mon, 18 Jun 2018 22:11:50 +0300
Post by Konstantin Reich
Mike,
Thank you for your help. Recently, i was behind the curve and was not able to answer.
No worries.
Post by Konstantin Reich
I used emacs -Q with loaded emms from the directory ~/.emacs.d/elpa/emms-......
and your config. Got the same error.
Maybe the problem me using emacs 26?
Oh, I didn't think of that, and just tried it here with updated emacs,
and yes - same exact error, looks like some kind of change in how
processes are handled there.

Will fix and report back, thanks for mentioning it!
--
Mike Kazantsev // fraggod.net
Mike Kazantsev
2018-06-19 16:06:15 UTC
Permalink
On Tue, 19 Jun 2018 09:20:48 +0500
Post by Mike Kazantsev
On Mon, 18 Jun 2018 22:11:50 +0300
Post by Konstantin Reich
Maybe the problem me using emacs 26?
Oh, I didn't think of that, and just tried it here with updated emacs,
and yes - same exact error, looks like some kind of change in how
processes are handled there.
Will fix and report back, thanks for mentioning it!
Did find what looks like a bug in emacs-26, and reported it here:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31901

There are simple workarounds for it (aside from that 'file one), like
"(setq emms-player-mpv-ipc-connect-delays '(1))", using tcp socket on
localhost, or adding some ipc connection restart timer, but wanted
someone to maybe comment on the bug first, in case I might be using the
thing wrong wrt emacs-26 :nowait changes or something.

And if it's indeed such an obvious bug, could be patched quickly and
require no additional hacks anyway :)
--
Mike Kazantsev // fraggod.net
Mike Kazantsev
2018-06-30 17:08:53 UTC
Permalink
On Tue, 19 Jun 2018 21:06:15 +0500
Post by Mike Kazantsev
On Tue, 19 Jun 2018 09:20:48 +0500
Post by Mike Kazantsev
On Mon, 18 Jun 2018 22:11:50 +0300
Post by Konstantin Reich
Maybe the problem me using emacs 26?
Will fix and report back, thanks for mentioning it!
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=31901
There seem to have been another similar issue filed with :nowait for
server sockets as well, but unfortunately neither got any attention so far.

So implemened and pushed a workaround to simply disable :nowait
in emacs-26 and later versions until that issue will be resolved.

I think this should only impact emacs performance if mpv process
becomes unresponsive and ipc socket buffers fill up, which should not
happen normally.

Workaround with 'file as emms-player-mpv-ipc-method should no longer be
necessary, and I'd appreciate if you can test and confirm that it works
in your case as well.

Again, thanks a lot for helping to track down this issue.
I'm usually lagging a bit behind OS updates, so probably wouldn't have
spotted it for a while, despite emacs-26.1 being available in Arch repos.
--
Mike Kazantsev // fraggod.net
Konstantin Reich
2018-07-01 08:40:44 UTC
Permalink
Mike,

I have updated emms (20180630.945) with your commit
(emms-player-mpv-ipc-conn-emacs-26-workaround). Still I get the same
error when i comment the line "emms-player-mpv-ipc-method 'file"
Mike Kazantsev
2018-07-01 09:53:20 UTC
Permalink
On Sun, 01 Jul 2018 11:40:44 +0300
Post by Konstantin Reich
Mike,
I have updated emms (20180630.945) with your commit
(emms-player-mpv-ipc-conn-emacs-26-workaround). Still I get the same
error when i comment the line "emms-player-mpv-ipc-method 'file"
Hmm, interesting, can you run the following s-exp:

(progn
(setq emms-player-mpv-debug t)
(emms-player-mpv-debug-msg
"---------- emacs version: %s %s"
(subst-char-in-string ?\n ? (emacs-version))
emms-player-mpv-ipc-conn-emacs-26-workaround)
(emms-player-mpv-proc-stop)
(emms-player-mpv-ipc-stop)
(emms-play-url "https://somafm.com/sf1033130.pls"))

And send/attach the output in *Messages* buffer, starting with that
"--- emacs version: ..." line?

(can paste that sexp into any buffer, then use M-x eval-last-sexp)

It should stop mpv process and connection to it, then restart it all
with emms-player-mpv-debug enabled, so that everything from mpv/ipc
start will end up in that Messages buffer, including emacs version,
in case maybe there's some other difference there.
--
Mike Kazantsev // fraggod.net
Konstantin Reich
2018-07-01 10:29:06 UTC
Permalink
This is what i get when i run your code

emms-player-mpv 0.0 ---------- emacs version: GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-05-22 nil
emms-player-mpv 0.1 proc[emms-player-mpv]: start (mpv --quiet --really-quiet --no-audio-display --input-ipc-server=/home/reich/.emacs.d/emms/mpv-ipc.sock --idle)
emms-player-mpv 0.1 ipc: init
emms-player-mpv 0.2 ipc: connect-delay 0.1
EMMS: All track information loaded.

At this point i go to the emms buffer and start to play the
https://somafm.com/sf1033130.pls. I get the following

emms-player-mpv 9.0 json >> {"command":["loadfile","https://somafm.com/sf1033130.pls","replace"],"request_id":1}
emms-player-mpv 9.0 proc[emms-player-mpv]: stop
emms-player-mpv 9.0 proc[emms-player-mpv<1>]: start (mpv --quiet --really-quiet --no-audio-display --input-ipc-server=/home/reich/.emacs.d/emms/mpv-ipc.sock --idle)
emms-player-mpv 9.0 json >> {"command":["loadfile","https://somafm.com/sf1033130.pls","replace"],"request_id":2}
emms-player-mpv 9.0 proc[emms-player-mpv<1>]: stop
emms-player-mpv ipc-error: connection-error
emms-player-mpv 9.0 proc[emms-player-mpv<2>]: start (mpv --quiet --really-quiet --no-audio-display --input-ipc-server=/home/reich/.emacs.d/emms/mpv-ipc.sock --idle)
emms-player-mpv 9.0 json >> {"command":["loadfile","https://somafm.com/sf1033130.pls","replace"],"request_id":3}
emms-player-mpv 9.0 proc[emms-player-mpv<2>]: stop
emms-player-mpv ipc-error: connection-error
emms-player-mpv 9.0 proc[emms-player-mpv<3>]: start (mpv --quiet --really-quiet --no-audio-display --input-ipc-server=/home/reich/.emacs.d/emms/mpv-ipc.sock --idle)
emms-player-mpv 9.0 json >> {"command":null,"request_id":4}
emms-player-mpv 9.0 proc[emms-player-mpv<3>]: stop
emms-player-mpv 9.0 proc[emms-player-mpv<4>]: start (mpv --quiet --really-quiet --no-audio-display --input-ipc-server=/home/reich/.emacs.d/emms/mpv-ipc.sock --idle)
emms-player-mpv 9.0 json >> {"command":["set","pause","no"],"request_id":5}
emms-player-mpv 9.0 proc[emms-player-mpv<4>]: stop
emms-player-mpv ipc-error: connection-error
emms-player-mpv 9.1 proc[emms-player-mpv<4>]: interrupt (status=signal, playing=nil)
emms-player-mpv 9.1 proc[emms-player-mpv<3>]: interrupt (status=signal, playing=nil)
emms-player-mpv 9.1 proc[emms-player-mpv<2>]: interrupt (status=signal, playing=nil)
emms-player-mpv 9.1 proc[emms-player-mpv<1>]: interrupt (status=signal, playing=nil)
emms-player-mpv 9.1 proc[emms-player-mpv]: exited abnormally with code 4 (status=exit, playing=nil)
Mike Kazantsev
2018-07-01 10:41:35 UTC
Permalink
On Sun, 01 Jul 2018 13:29:06 +0300
Post by Konstantin Reich
This is what i get when i run your code
emms-player-mpv 0.0 ---------- emacs version: GNU Emacs 26.1 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.22.30) of 2018-05-22 nil
I think issue is right here - that "nil" at the end is value for
emms-player-mpv-ipc-conn-emacs-26-workaround, apparently it was not set
correctly, despite same version of emacs as I have here.

It should be set upon its definition via:

(defvar emms-player-mpv-ipc-conn-emacs-26-workaround (>= emacs-major-version 26) ...)

You don't have it disabled or overidden manually somewhere, by chance?

Really struggling to think how else it might be initialized to nil value
at the moment - "(>= emacs-major-version 26)" should return t for sure
with your version.
--
Mike Kazantsev // fraggod.net
Mike Kazantsev
2018-07-01 10:51:12 UTC
Permalink
On Sun, 1 Jul 2018 15:41:35 +0500
Post by Mike Kazantsev
(defvar emms-player-mpv-ipc-conn-emacs-26-workaround (>= emacs-major-version 26) ...)
You don't have it disabled or overidden manually somewhere, by chance?
Really struggling to think how else it might be initialized to nil value
at the moment - "(>= emacs-major-version 26)" should return t for sure
with your version.
Can you run this:

(describe-variable 'emms-player-mpv-ipc-conn-emacs-26-workaround)

(alternatively, "C-h v" or "M-x describe-variable" then type that
variable name in minibuffer with auto-completion)

It should open *Help* buffer which would say where this var was
defined, along with its value.

Is it still nil there?
And if so, was is it defined/initialized in emms-player-mpv.el at the
correct ELPA path or maybe somewhere else?

It's a long shot, but at least can explain how nil value might end up there,
if something else picked-up and initializing this var before emms does.
--
Mike Kazantsev // fraggod.net
Konstantin Reich
2018-07-01 19:31:54 UTC
Permalink
Mike,

Yeah i cannot figure out what it is going on.
Post by Mike Kazantsev
You don't have it disabled or overidden manually somewhere, by chance?
no

(>= emacs-major-version 26)
gives
t


(describe-variable 'emms-player-mpv-ipc-conn-emacs-26-workaround) shows

"emms-player-mpv-ipc-conn-emacs-26-workaround is a variable defined in ‘emms-player-mpv.el’.
Its value is nil

Documentation:
Non-nil to enable workaround for issue #31901 in emacs 26.0-26.1 and possibly later versions.
These seem to fail to call sentinel function for unix socket network processes
that were started with :nowait t, so blocking connections are used there instead.
:
Mike Kazantsev
2018-07-02 05:34:13 UTC
Permalink
On Sun, 01 Jul 2018 22:31:54 +0300
Post by Konstantin Reich
Mike,
Yeah i cannot figure out what it is going on.
Post by Mike Kazantsev
You don't have it disabled or overidden manually somewhere, by chance?
no
(>= emacs-major-version 26)
gives
t
Guess one other option is that something straight-up does:

(let ((emacs-major-version 25)) ... (require 'emms-player-mpv) ...)

...somewhere, maybe as a bad workaround for whatever weird quirk.

Sorry that it's already a lot of work for issue that you
probably don't particulary care about, but maybe you can edit that elpa
file at /home/reich/.emacs.d/elpa/emms-20180630.945/emms-player-mpv.el
and next to (defvar emms-player-mpv-ipc-conn-emacs-26-workaround ...)
line (e.g. right after it), put something like this:

(message "------ emms-mpv: emacs-major-version on load: %s" emacs-major-version)
(message "------ emms-mpv: workaround value init: %s" emms-player-mpv-ipc-conn-emacs-26-workaround)

And then restart emacs, make it load/init emms as you'd usually do, and
look into *Messages* afterwards for these two lines.

First one should show if maybe emacs-major-version is indeed overidden,
while second one might reveal whether variable is initialized to t and
then reset to nil or if latter happens on initialization there.


And if it's the latter case of something changing variable indeed
(probably is, given that it's defined in the right place and
emacs-major-version hack seems very unlikely), then edit that file
again and instead of these two "message" lines put this one there:

(debug-watch 'emms-player-mpv-ipc-conn-emacs-26-workaround)

This should land you in an emacs debugger with a backtrace should
anything ever try to change that variable (nothing in emms code should
afaik), so likely will signal such error upon next restart and emms init.

Found out about this new feature of emacs-26.1 myself googling for how
to trace variable changes just now.


Again, thanks and apologies for all the debugging work you've done on
this issue already.

Got comment on underlying emacs issue, confirming that it might be
accidental bug during refactoring, so might hopefully be fixed without
need for such workarounds in the next emacs version releases.
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e09c0972c350e9411683b509414fc598cbf387d3
--
Mike Kazantsev // fraggod.net
Konstantin Reich
2018-07-02 08:57:27 UTC
Permalink
I did what you suggested:


(defvar emms-player-mpv-ipc-conn-emacs-26-workaround (> emacs-major-version 26)
"Non-nil to enable workaround for issue #31901 in emacs 26.0-26.1 and possibly later versions.
These seem to fail to call sentinel function for unix socket network processes
that were started with :nowait t, so blocking connections are used there instead.")

(message "------ emms-mpv: emacs-major-version on load: %s" emacs-major-version)
(message "------ emms-mpv: workaround value init: %s" emms-player-mpv-ipc-conn-emacs-26-workaround)

I got the following in the Message buffer


------ emms-mpv: emacs-major-version on load: 26
------ emms-mpv: workaround value init: nil


Also, instead of these two lines i added (debug-watch 'emms-player-mpv-ipc-conn-emacs-26-workaround)
The debugger didnot appear, nothing is in the Message buffer.
Post by Mike Kazantsev
Got comment on underlying emacs issue, confirming that it might be
accidental bug during refactoring, so might hopefully be fixed without
need for such workarounds in the next emacs version releases.
Good.
Post by Mike Kazantsev
 Mike,
 Yeah i cannot figure out what it is going on.
 > You don't have it disabled or overidden manually somewhere, by chance?
 no
 (>= emacs-major-version 26)
 gives
 t
  (let ((emacs-major-version 25)) ... (require 'emms-player-mpv) ...)
...somewhere, maybe as a bad workaround for whatever weird quirk.
Sorry that it's already a lot of work for issue that you
probably don't particulary care about, but maybe you can edit that elpa
file at /home/reich/.emacs.d/elpa/emms-20180630.945/emms-player-mpv.el
and next to (defvar emms-player-mpv-ipc-conn-emacs-26-workaround ...)
  (message "------ emms-mpv: emacs-major-version on load: %s" emacs-major-version)
  (message "------ emms-mpv: workaround value init: %s" emms-player-mpv-ipc-conn-emacs-26-workaround)
And then restart emacs, make it load/init emms as you'd usually do, and
look into *Messages* afterwards for these two lines.
First one should show if maybe emacs-major-version is indeed overidden,
while second one might reveal whether variable is initialized to t and
then reset to nil or if latter happens on initialization there.
And if it's the latter case of something changing variable indeed
(probably is, given that it's defined in the right place and
emacs-major-version hack seems very unlikely), then edit that file
  (debug-watch 'emms-player-mpv-ipc-conn-emacs-26-workaround)
This should land you in an emacs debugger with a backtrace should
anything ever try to change that variable (nothing in emms code should
afaik), so likely will signal such error upon next restart and emms init.
Found out about this new feature of emacs-26.1 myself googling for how
to trace variable changes just now.
Again, thanks and apologies for all the debugging work you've done on
this issue already.
Got comment on underlying emacs issue, confirming that it might be
accidental bug during refactoring, so might hopefully be fixed without
need for such workarounds in the next emacs version releases.
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e09c0972c350e9411683b509414fc598cbf387d3
Mike Kazantsev
2018-07-02 10:04:52 UTC
Permalink
On Mon, 02 Jul 2018 11:57:27 +0300
Post by Konstantin Reich
(defvar emms-player-mpv-ipc-conn-emacs-26-workaround (> emacs-major-version 26)
Good that you've pasted this line.

Apparently pushed non-final version of that file into repository,
forgetting to sync it with local file after that one last change,
and instead of >= it has just > in the check there, my bad.
Couldn't spot that one-char difference earlier either.

Should be fixed now, thanks for sticking with the issue.
--
Mike Kazantsev // fraggod.net
Konstantin Reich
2018-07-02 11:03:42 UTC
Permalink
Yeah, it is ok now
Post by Mike Kazantsev
Apparently pushed non-final version of that file into repository,
forgetting to sync it with local file after that one last change,
and instead of >= it has just > in the check there, my bad.
Couldn't spot that one-char difference earlier either.
Should be fixed now, thanks for sticking with the issue.
Konstantin Reich
2018-07-01 19:33:58 UTC
Permalink
Also,
And if so, was is it defined/initialized in emms-player-mpv.el at the correct ELPA path or maybe somewhere else?
Yes, it is defined in the correct elpa path

(describe-variable 'emms-player-mpv-ipc-conn-emacs-26-workaround)
#("emms-player-mpv-ipc-conn-emacs-26-workaround is a variable defined in ‘emms-player-mpv.el’.
Its value is nil

Documentation:
Non-nil to enable workaround for issue #31901 in emacs 26.0-26.1 and possibly later versions.
These seem to fail to call sentinel function for unix socket network processes
that were started with :nowait t, so blocking connections are used there instead." 71 89 (button (t) category help-variable-def-button help-args (emms-player-mpv-ipc-conn-emacs-26-workaround "/home/reich/.emacs.d/elpa/emms-20180630.945/emms-player-mpv.el")))
Loading...