Closed mihaiolteanu closed 4 years ago
I have the almost the same problem every time when I play a track when one is already playing. If I do vuiet-stop in between then no errors happened.
mpv-start: make client process failed: No such file or directory, :name, mpv-socket, :family, local, :service, /tmp/mpv-o7eCEI
Yes, that's the exact same problem.
And yes, vuiet-stop
is called in between, as can be seen here https://github.com/mihaiolteanu/vuiet/blob/master/vuiet.el#L547
But the mpv package calls are not synchronous. So when a new mpv instance is created, I think the old one might happen to be still running and then there is some kind of a mix-up.
If I also put a (sleep-for 1)
after the (vuiet-stop)
call from above, I don't get this error anymore. But that seems like a big hack and Emacs just freezes for a seconds which is not so nice.
So I'm still looking for a solution to this. Hopefully the mpv package owner knows better.
Anyway, thanks for your input. I really appreciate it.
I can see this hack in mpv too:
(while (and (live-p) (not (file-exists-p socket)))
(sleep-for 0.05))
So if you'll place smth like in the place you've mentioned:
(defun vuiet--play-generator (generator)
"Play one track from the GENERATOR.
Set mvp up so that after quiting (track finishes), the next item
from the generator is played."
(while (mpv-live-p)
(vuiet-stop) ;Cleanup
(sleep-for 0.1))
(vuiet--play-track (vuiet--next-track generator))
(setf mpv-on-exit-hook
(lambda (&rest event)
;; A kill event (mpv closes) is "registered" as nil.
(unless event
(awhen (vuiet--next-track generator)
(vuiet--play-track it)))))
t)
That would make a bit more flexible, at least I don't observe a tangible delay.
Yes, there is a hack in mpv also. I've tried all kind of variants in that while loop. Something always breaks :)
I'm currently working on something which will fix this, indirectly, by not closing the mpv when changing the playlist. Will see how that works.
I also noticed that when I do play similar after first track ends I get
error in process sentinel: let: Symbol’s value as variable is void: generator
error in process sentinel: Symbol’s value as variable is void: generator
Looks like this is happening inside
(setf mpv-on-exit-hook
(lambda (&rest event)
;; A kill event (mpv closes) is "registered" as nil.
(unless event
(awhen (vuiet--next-track generator)
(vuiet--play-track it)))))
t)
Looks like this generator error is happening when I use that timer. Something I am not really aware of. Anyway, looking forward for your proper fix.
I've replaced that piece of code entirely. I've modified vuiet to not close the mpv player between tracks and when changing the playlists. This adds the benefit of lower load times and a nicer user experience, but also gets rid of that pain point and, hopefully, of these kind of errors in the future.
If you try it, let me know how it works, or if you find other issues.
Thanks!
Nice, thanks a lot, looks like I don't see these types of errors.
Sometimes I get an error like this
if I'm trying to play something else while something is currently playing.
From what I was able to debug, this has to do with the way the mpv.el library is starting up the mpv process. I've opened an mpv.el issue: https://github.com/kljohann/mpv.el/issues/4.
Let me know if you have the same problem or any ideas on how to solve it.