On Sat, 14 Apr 2018 00:48:43 +0500 Mike Kazantsev <mk.frag...@gmail.com> wrote:
> On Fri, 13 Apr 2018 15:31:23 -0400 > Yoni Rabkin <y...@rabkins.net> 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 Emms-help@gnu.org https://lists.gnu.org/mailman/listinfo/emms-help