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

[Mike Kazantsev]

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.


Don't think I've noticed that, but my use is very simple, I rarely
switch tracks manually, and mostly play stuff from relatively slow sshfs.

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.

My local version has diverged a bit due to these patches, so if this is
the cause of the issue, it'd make sense that I won't have it.
Don't think it should be the problem here though, as it seem to be from
before 7.3 and if initial "loadfile" fails (requiring that fallback),
something else is working weirdly - shouldn't normally happen anyway.

Can recommend enabling debug logging via (setq emms-player-mpv-debug t)
to see what's going on via *Messages* buffer, if possible to reproduce
without too much annoyance from stuff flashing in minibuffer.


-- 
Mike Kazantsev // fraggod.net