Auto-forward bug with mpv backend

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Auto-forward bug with mpv backend

Pierre Neidhardt-2
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?

--
Pierre Neidhardt
https://ambrevar.xyz/

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Auto-forward bug with mpv backend

Yoni Rabkin-2
Pierre Neidhardt <[hidden email]> writes:

> 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?

Can't reproduce with mpv 0.29 here. I'll try to grab 0.30 and see.

--
   "Cut your own wood and it will warm you twice"

Reply | Threaded
Open this post in threaded view
|

Re: Auto-forward bug with mpv backend

Mike Kazantsev-2
On Thu, 05 Dec 2019 14:35:54 -0500
Yoni Rabkin <[hidden email]> wrote:

> Pierre Neidhardt <[hidden email]> writes:
>
> > 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?  
>
> Can't reproduce with mpv 0.29 here. I'll try to grab 0.30 and see.

Definitely related to mpv-0.30, as I just updated it here from 0.29.1 to
test and was able to immediately reproduce it.


--
Mike Kazantsev // fraggod.net

Reply | Threaded
Open this post in threaded view
|

Re: Auto-forward bug with mpv backend

Yoni Rabkin-2
Mike Kazantsev <[hidden email]> writes:

> On Thu, 05 Dec 2019 14:35:54 -0500
> Yoni Rabkin <[hidden email]> wrote:
>
>> Pierre Neidhardt <[hidden email]> writes:
>>
>> > 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?  
>>
>> Can't reproduce with mpv 0.29 here. I'll try to grab 0.30 and see.
>
> Definitely related to mpv-0.30, as I just updated it here from 0.29.1 to
> test and was able to immediately reproduce it.

Thank you; that's very useful information. I still don't have 0.30 to
test with at the moment, but at least we know where to look.

--
   "Cut your own wood and it will warm you twice"

Reply | Threaded
Open this post in threaded view
|

Re: Auto-forward bug with mpv backend

Mike Kazantsev-2
In reply to this post by Pierre Neidhardt-2
On Thu, 05 Dec 2019 12:25:43 +0100
Pierre Neidhardt <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Auto-forward bug with mpv backend

Mike Kazantsev-2
On Fri, 6 Dec 2019 01:08:41 +0500
Mike Kazantsev <[hidden email]> wrote:

> On Thu, 05 Dec 2019 12:25:43 +0100
> Pierre Neidhardt <[hidden email]> wrote:
>
> > Since recently (1-2 months), I experience a strange issue with Emms
> > using the MPV backend.  I can reproduce on a vanilla setup:
...
> >
> > Result:
> > Instead of playing the first track, it pause for <1s and automatically
> > start playing the following track.
>
> 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.

Fixed in git master (eedd61d).

Should be compatible with any older mpv versions, as all fix does is
introducing aforementioned (non-blocking) delay between stop/start commands.

Simpliest workaround in earlier emms-player-mpv.el versions with new
mpv-0.30 is to set emms-player-mpv-ipc-method to 'file (which will also
disable some newer ipc features however).

Other than that, anything that'd run something like "emms-stop, wait 0.1s"
before switching to selected track will also work, but probably more
hassle than replacing emms-player-mpv.el with the one from git.

Thanks for reporting!
Probably should update my machine more often too :)


--
Mike Kazantsev // fraggod.net

Reply | Threaded
Open this post in threaded view
|

Re: Auto-forward bug with mpv backend

Yoni Rabkin-2
Mike Kazantsev <[hidden email]> writes:

> On Fri, 6 Dec 2019 01:08:41 +0500
> Mike Kazantsev <[hidden email]> wrote:
>
>> On Thu, 05 Dec 2019 12:25:43 +0100
>> Pierre Neidhardt <[hidden email]> wrote:
>>
>> > Since recently (1-2 months), I experience a strange issue with Emms
>> > using the MPV backend.  I can reproduce on a vanilla setup:
> ...
>> >
>> > Result:
>> > Instead of playing the first track, it pause for <1s and automatically
>> > start playing the following track.
>>
>> 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.
>
> Fixed in git master (eedd61d).
>
> Should be compatible with any older mpv versions, as all fix does is
> introducing aforementioned (non-blocking) delay between stop/start commands.
>
> Simpliest workaround in earlier emms-player-mpv.el versions with new
> mpv-0.30 is to set emms-player-mpv-ipc-method to 'file (which will also
> disable some newer ipc features however).
>
> Other than that, anything that'd run something like "emms-stop, wait 0.1s"
> before switching to selected track will also work, but probably more
> hassle than replacing emms-player-mpv.el with the one from git.
>
> Thanks for reporting!
> Probably should update my machine more often too :)

Thank you. Checked to work with an ancient mpv version 0.3.4, as well as
with mpv 0.29.

--
   "Cut your own wood and it will warm you twice"

Reply | Threaded
Open this post in threaded view
|

Re: Auto-forward bug with mpv backend

Pierre Neidhardt-2
Thanks for the prompt fix!

