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
So implemented a different backend for mpv using its bidirectional
"JSON IPC" API with long-running mpv instances (kinda like mpd):
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.
- 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.
Mike Kazantsev // fraggod.net
Emms-help mailing list