mpv player alternative with json-ipc

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

mpv player alternative with json-ipc

Mike Kazantsev-2
Hi,


Have been using recently-merged dochang/emms-player-mpv emms backend
for a while, but recently had an thought to get track durations from
mpv, as pre-scanning them otherwise from mostly-sshfs sources is quite
slow.

So implemented a different backend for mpv using its bidirectional
"JSON IPC" API with long-running mpv instances (kinda like mpd):

  https://github.com/mk-fg/emacs-setup/blob/master/extz/emms-player-mpv.el


Advantages of using mpv this way vs player-simple (that I can think of):

- Access to any properties, including track metadata, any file/stream
  info, video/audio output info, playlist info (if added as such).

  Can be used with e.g. long-running internet radio URLs to fetch
  currently playing track information, as parsed by mpv from icy tags.

- Precise event monitoring - e.g. only call emms-player-started when
  audio actually starts playing, taking any delay due to mpv startup,
  youtube-dl or file buffering (netwok sources) into account.

- Feedback from mpv on any command (success/error) and playback state
  (e.g. get playback position info).

- Maybe some minor performance gains due to mpv staying initialized in
  memory, instead of starting from scratch for every track.


Apparent disadvantages:

- More work emacs-side to handle events from JSON-IPC.
  For static files, it's usually just ~5-10 JSON lines per file.

- More complex implementation.


As I've also noticed that mpv backend was recently merged info emms,
wanted to present this one here as well, in case it might be for
whatever reason preferrable to player-simple mpv wrapping.

Not sure if it is the case, given more complex code, but also not sure
if maybe someone can think of other simple backend deficiencies which
this one can address nicely.


If it is worthy replacement for simple mpv backend for whatever reason
- let me know, can adjust code style to fit better with other .el
files in the repo, and get rid of dependencies like s.el/dash.el
(only used in couple of places).

Any other comments are also welcome, of course.


Cheers!


--
Mike Kazantsev // fraggod.net

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Pierre Neidhardt

Thanks for the hard work!

Before merging dochang/emms-player-mpv, we also considered
https://github.com/momomo5717/emms-player-simple-mpv which uses IPC as
well.

It turned out that there were many rough edges that needed polishing
before merging.  So instead we opted for dochang's simpler version for
now and we will adopt IPC features incrementally.

I haven't looked at your code, but isn't it duplicating momomo5717's
effort?

That said, it's no waste of effort and if you'd like to help merge the
IPC features, you are very welcome!

--
Pierre Neidhardt

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help

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

Re: mpv player alternative with json-ipc

Yoni Rabkin-2
In reply to this post by Mike Kazantsev-2

Thank you for the offer. Having the bi-directional communication would
be good. For the 5.0 release on the 1st of May we will keep the current
implementation since it Just Works (TM). After the release I have no
problem with adding API features galore.

Do you want to be the one working on this?

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

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Mike Kazantsev-2
In reply to this post by Pierre Neidhardt
On Fri, 13 Apr 2018 21:53:47 +0530
Pierre Neidhardt <[hidden email]> wrote:

> Thanks for the hard work!
>
> Before merging dochang/emms-player-mpv, we also considered
> https://github.com/momomo5717/emms-player-simple-mpv which uses IPC as
> well.
>
> It turned out that there were many rough edges that needed polishing
> before merging.  So instead we opted for dochang's simpler version for
> now and we will adopt IPC features incrementally.
>
> I haven't looked at your code, but isn't it duplicating momomo5717's
> effort?

Didn't know about that implementation, though not sure why I missed it
when looking for mpv wrappers earlier.

But yeah, it seem to be implementing same IPC thing, though in a bit
different style using transaction queues.

Code there seem to be ~3x in size, which I guess is mostly due to tq
boilerplate and confirmed command deliverly, while my code just fires
these same as with --input-file= fifo and assigns common
'(when err (message "emms-mpv-ipc-error: %s" (s-trim err))))'
handler to all of these, where user'd presumably just retry (when player
loads stream or whatever), same as with cli/osd inputs.

