[emms-help] Playback / cache issue with mpv backend

[Pierre Neidhardt]

I've recently switched to [[https://www.gnu.org/software/guix/][GuixSD]]
which packages mpv 0.28 by default. I've been having issues with the
emms-player-mpv backend recently. Seemingly randomly, new additions to
the playlist (and hence the cache) will fail in the following manner:

- The entries in the playlist will be displayed as "playlist: $FILENAME"
(replace $FILENAME with the actual filename).

- The browser will be populated with the file names under
<unknown>/<unknown> (in the artist/album view).

- EMMS will fail to play any of those entries.

- Re-adding those files will inevitably fail again.

- Removing the cache file, starting over and re-adding the files will
sometimes work.

- The failed cached entries look like the following:

(puthash "/home/ambrevar/music/foo.ogg"
'(*track* (type . file)
(name . "/home/ambrevar/music/foo.ogg")
(metadata)
(last-played 23232 38887 674327 542000)
(play-count . 2))
emms-cache-db)

Using the mplayer backend, the above issue doesn't seem to ever happen.

The only thing I can think of is that I use a different version of mpv.
I can't see what could be the issue from a quick glance at the [[https://github.com/mpv-player/mpv/blob/master/RELEASE_NOTES][release notes]].
The default build parameters for mpv on GuixSD are:

#:configure-flags (list "--enable-libmpv-shared"
"--enable-cdda"
"--enable-dvdread"
"--enable-dvdnav"
"--enable-zsh-comp"
"--disable-build-date")

Anyone?

--
Pierre Neidhardt

[Pierre Neidhardt]

Found it:

https://github.com/emacs-helm/helm-emms/pull/10

Performing the default action on a candidate from the "Music
Directories" source adds files to the playlist as tracks with type
playlist because helm-emms-add-files-to-playlist uses
emms-add-file-playlist.
In my case, I have no player configured for playlists, so this action
causes an error: (error "Don’t know how to play track: (*track* (type
. playlist) ....
Note that emms-track caches information including the track type, which
can exacerbate the problem by continuing to use the wrong type even if
the track is later added with the correct type specified. This caching
can also mask the problem if the track is added with the correct type
before helm-emms adds it with the wrong type.
I see no reason to assume the files in a directory are playlists, so
this pull request replaces use of emms-add-file-playlist with
emms-add-file.

Don't mind my bug report, it was completely misguided.

That said, I think Emms should be smarter here: I think it should detect
whether the target is a playlist or a track. What about having just one
`emms-add-file` function then?

[Pierre Neidhardt]

Post by Pierre Neidhardt
That said, I think Emms should be smarter here: I think it should detect
whether the target is a playlist or a track. What about having just one
`emms-add-file` function then?

absolutely

I can work on it but I'm not so familiar with that part of the code.
Any cue there, Yoni?

A primitive/naive solution should be relatively straightforward. For
(define-emms-source file (file)
"An EMMS source for a single file - either FILE, or queried from the
user."
(interactive (list (read-file-name "Play file: "
emms-source-file-default-directory
emms-source-file-default-directory
t)))
(cond ((file-directory-p file)
(emms-source-directory file))
((emms-file-playlist-p file)
(emms-add-playlist file))
(t (emms-playlist-insert-track
(emms-track 'file (expand-file-name file))))))
... where `emms-file-playlist-p' doesn't exist yet, but would try to
naively detect if it is a playlist (checks extension). It would probably
need to have unwind protection in case that the playlist file isn't
supported by `emms-add-playlist' (checks content).
After all, `define-emms-source file' already checks to see if you've
pointed it at a directory so there is no reason not to keep on
overloading that function until it starts doing what we mean.
Does that make sense?

Totally. Will implement as soon as possible.

P.S. If you are OK with it, we should probably be copying the mailing
list on this as well.

Done, I had missed that I only replied to you after you've sent me an
e-mail offlist. To avoid this in the future, I think it's good practice
to always keep all recipients within an e-mail threads and to send
offlist e-mails separately.


--
Pierre Neidhardt

[Yoni Rabkin]

I totally missed the email; thanks for pointing it out. Yes, Zhang's
emms-player-mpv probably won't be considered for inclusion. I think that
people's (like me) mpv versions will ultimately catch up so that
everyone has the unix-socket option.
One of my other free software projects wrestles with different code
branches for different API versions... and it's something to definitelty
avoid.

I agree but I haven't really looked into the differences between the two
implementation. What are the pros/cons of the Unix socket? Other
things to consider?

My understanding is that it is the way forward for the mpv project, so
we may as well do it that way if we are going to support mpv, and it's
bi-directional:

"""
--input-file=<filename>

Read commands from the given file. Mostly useful with a FIFO. Since
mpv 0.7.0 also understands JSON commands (see JSON IPC), but you
can't get replies or events. Use --input-ipc-server for something
bi-directional.
"""