Re: a way to not close mpv window on next/prev because exwm

[Stefan Huchler]

Hello Yoni,

well it's a wrapper that if you open another file with umpv next file it
adds it to the playlist instead of opening another window or overwriting
it.

Yes it seems not the right solution, the point is to not have the window
closed, I don't need syncronisation between the 2 playlists.

The window closing and opening is the again the problem.

Tried a bit something but don't work:

(defun emms-player-mpv-next (track)
  (let ((track-name (emms-track-get track 'name)))   
    (emms-player-mpv-cmd `(loadfile track-name)))

(emms-player-set emms-player-mpv 'next #'emms-player-mpv-next)

(defun emms-next ()
  "Start playing the next track in the EMMS playlist.
  (interactive)
  (emms-playlist-current-select-next)
  (when emms-player-playing-p
    (emms-player-next (emms-playlist-current-selected-track)))
  ;; (emms-start)
  )

(defun emms-next ()
  "Start playing the next track in the EMMS playlist.
This might behave funny if called from `emms-player-next-function',
so use `emms-next-noerror' in that case."
  (interactive)
  (emms-playlist-current-select-next)
  (when emms-player-playing-p
    (emms-player-next (emms-playlist-current-selected-track)))
  ;; (emms-start)
  )

It's detectable if a track ends and then it just should send the command
loadfile nextfile which default replaces and starts the next track. and
if the track is eof it should do the same basically.

When I read the doku of emms-player-mpv-ipc-method it sounded to me that
this is configurable through this variable:

;; It works in one of two modes, depending on `emms-player-mpv-ipc-method'
;; customizable value or installed mpv version:
;;
;;
;;  - Using long-running mpv instance and JSON IPC interface to switch tracks
;;    and receive player feedback/metadata - for mpv 0.7.0 2014-10-16 and later.
;;
;;  - Starting new mpv instance for each track, using its exit
;;    as "next track" signal and --input-file interface for pause/seek.
;;    Used as a fallback for any older mpv versions (supported in all of them).
;;

So that sounds that 1 mode starts and exits and the json ipc don't does
that, but I think I missunderstand that, but I don't see a need for the
quit of the window in between, when I set it to ipc-server or it
autodetects that I don't see why it should stop the mpv when I set
keep-open in my mpv config file.

Or in other words I wish it would not do that or give a option to
prevent it from quiting the player between each track.

Yoni Rabkin <yoni@rabkins.net> writes:

> Stefan Huchler <stefan.huchler@mail.de> writes:
>
>> I try to manage video files over emms which generally works the problem
>> is when it closes the window each time a new file starts the window pops
>> directly in my current frame because I use exwm, instead of staying in
>> the other frame on the other monitor so is there a way to not close the
>> window for changing to the next file?
>>
>> I used umpv before which should be included in the mpv package that way
>> it adds files instead of starting now windows. Not sure if there are
>> other ways to keep the window open, but I think you could if you detect
>> end of file instead of closing clear playlist and at current file in and
>> start playback?
>>
>> Would that be a new player backend or would a few modifications to the
>> mpv backend be enough?
>
> I'm unfamiliar with umpv, but doesn't mpv already reuse a window if
> given a playlist?
>
>     $ mpv --playlist=play.list
>
> ...should reuse the same window. So I'm unsure of what umpv adds unless
> it allows you to append files to already running playlists.
>
> What you are asking seems to be tantamount to Emms managing mpv's
> --playlist playlist, which would entail somehow syncing the two.
>
> I use awesomewm, and I watch videos exclusively through Emms, but I
> never have a playlist of videos to watch one after the other (and I have
> only one monitor) so I've never had this issue.
>
> A good solution would be to config mpv to open its windows always in the
> right place. If there is a way to do that, then perhaps emms-player-mpv
> can add the option to pass those arguments to mpv.
>
> Another solution perhaps would be to add an option to emms-player-mpv
> which feeds the current emms playlist to mpv as an argument to
> --playlist. The problem there, as above, is that you would have no way
> to edit that playlist once it is sent to mpv.