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"
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 versio
>
> It seems no one like to display the cover. Maybe enabling the option is a
> better choice.
Anyone can easily change `emms-player-mpv-parameters', so I think we are
already there.
They just need to remember to either define their own before
`define-emms-simple-player' creates it, or modify t
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?
On Fri, 13 Apr 2018 21:53:47 +0530
Pierre Neidhardt 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 p
On Fri, 13 Apr 2018 14:44:49 -0400
Yoni Rabkin 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
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 meth
On Sat, 14 Apr 2018 00:00:14 +0500
Mike Kazantsev wrote:
> On Fri, 13 Apr 2018 21:53:47 +0530
> Pierre Neidhardt 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
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 f
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 writes:
> Not sure on coding style strictness, tabs-spaces and such, bu
On Fri, 13 Apr 2018 15:23:05 -0400
Ian Dunn 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.
>
On Fri, 13 Apr 2018 15:31:23 -0400
Yoni Rabkin 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
Ian Dunn 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
13 matches
Mail list logo