Re: [emms-help] mpv player alternative with json-ipc

[Mike Kazantsev]

On Sat, 14 Apr 2018 00:48:43 +0500
Mike Kazantsev <address@hidden> wrote:

> On Fri, 13 Apr 2018 15:31:23 -0400
> Yoni Rabkin <address@hidden> 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