Oh well, guess if you need another idea for how thing can be wrapped,
there it is :)


> That said, it's no waste of effort and if you'd like to help merge the
> IPC features, you are very welcome!

Not sure if there's any gradual way to merge one implementation into
another, as with define-emms-simple-player you'd have simplier
process-per-track model, and replacing that with something like sending
commands to singleton "(emms-mpv-ipc)" (be it tq or async socket) pretty
much replaces the whole thing (which was rather simple to begin with).

Dunno about rough edges you've mentioned though - I'm kinda used to
writing code/protocols around async sockets (usually in python with
twisted/asyncio), so seemed to be rather simple protocol to me,
especially given how mpv can handle any commands at any time/state
without breaking, same as with --input-file= fire-and-forget fifo.

Will follow-up on that in a reply to Yoni's email, I guess.


Thanks for the feedback!
First time I've seen tq module used in the wild :)


--
Mike Kazantsev // fraggod.net

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Mike Kazantsev-2
In reply to this post by Yoni Rabkin-2
On Fri, 13 Apr 2018 14:44:49 -0400
Yoni Rabkin <[hidden email]> wrote:

> Thank you for the offer. Having the bi-directional communication would
> be good. For the 5.0 release on the 1st of May we will keep the current
> implementation since it Just Works (TM). After the release I have no
> problem with adding API features galore.
>
> Do you want to be the one working on this?

Yeah, pretty sure it shouldn't be beyond my humble abilities to maintain
that code, and definitely plan to do it for myself, as I use it every
day here.

Indeed it'd make sense to keep current implementation for at least one
release, and unless you've looked over the code, I'd think jury is
still out on whether it's actually any better than simple-player :)


Will mark the day to check for release and prepare/post a format-patch
here with most basic replacement for review, with follow-up patches for
basic metadata.

Not sure on coding style strictness, tabs-spaces and such, but all such
trivia should probably all be deferred until then.

Thanks!


--
Mike Kazantsev // fraggod.net

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Ian Dunn
In reply to this post by Pierre Neidhardt

    PN> I haven't looked at your code, but isn't it duplicating momomo5717's
    PN> effort?

A brief pass of Mike's code looks like he's using a persistent mpv instance (via the --idle flag), whereas momomo5717's version spawns and destroys a new one with each new track.  Mpv supports both methods, so I think a persistent instance would be the way to go.

--
Ian Dunn

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Mike Kazantsev-2
In reply to this post by Mike Kazantsev-2
On Sat, 14 Apr 2018 00:00:14 +0500
Mike Kazantsev <[hidden email]> wrote:

> On Fri, 13 Apr 2018 21:53:47 +0530
> Pierre Neidhardt <[hidden email]> wrote:
>
> > It turned out that there were many rough edges that needed polishing
> > before merging.  So instead we opted for dochang's simpler version for
> > now and we will adopt IPC features incrementally.

> Dunno about rough edges you've mentioned though ...

Skimming though ML archives, noticed (mostly-missing) conversation
about json-ipc which seem to mention mpv version issues wrt support for
that feature, which I haven't considered at all as it's the first time
I've used this API (more familiar with controlling mpv from lua),
and kinda-assumed it was there long enough, given how simple and
inadequate --input-file= is comparatively.

In which case guess maybe it makes even more sense to leave simple
implmenetation in for compatibility + simplicity reasons for a while,
as improvements that json-ipc provides don't seem to be huge.


--
Mike Kazantsev // fraggod.net

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Ian Dunn
In reply to this post by Mike Kazantsev-2

    MK> Hi,


    MK> Have been using recently-merged dochang/emms-player-mpv emms backend for
    MK> a while, but recently had an thought to get track durations from mpv, as
    MK> pre-scanning them otherwise from mostly-sshfs sources is quite slow.

    MK> So implemented a different backend for mpv using its bidirectional "JSON
    MK> IPC" API with long-running mpv instances (kinda like mpd):

    MK>   https://github.com/mk-fg/emacs-setup/blob/master/extz/emms-player-mpv.el


    MK> Advantages of using mpv this way vs player-simple (that I can think of):

    This looks great!  Couple of comments after a brief look at it:

