Re: No sound if emms-play-dired is run while another track is paused

[Mike Kazantsev]

On Sat, 19 Jun 2021 06:19:16 +0500
Mike Kazantsev <mk.fraggod@gmail.com> wrote:

> On Fri, 18 Jun 2021 16:00:28 -0400
> Greg Farough <gregf@gnu.org> wrote:
> 
> > On Fri, Jun 18 2021, Yoni Rabkin <yoni@rabkins.net> wrote:
> > 
> > > Now I'm having an issue where occasionally I'll need to select a track
> > > twice in order for it to play, especially after a while of not playing
> > > anything. I reverted to d4d9171ce and isn't happening there.
> > >
> > > I haven't looked into it yet.
> > >
> > > Anyone else experiencing this?  
> > 
> > Actually, yes. Once again I thought it was a quirk of my system, but
> > the same thing has been happening to me on 7.4.


> One thing there that I've just noticed is that
> 02915f7aa24d27d717ff4821a58f791cffcc174c seem to have produced this code:
> 
>   (start-func (lambda ()
>     (emms-player-mpv-cmd start-cmd
>       (apply-partially #'emms-player-mpv-start-error-handler ',start-cmd))
>     ...
> 
> Where previously lambda was in quasiquotes, ',start-cmd made sense,
> but now I think it's broken, and if initial start-cmd fails for some reason,
> that "restart stuff and try again" fallback won't be invoked correctly.

Looks like it works either way, but fixed it anyway in 1ce322a,
and while testing how it works, found a way to reproduce issue like one
mentioned above - see below.


> if initial "loadfile" fails (requiring that fallback),
> something else is working weirdly - shouldn't normally happen anyway.

This might actually be what is happening for you, but not sure why,
even though symptoms seem to match:

 - Playback is stopped, as in emms-stop.

 - At some later point mpv process dies or exits.
   I've used this command to reproduce it: pkill -ef -- 'mpv --quiet'

 - emms-player-mpv-start is called (by emms) to start playback again.

   - It runs e.g. (emms-player-mpv-cmd (loadfile somefile.mp3 replace))
   - Then it runs (emms-player-mpv-cmd (set pause no))
   - Sending both commands to mpv fails (ipc closed/nil), as it is dead.
   - After mpv is auto-restarted, last command gets re-sent to it,
     which now happens to be (set pause no), and notably not "loadfile".
   - As new mpv process wasn't given any track to play, it keeps idling.

So issue was indeed adding that (set pause no) command.

(spotted by enabling emms-player-mpv-debug for checking how that
',start-cmd works - mpv was restarted, but only sent "set pause no"
command, which looks rather odd with no actual prior "start-cmd")

Should be fixed by b31db42, which added special
'(batch (cmd1 . handler1) ...) syntax to queue multiple commands,
hopefully simplifying both sending batches of these and
emms-player-mpv-start, as now it doesn't need complicated
emms-player-mpv-start-error-handler that re-sends same two commands,
just one check for whether there was socket error and re-sends same batch.

Please test, as I didn't think last tiny fix can break things either,
but forgot about how (setq emms-player-mpv-ipc-connect-command cmd) works
if mpv process is not around atm.
It was fine and simple with one "loadfile" command, but if a batch of
these is needed to start playback, obviously not good enough.


And I don't know if this is actually the issue that you have - if it
is, I'd recommend also checking why mpv process exits in your case.

Could be that it dies when audio daemon like pulseaudio exits due to
being idle for too long, but maybe it's something stranger, like mpv
crashing randomly when idle, which you might want to know about.

One good way to check might be adding something like:

  --log-file=/tmp/emms-mpv.log --msg-level=all=debug

...to emms-player-mpv-parameters or mpv config (btw, modern mpv has
--profile feature to pre-configure it for diff purposes in config file easily).


Also added 144c49a with a fix for earlier comment revisions, as I think
patch there confused emacs "network process" term (as in make-network-process)
with linux/os processes.


Cheers!


-- 
Mike Kazantsev // fraggod.net