Re: Auto-forward bug with mpv backend

[Mike Kazantsev]

On Thu, 05 Dec 2019 12:25:43 +0100
Pierre Neidhardt <address@hidden> wrote:

> Since recently (1-2 months), I experience a strange issue with Emms
> using the MPV backend.  I can reproduce on a vanilla setup:
> 
> - Emacs 26.3
> - Emms 5.3
> - mpv 0.30
> 
> Recipe:
> 
> - Add 2 tracks or more to your playlist.
> - Start playing any track.
> - Press RET (emms-playlist-mode-play-smart) on the first track.
> 
> Result:
> Instead of playing the first track, it pause for <1s and automatically
> start playing the following track.
> 
> This issue does not occur if not track is currently playing (i.e. after
> calling emms-stop).
> 
> Any clue what's going on?

Looks like a change in how mpv-0.30 handles sequence of commands.

Will probably fix it by delaying "loadfile" command until playback is
stopped by earlier stop, if any.


Gory details:

This is what seem to be happening, which you can check in *Messages*
after (setq emms-player-mpv-debug t):

  emms-player-mpv 0.0 json >> {"command":["stop"],"request_id":20}
  emms-player-mpv 0.0 json >> 
{"command":["loadfile","track1.mp3","replace"],"request_id":21}
  emms-player-mpv 0.0 json << {"data":null,"request_id":20,"error":"success"}
  emms-player-mpv 0.0 json << {"data":null,"request_id":21,"error":"success"}
  emms-player-mpv 0.0 json >> {"command":["set","pause","no"],"request_id":22}
  emms-player-mpv 0.0 json << {"event":"audio-reconfig"}
  emms-player-mpv 0.0 json << {"data":null,"request_id":22,"error":"success"}
  emms-player-mpv 0.0 json << {"event":"tracks-changed"}
  emms-player-mpv 0.0 json << {"event":"end-file"}
  emms-player-mpv 0.0 json << {"event":"audio-reconfig"}
  emms-player-mpv 0.0 json << {"event":"idle"}
  emms-player-mpv 0.0 json << 
{"event":"property-change","id":1,"name":"metadata","data":null}
  emms-player-mpv 0.5 idle-check (stopped=nil)
  emms-player-mpv 0.5 json >> 
{"command":["loadfile","track2.mp3","replace"],"request_id":23}

I.e. mpv gets same "stop" + "loadfile" sequence of commands,
immediately following one another, but if earlier it ended up producing
expected "loadfile" result, now it seem to do "stop".

After that emms-player-mpv-event-idle check kicks with 0.5s delay
(emms-player-mpv-idle-delay) to advance the track.
(this check is a kind of catch-all fallback for any kind of unexpected
"playback stopped when emms didn't instruct it to" situations, like i/o
errors and such)

Don't think I've seen such async semantics documented anywhere in mpv,
so it's probably not a bug, and given that it all happens within milliseconds,
avoiding relying on them (i.e. by delaying loadfile until playback stops)
seem to be most foolproof solution.


-- 
Mike Kazantsev // fraggod.net