1a. You should require s and dash in the header, as they both appear to be dependencies.  I can't immediately see any others.

1b. Neither is currently a dependency of EMMS, so either they'd have to be added, or removed from your code.

2. In "emms-mpv-ipc-line", give the option for users to introduce their own event handlers.  This makes it easier to extend to support additional events.

3. As stated in another email, you use the --idle flag, which seems to exist for this very purpose.  Thanks for that.

4. A general convention when dealing with external processes in emacs is to break up command line args and the actual program.  It especially helps when users want to use a specific binary.  Otherwise, I'd have to modify just the first argument of a list if I wanted to modify it at all in a robust way.

5. Adding to 4, I'd recommend making emms-mpv-proc-cmd a defcustom instead of a defvar.

--
Ian Dunn

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Yoni Rabkin-2
In reply to this post by Mike Kazantsev-2

I have version 0.3.4 of mpv on my machine (Trisquel) so this code
wouldn't work on my box. I think one needs (<= 0.17.0 mpv-version). We'd
need a way not to break mpv for people who start enjoying it in 5.0.


Mike Kazantsev <[hidden email]> writes:

> Not sure on coding style strictness, tabs-spaces and such, but all such
> trivia should probably all be deferred until then.

Emms is old (the Savannah project was registered 15 years ago), so code
style is all over the place. As maintainer I try for three things:

    * HEAD should be pretty stable before a release, but otherwise it
      can be as bleeding edge as we want.

    * It should compile without warnings.

    * Documentation is good, and should be updated.


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

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Mike Kazantsev-2
In reply to this post by Ian Dunn
On Fri, 13 Apr 2018 15:23:05 -0400
Ian Dunn <[hidden email]> wrote:

> 1a. You should require s and dash in the header, as they both appear to be dependencies.  I can't immediately see any others.
> 1b. Neither is currently a dependency of EMMS, so either they'd have to be added, or removed from your code.
>
> 2. In "emms-mpv-ipc-line", give the option for users to introduce their own event handlers.  This makes it easier to extend to support additional events.
>
> 3. As stated in another email, you use the --idle flag, which seems to exist for this very purpose.  Thanks for that.
>
> 4. A general convention when dealing with external processes in emacs is to break up command line args and the actual program.  It especially helps when users want to use a specific binary.  Otherwise, I'd have to modify just the first argument of a list if I wanted to modify it at all in a robust way.
>
> 5. Adding to 4, I'd recommend making emms-mpv-proc-cmd a defcustom instead of a defvar.

Completely agree.

Definitely need to make quite a few defvar's there into defcustom's,
including separate binary/args.

s/dash deps (pretty sure I use cl-return and let* too) are only
omitted because it's in the repo where I use them all over the place,
and would be better to drop them entirely for emms code to avoid new
requires there.

Will be sure to address all these, thanks a lot for pointing them out!


--
Mike Kazantsev // fraggod.net

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Mike Kazantsev-2
In reply to this post by Yoni Rabkin-2
On Fri, 13 Apr 2018 15:31:23 -0400
Yoni Rabkin <[hidden email]> wrote:

> I have version 0.3.4 of mpv on my machine (Trisquel) so this code
> wouldn't work on my box. I think one needs (<= 0.17.0 mpv-version). We'd
> need a way not to break mpv for people who start enjoying it in 5.0.

Right.

Guess I'll look for a way to separate simple/json-ipc versions cleanly
and load one or the other depending on mpv version.


> Emms is old (the Savannah project was registered 15 years ago), so code
> style is all over the place. As maintainer I try for three things:

