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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Stefan Huchler
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?


Reply | Threaded
Open this post in threaded view
|

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

Yoni Rabkin-2
Stefan Huchler <[hidden email]> 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.

--
   "Cut your own wood and it will warm you twice"

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> writes:

> Stefan Huchler <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

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

Mike Kazantsev-2
In reply to this post by Stefan Huchler
On Fri, 20 Nov 2020 01:19:34 +0100
Stefan Huchler <[hidden email]> wrote:

> 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'd try adding following options to emms-player-mpv-parameters:

  --force-window=immediate --keep-open=always

And in general, check out mpv manpage, it has a lot of configuration
for how/where/when its video playback window is presented.


> 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?

Should be possible to do with this backend, but I think Yoni is right
about extra work for syncing it.

Currently emms-player-mpv-start runs "loadfile" with just a file
argument to start a new track once mpv indicates that playback
finished, and doesn't use playlist functionality on the mpv side at all -
playlist is kept in emms and it just tells mpv what file to play and when.


But "loadfile" command has following spec (from mpv manpage):

  loadfile <url> [<flags> [<options>]]
    Load the given file or URL and play it.
    Second argument:
    <replace> (default)
      Stop playback of the current file, and play the new file immediately.
    <append>
      Append the file to the playlist.
    <append-play>
      Append  the  file,  and if nothing is currently playing, start playback.
      (Always starts with the added file, even if the playlist was not empty before running this command.)
    The  third  argument  is  ...

So it is possible to append entries to playlist on the mpv side
and check/remove them in whatever ways as well.

I think you'd either want to add such entries at least couple seconds
before previous one finishes, or synchronize playlist and playback
position between emms and mpv entirely (i.e. when something added/removed
from emms playlist, change is instantly propagated to mpv).


First option - adding entries before playlist ends - can probably be
due by adding a check/hook to playback time updates in emms, and enabling
emms-player-mpv-update-duration.

Another option would be to always add one playlist entry ahead of one
playing, and a hook to remove that if it's gone from emms playlist,
but not sync the entire thing otherwise.


And for syncing whole playlist, guess you'd want to use loadlist +
loadfile + playlist-remove + playlist-move and such to do it.

It's probably easier that it sounds - just write one function to fetch
whole playlist from mpv and generate/send commands to synchronize it,
and then run that on any emms playlist changes.


If simple display options suggested above work though, maybe such
modifications shouldn't be necessary, but if you'll come up with an
algorithm to manage playback that way, might be worth merging it into
the backend too, as it'd allow using mpv prefetching options - e.g.
have playlist of videos on slow network media or youtube links that
would be prefetched and cached by mpv while previous file is still playing.


--
Mike Kazantsev // fraggod.net

Reply | Threaded
Open this post in threaded view
|

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

Mike Kazantsev-2
In reply to this post by Stefan Huchler
On Fri, 20 Nov 2020 03:39:53 +0100
Stefan Huchler <[hidden email]> wrote:

> 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.

I think such synchronisation was suggested as a way to fix the issue.
I.e. if you let mpv know that there's a track after current one via its
own internal playlist, it won't close the window.


> 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.

Yes, it should not quit between tracks as it is, unless you set
emms-player-mpv-ipc-method to 'file.

I think loadfile simply replacing the currently-played track does the
video window closing/reopening on mpv side though, hence my earlier
suggestion to try some options which might prevent that.

Failing that, sounds like my other suggestion (to use append flags for
loadfile before track ends or sync playlists from emms) was quite like
what umpv does.


--
Mike Kazantsev // fraggod.net

Reply | Threaded
Open this post in threaded view
|

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

Mike Kazantsev-2
On Fri, 20 Nov 2020 12:44:26 +0500
Mike Kazantsev <[hidden email]> wrote:

> I think loadfile simply replacing the currently-played track does the
> video window closing/reopening on mpv side though, hence my earlier
> suggestion to try some options which might prevent that.

Or actually maybe not loadfile, but rather when it gets issued - after
mpv already stopped the playback and closed video window.

If that's indeed the case, --force-window and --keep-open options sound
like they should be exactly what you might need to address this issue.


--
Mike Kazantsev // fraggod.net

Reply | Threaded
Open this post in threaded view
|

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

Stefan Huchler
Mike Kazantsev <[hidden email]> writes:

> If that's indeed the case, --force-window and --keep-open options sound
> like they should be exactly what you might need to address this issue.

Well I thought for video files keep-open would be enough but adding
force-window did actually the trick, which is great.

I want to use it to open kodi series mkvs there is no way it can either
read dlna/upnp or info files would be great to get the right order and
flag it as watched? I mean I can add the folder and then I guess
manually set all as watched or delete it afterwards as good enough
solution but of course that would be better.


Reply | Threaded
Open this post in threaded view
|

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

Mike Kazantsev-2
On Fri, 20 Nov 2020 12:06:17 +0100
Stefan Huchler <[hidden email]> wrote:

> I want to use it to open kodi series mkvs there is no way it can either
> read dlna/upnp or info files would be great to get the right order and
> flag it as watched? I mean I can add the folder and then I guess
> manually set all as watched or delete it afterwards as good enough
> solution but of course that would be better.

Didn't use upnp/dlna myself much, but if I understand correctly,
you mean that videos are served over dlna by kodi and that protocol
has some kind of mechanism to mark them as watched, which mpv doesn't
use by default.

As I haven't used that stuff myself, don't know how to do it, but mpv
almost certainly uses some lib for playback from these sources.
I'd suggest checking a) if this lib supports such marking and b) how it
can be enabled - might be possible to do via env var or in some config
file.

And if it doesn't have such support - not much can be done on the mpv or
emacs side, obviously, but maybe you can open feature request on their
bugtracker, if it's a trivial thing to do, maybe devs just aren't aware
of that protocol extension or something.

If library has support that can only be enabled on C API level and mpv
doesn't have an option for it, I'd suggest either submitting a patch or
asking for a feature on mpv bugtracker - if it's just an extra option
and a flag to pass, should be only couple extra lines of code.

If you mean something entirely different, maybe on the kodi side,
or via separate api, that's probably not related to emms/mpv much and
can be done either via python addon script in kodi or by adding a hook
to run during/after playback in emacs (to mark position or watched
status).


--
Mike Kazantsev // fraggod.net