I can confirm that

(setq emms-player-mpv-ipc-method 'file)

works on 0.30, while waiting for Emms 5.4.

To help with testing of multiple (and recent) MPV versions, you could
give Guix a try (https://guix.gnu.org): it allows you to build multiple
non-conflicting versions of mpv which won't interfere with your system package.

Cheers!

--
Pierre Neidhardt
https://ambrevar.xyz/

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Auto-forward bug with mpv backend

Mike Kazantsev-2
On Fri, 06 Dec 2019 10:08:00 +0100
Pierre Neidhardt <[hidden email]> wrote:

> Thanks for the prompt fix!
>
> I can confirm that
>
> (setq emms-player-mpv-ipc-method 'file)
>
> works on 0.30, while waiting for Emms 5.4.

I did also file a report with mpv devs:
https://github.com/mpv-player/mpv/issues/7225

And I think it was confirmed to be a regression.

So guess other workaround can be updating mpv, if it'll get addressed
in the next version, as I imagine it should work same as 0.29 before it.


> To help with testing of multiple (and recent) MPV versions, you could
> give Guix a try (https://guix.gnu.org): it allows you to build multiple
> non-conflicting versions of mpv which won't interfere with your system package.

Yeah, wanted to try it sometime.

Though given amount of various hacks I have here, seems hard to justify
any kind of switch :)


--
Mike Kazantsev // fraggod.net

Reply | Threaded
Open this post in threaded view
|

Re: Auto-forward bug with mpv backend

Pierre Neidhardt-2
Mike Kazantsev <[hidden email]> writes:

> Yeah, wanted to try it sometime.
>
> Though given amount of various hacks I have here, seems hard to justify
> any kind of switch :)

What kind of hacks? :)

You can install Guix on top of your current distribution, it won't
interfere with anything.

Cheers!

--
Pierre Neidhardt
https://ambrevar.xyz/

signature.asc (497 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Auto-forward bug with mpv backend

Mike Kazantsev-2
On Fri, 06 Dec 2019 14:56:25 +0100
Pierre Neidhardt <[hidden email]> wrote:

> Mike Kazantsev <[hidden email]> writes:
>
> > Yeah, wanted to try it sometime.
> >
> > Though given amount of various hacks I have here, seems hard to justify
> > any kind of switch :)  
>
> What kind of hacks? :)

The usual hundreds of often distro/system/DE-specific scripts, aliases,
wrappers, custom-built packages, configurations, etc.


> You can install Guix on top of your current distribution, it won't
> interfere with anything.

Ah, fair enough, didn't realize that, thanks for the info.

Of course it's technically possible to install any distro on top (esp.
in an nspawn container or such), but looks like guix has that option by
design, and is easier to integrate into existing env, kinda like flatpak.


--
Mike Kazantsev // fraggod.net

Reply | Threaded
Open this post in threaded view
|

Re: Auto-forward bug with mpv backend

Mike Kazantsev-2
In reply to this post by Mike Kazantsev-2
On Fri, 6 Dec 2019 16:33:44 +0500
Mike Kazantsev <[hidden email]> wrote:

> On Fri, 06 Dec 2019 10:08:00 +0100
> Pierre Neidhardt <[hidden email]> wrote:
>
> > Thanks for the prompt fix!
> >
> > I can confirm that
> >
> > (setq emms-player-mpv-ipc-method 'file)
> >
> > works on 0.30, while waiting for Emms 5.4.  
>
> I did also file a report with mpv devs:
> https://github.com/mpv-player/mpv/issues/7225
>
> And I think it was confirmed to be a regression.
>
> So guess other workaround can be updating mpv, if it'll get addressed
> in the next version, as I imagine it should work same as 0.29 before it.

Was fixed in mpv master just now, so guess 0.30.1 should work like 0.29.
https://github.com/mpv-player/mpv/commit/b0c9f582


--
Mike Kazantsev // fraggod.net

Reply | Threaded
Open this post in threaded view
|

Re: Auto-forward bug with mpv backend

Pierre Neidhardt-2
In reply to this post by Mike Kazantsev-2
Mike Kazantsev <[hidden email]> writes:

> The usual hundreds of often distro/system/DE-specific scripts, aliases,
> wrappers, custom-built packages, configurations, etc.

What I found in my experience is that Guix helped reducing many of the
crufts I had, simply by providing more programmability and
composability, which can be upstreamed and served to all Guix users.

> Ah, fair enough, didn't realize that, thanks for the info.
>
> Of course it's technically possible to install any distro on top (esp.
> in an nspawn container or such), but looks like guix has that option by
> design, and is easier to integrate into existing env, kinda like flatpak.

I don't know about flatpak, but you can install Guix on your regular
/root partition, all it takes are 2 folders (/gnu/store + /var/guix) and
some guixbuilder users.  It remains a first-class piece of software.

--
Pierre Neidhardt
https://ambrevar.xyz/

signature.asc (497 bytes) Download Attachment