All noted, thanks.


--
Mike Kazantsev // fraggod.net

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Pierre Neidhardt
In reply to this post by Ian Dunn

Ian Dunn <[hidden email]> writes:

> A brief pass of Mike's code looks like he's using a persistent mpv
> instance (via the --idle flag), whereas momomo5717's version spawns
> and destroys a new one with each new track.  Mpv supports both
> methods, so I think a persistent instance would be the way to go.

Sounds reasonable.

--
Pierre Neidhardt

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help

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

Re: mpv player alternative with json-ipc

Mike Kazantsev-2
In reply to this post by Mike Kazantsev-2
On Sat, 14 Apr 2018 00:48:43 +0500
Mike Kazantsev <[hidden email]> wrote:

> On Fri, 13 Apr 2018 15:31:23 -0400
> Yoni Rabkin <[hidden email]> wrote:
>
> > I have version 0.3.4 of mpv on my machine (Trisquel) so this code
> > wouldn't work on my box. I think one needs (<= 0.17.0 mpv-version). We'd
> > need a way not to break mpv for people who start enjoying it in 5.0.  
>
> Right.
>
> Guess I'll look for a way to separate simple/json-ipc versions cleanly
> and load one or the other depending on mpv version.

Pushed new backend option now to mpv-json-ipc branch, with support for
both older mpv versions with one-pid-per-track + --input-file operation
and newer versions running as "mpv --idle".

Tried to address all the feedback and suggestions
(thanks again, let me know if I missed any).

Guess I'll leave it there until next release, and maybe ping about way
ahead for it afterwads, fixing any issues that might pop-up there in the
meantime.

Any extra testing and/or feedback is always appreciated.


Few notes about this implementation and new operation mode:


 - JSON IPC was initially introduced in mpv 0.7.0, but with different
   option (--input-unix-socket), which code tries to detect and use
   based on "mpv --version" output (in emms-mpv-ipc-detect).


 - For mpv version earlier than 0.7.0, same oneshot operation and
   --input-file fifo are used, which are supported in any mpv.

   emms-player-mpv-ipc-method allows user to force specific mode,
   if necessary, skipping --version output check.


 - Tested this with only mpv-0.27.2 (Arch Linux) here, and didn't look
   through JSON IPC history, but unless basic request-response flow of
   it has changed, it should be compatible - currently-used commands
   there date back to mplayer (same as sent over --input-file), and any
   failed metadata subscriptions are non-fatal.


 - All customization parameters have same names, values and should be
   fully compatible with currently merged implementation.

   Extra argv stuff like --idle, --input-* and file/playlist paths
   are added dynamically, depending on emms-player-mpv-ipc-method
   and should not require any additional customization.


 - Only code requirements are 'emms and 'json (in emacs since 2008)
   afaik, not even 'cl stuff, as let* seem to be in core emacs now,
   and can't find anything else cl in there.


 - emms-mpv-event-functions, emms-mpv-event-connect-hook and
   emms-mpv-ipc-req-send should allow to easily extend interactions with
   mpv by subscribing to more events/changes/logging, listening to
   these, and sending control commands at any time, with only knowledge
   of mpv API needed.


 - Testing oneshot vs long-running mode, easy to see that gaps
   when switching tracks are much smaller that way, at least on this
   machine.

   Not unexpected, but kinda nice, and maybe opens the path to
   an easy gapless playback option with crossfade, if mpv supports it.


 - long-running mode allows to keep nice persistent audio visualization
   window around (which lavfi-complex options allow to render), with osd
   for lyrics, subs or track metadata and whatever else.

   Didn't think about this bonus use-case for such mode initially at all.


 - Obvious way ahead feature-wise would be to add processing for
   dynamic metadata that online streams (think soma.fm) provide in icy
   tags, and maybe optional support for updating metadata for static
   tracks (beyond just duration, which is the only one currently handled)
   as they get played.

   Also maybe request/sync playback position info via repeating timer.

   Despite using emms pretty much every day since 2009, afraid I haven't
   looked at most of its features beyond simple playlists, so might be
   missing some really useful low-hanging fruit here.


Cheers!


--
Mike Kazantsev // fraggod.net

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Pierre Neidhardt

Wow, great work!  I'll keep running your branch for now and report if I
run into any issue.

Thanks again!

--
Pierre Neidhardt

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help

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

Re: mpv player alternative with json-ipc

Pierre Neidhardt

Well, did not take long! :p

- When I first started playing, I could not hear anything.  I had to
pause/unpause so that mpv would start make sounds.

- Seeking forward / backward resets the timer (but the seeking works).

--
Pierre Neidhardt

Paul Revere was a tattle-tale.

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help

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

Re: mpv player alternative with json-ipc

Mike Kazantsev-2
On Mon, 16 Apr 2018 11:11:41 +0530
Pierre Neidhardt <[hidden email]> wrote:

> Well, did not take long! :p

Oh well, not entirely unexpected :)


> - When I first started playing, I could not hear anything.  I had to
> pause/unpause so that mpv would start make sounds.

Suspect this one is due to mpv configuration (which maybe needs to
be reset on first connection) or different behavior of --idle in
previous versions.

Can you do:

  (require 'emms-player-mpv)
  (add-to-list 'emms-player-list 'emms-player-mpv)
  (setq emms-mpv-debug t)
  (emms-player-mpv-start (emms-playlist-current-selected-track))

Then send whatever ends up in *Messages* when running these?

"loadfile" seem to be "Load the given file and play it." so works fine
for starting playback here, gotta check it for previous versions, in
case it might be the cause for the issue, though log can probably clear
this out faster.


> - Seeking forward / backward resets the timer (but the seeking works).

Wasn't the case before, but can definitely see this happening in
current version, missed it during testing.

Should be easy to fix though.


Thanks!


--
Mike Kazantsev // fraggod.net

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Mike Kazantsev-2
On Mon, 16 Apr 2018 12:03:26 +0500
Mike Kazantsev <[hidden email]> wrote:

> On Mon, 16 Apr 2018 11:11:41 +0530
> Pierre Neidhardt <[hidden email]> wrote:
>
> > Well, did not take long! :p  

> > - Seeking forward / backward resets the timer (but the seeking works).  

Was due to issuing emms-player-started on every playback-restart, fixed here:
https://git.savannah.gnu.org/cgit/emms.git/commit/?h=mpv-json-ipc&id=e04cbaa1


> > - When I first started playing, I could not hear anything.  I had to
> > pause/unpause so that mpv would start make sounds.  

Found that this can also happen if both these are true:

 - Track is an url.
 - It's not the only track in the emms playlist.

Due to the same emms-player-started change, should be fixed by the same
commit as above.
Might fix issue in your case too, if cause is the same.

If still happens, would help greatly if you can post the log or maybe
more details on specific sequence of actions and tracks involved
(so that I can try to reproduce it here).


--
Mike Kazantsev // fraggod.net

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Pierre Neidhardt
In reply to this post by Mike Kazantsev-2

Mike Kazantsev <[hidden email]> writes:

> Can you do:
>
>   (require 'emms-player-mpv)
>   (add-to-list 'emms-player-list 'emms-player-mpv)
>   (setq emms-mpv-debug t)
>   (emms-player-mpv-start (emms-playlist-current-selected-track))

From which state do you expect this?  Anyways, here is a message when I
ran the last command from the playlist buffer with multiple tracks and
one track was playing.

--8<---------------cut here---------------start------------->8---
emms-mpv-ipc-json >> {"command":["loadfile","/home/ambrevar/music/Juno Reactor/2012 - From the Land of the Rising Sun - Inside the Reactor II/Juno Reactor - 02 - Tokyo Dub - Tri-Force Remix.ogg","replace"],"request_id":31}
(lambda (data err) (if (eq err (quote connection-error)) (progn (emms-player-mpv-cmd cmd))))
emms-mpv-ipc-json << {"data":null,"request_id":31,"error":"success"}
emms-mpv-ipc-json << {"event":"audio-reconfig"}
emms-mpv-ipc-json << {"event":"tracks-changed"}
emms-mpv-ipc-json << {"event":"end-file"}
emms-mpv-ipc-json << {"event":"start-file"}
emms-mpv-ipc-json << {"event":"property-change","id":1,"name":"duration","data":null}
emms-mpv-ipc-json << {"event":"tracks-changed"}
emms-mpv-ipc-json << {"event":"metadata-update"}
emms-mpv-ipc-json << {"event":"audio-reconfig"}
emms-mpv-ipc-json << {"event":"file-loaded"}
emms-mpv-ipc-json << {"event":"seek"}
emms-mpv-ipc-json << {"event":"property-change","id":1,"name":"duration","data":454.961633}
emms-mpv-ipc-json << {"event":"audio-reconfig"} [2 times]
emms-mpv-ipc-json << {"event":"playback-restart"}
--8<---------------cut here---------------end--------------->8---

I noticed the issue happens when going to the next track.  I'm not
sure it exactly when it happens, but it happens very frequently, so I'm
quite puzzle that you did not experience it.

>> - Seeking forward / backward resets the timer (but the seeking works).

Last commit fixed it.

--
Pierre Neidhardt

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help

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

Re: mpv player alternative with json-ipc

Mike Kazantsev-2
On Tue, 17 Apr 2018 17:24:38 +0530
Pierre Neidhardt <[hidden email]> wrote:

> From which state do you expect this?

I thought you'd run it from scratch, with all the requires and init
stuff in there, so that everything that mpv instance does will be
captured, assuming that issue happens there, of course.

But any log is fine, really :)


> Anyways, here is a message when I
> ran the last command from the playlist buffer with multiple tracks and
> one track was playing.
...
> I noticed the issue happens when going to the next track.  I'm not
> sure it exactly when it happens, but it happens very frequently, so I'm
> quite puzzle that you did not experience it.

Logs for mpv my configuration are identical, except for one thing -
'{"event":"seek"}' in there right before playback is supposed to start
("file-loaded -> audio-reconfig x2 -> duration -> playback-restart"
in my case).
But that shouldn't really affect anything, guess maybe it's maybe some
kind of "skip initial silence" script/filter that you might have there.


I wonder if maybe I'm misunderstanding the situation though.

Are steps to reproduce the issue same as following:

- Start any kind of mpv playback, it starts normally.
- Pause currently-playing track via e.g. emms-player-mpv-pause.
- Run emms-next.
- Playlist is switched to next track, but playback is still paused.

With expected result: next track starts playing after (emms-next).
Vs actual result: playback is still paused after (emms-next).

This is the issue that you meant, right?

And e.g. test-case proposed in my previous mail doesn't demonstrate the
issue as there's no pausing involved there?


I think this situation is indeed a bug, as guess emms-next should
also unpause the track, or at least not reset emms-player-paused-p if
it doesn't - will fix in a moment, haven't considered what should
happen on pause+switch like that.


--
Mike Kazantsev // fraggod.net

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
Reply | Threaded
Open this post in threaded view
|

Re: mpv player alternative with json-ipc

Mike Kazantsev-2
On Tue, 17 Apr 2018 20:26:49 +0500
Mike Kazantsev <[hidden email]> wrote:

> I think this situation is indeed a bug, as guess emms-next should
> also unpause the track, or at least not reset emms-player-paused-p if
> it doesn't - will fix in a moment, haven't considered what should
> happen on pause+switch like that.

Fixed in last commit by always removing paused state in
emms-player-start, which seem to make perfect sense there.


--
Mike Kazantsev // fraggod.net

_______________________________________________
Emms-help mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/emms-help
123