Mpv: OS X app bundle: running multiple videos simultaneously

[zmwangx]

When I use mpv from the command line, I can launch as many instances as I want, and hence run as many videos simultaneously as I want. However, the app bundle can only have one running instance at a time (unless I open -n in the command line, which defeats the convenience of an app bundle altogether), and that one instance can only run one video, as far as I know. In particular, this has the undesirable effect that when I'm watching a video opened with the app bundle, and unsuspectingly open another video (which is associated to the mpv app bundle by default), the latter video takes over and the position in the former video is lost.

In fact, I have an ugly workaround: I created an Automator app mpv-launcher.app that runs the command daemonize /usr/local/bin/mpv "$@" (daemonize so as to not block; the app immediately quits after launching, making multiple "instances" possible). But it would be nice if the app bundle could support multiple videos out of box. (See the update below for a better workaround.)

[ghost]

Isn't it an explicit feature of the bundle to start only 1 instance?

[pigoz]

Application bundles can only support one concurrent instance. To support multiple videos, we would need to rewrite it as a cocoa document based application, and use a new libmpv instance for each file open.

Of course, that would require quite a lot of work and the application bundle would become a small GUI. Marking as enhancement.

[zmwangx]

Sorry I don't quite get it. Is that a "feature"? Yes, normally there's only one instance of an app bundle, but one instance of the app bundle could support multiple videos.

[zmwangx]

Uh ninja'd by @pigoz.

[zmwangx]

I just noticed that the workaround I suggested above is a bit problematic. Specifically, daemonize doesn't play too well with the OS: when you select dark menu bar on Yosemite, apps launched with daemonize won't conform to that. So now I'm using a native shell solution (zsh required):

mpv "$@" &>/dev/null </dev/null &!

to replace the daemonize command line.

[pinumbernumber]

Still a problem. I get that it isn't really mpv's fault, but it makes for a pretty poor user experience on OSX. Perhaps one of the workarounds above could be implemented in the bundle by default?

[ghost]

but it makes for a pretty poor user experience on OSX.

I thought this is just how things work on OSX?

[zmwangx]

I thought this is just how things work on OSX?

I appreciate your effort in maintaining mpv. But these little shots at OS X users — is that really necessary? Do they add anything?

[kevmitch]

That's not a shot at OSX users. It's a statment / question about how OSX is expected to work.

[ghost]

Yes. Everything on OSX seems to be geared towards "single application / single window" mode. And of course the command line allows you to work this around.

[ghost]

PS: we even have a script for Linux (umpv) which replicates this behavior. It's usually called from DE file associations etc.

[vitorgalvao]

I thought this is just how things work on OSX?

Not at all; I’m thinking about it, and don’t know how you got that impression. Still, to make sure, I tried with QuickTime Player (which comes pre-installed on OS X) and it opens a new window if you already have one, so having a single window when playing video is definitely not expected behaviour on OS X.

[zmwangx]

That's not a shot at OSX users. It's a statment / question about how OSX is expected to work.

Sorry, I read it as "a pretty poor user experience is just how things work on OSX". If memory serves, wm4 was always kind of snarky about OS X, so that's why I read it that way. Sorry if I misinterpreted.

Everything on OSX seems to be geared towards "single application / single window" mode.

Citation needed? QuickTime, for instance, support multiple videos in multiple windows, and certainly won't "replace" a playing video when something else is opened.

Single application — yes. But as far as I know most if not all applications I use on OS X support multiple windows.

I can totally understand the desire to keep mpv minimal, and this issue can be easily worked around, as I pointed out in https://github.com/mpv-player/mpv/issues/1377#issuecomment-90370504, but "just how things work on OSX?" is not true at all.

[pinumbernumber]

@wm4 No, this isn't expected behaviour on OSX. If I open multiple image files associated with Preview, a window opens for each of them; if I open multiple text documents associated with Textedit/Sublime/whatever, a different window/tab is provided for each. Multiple Quicktime windows will open if I associate videos with that.

The only other app I have with the same problem is Blender.

[ghost]

If memory serves, wm4 was always kind of snarky about OS X

Oh, I definitely am. But I also realize that people like many UI specifics which I don't like on OSX. Different tastes I guess, but I don't mind giving people what they want, as long as it doesn't affect the holy command line.

There's still a technical problem though, as pigoz already said. OSX won't actually start a new mpv process, instead mpv gets a cocoa notification. @pigoz: could we maybe just spawn a new mpv process?

[pigoz]

As I said to get this right we need to implement a document based application, and that is not something we want in the core since I feel it would overcomplicate things. A GUI application would be a perfect place for this feature, it would open N windows and start a new libmpv instance for each one of those.

[pinumbernumber]

@pigoz Now I may well be completely incorrect here, and you would know a lot better than I seeing as you're a dev, but it strikes me that making a wrapper GUI and embedding mpv within it would lead to problems with frame pacing and such (since it isn't in control of its own window). That would be a shame, since a lot of work has gone into keeping that correct. I've avoided mplayer wrappers in the past (SMplayer and friends) due to possible issues like that.

Would that actually be a problem in practice?

EDIT: Additionally, how intrusive would it be in the meantime to add @zmwangx 's hack to the bundle?

[zmwangx]

Additionally, how intrusive would it be in the meantime to add @zmwangx 's hack to the bundle?

My workaround doesn't involve the bundle, and you will see multiple instances each with its own icon in the dock. That's not the expected behavior on OS X (although I have no problem with it).

[pigoz]

embedding mpv within it would lead to problems with frame pacing and such (since it isn't in control of its own window)

We don't have those problems with libmpv.

[basakil]

+1 for this ticket, -1 for its priority; it is a fault, not a requested feature: Default/proper OSX applications spawn either a new process or a new window, they don't destruct the current window/document.
Unfortunately, VLC also has this fault...

[zmwangx]

@basakil It is not a fault. mpv was never meant to be a proper OS X application. That's what you should take away from the triage.

[zmwangx]

Accidentally closed, sorry.

[netheril96]

What is the status of this issue? Won't fix? Low priority? Waiting for a Mac developer? No one cares?

[zmwangx]

@netheril96 Can't you see the tag? Nagging won't help with anything.

[netheril96]

@zmwangx

I am just afraid that no one cares to work on it, with the result that no one cares to update its status as well.

Are you one of the developers? If not, what I am afraid of might just be true.

[zmwangx]

@netheril96

I am just afraid that no one cares to work on it

Stacking nagging comments to the thread won't suddenly make someone care, unfortunately. Raise a PR, or leave our inboxes alone. Thanks.

no one cares to update its status as well.

Sure it's possible, maybe it could be changed to wontfix. Does that make much of a difference?

Are you one of the developers?

Once again, you can easily find out by looking for the badge at the top right of each post. Plus the fact that I was the OP.

[miaomi]

Try this open -na /<path-to>/mpv.app
Packge it into an AppleScript app as showing at VLC Wiki

[basakil]

To allow making a playlist when multiple files/folders are selected, instead of spawning an application for each selected file, I have modified the VLC script as:

on run
    do shell script "open -n /Applications/mpv.app"
    tell application "mpv" to activate
end run

on open theFiles
    do shell script "open -na /Applications/mpv.app " & quote & (POSIX path of theFiles) & quote
    tell application "mpv" to activate
end open

and saved it as an application in /Applications/.
I then copied the .icns files from mpv.app into it, changed the info.plist to include CFBundleDocumentTypes for extensions (brings up the new app in open-with menu) and changed the CFBundleTypeIconFile to document.icns.
Everything except the app icon works. As expected, the file(s) open after a little bit of delay (time to load & run the script).

[netheril96]

@basakil

Can you share the whole solution on github or gist?

[zmwangx]

To allow making a playlist when multiple files/folders are selected, instead of spawning an application for each selected file

With my solution you shouldn't see one instance for each file. I wrote mpv "$@", so that's exactly one instance with all the files/directories. I don't know about what you were using, maybe an AppleScript app using open -a (I don't really care anyway)?

[basakil]

There were problems with opening multiple files/directories so, I have modified the script as:

on run
    do shell script "open -n /Applications/mpv.app"
    tell application "mpv" to activate
end run

on open theFiles
    set files_ to ""
    repeat with theFile in theFiles
        set files_ to files_ & " " & quote & (POSIX path of theFile) & quote
    end repeat
    do shell script "open -na /Applications/mpv.app " & files_
    tell application "mpv" to activate
end open

I have also removed subtitle file associations from both this app and mpv.app (from info.plist files) and application icon also works now.
The modified app bundle can be found in OpenWithMPV.app repository with the instructions.

[basakil]

With my solution you shouldn't see one instance for each file. I wrote mpv "$@", so that's exactly one instance with all the files/directories.

@zmwangx , as I understand, your modified solution (mpv "$@" &>/dev/null </dev/null &!) requires using the terminal. The solution I am using, the AppleScript app solution which I was also using -a similar one- with VLC before, makes it possible to associate and open files/folders via Finder. I am not saying one is better or worse, they are just different.

(I don't really care anyway)?

When it comes to media players, OSX does not have many choices. Till recent times, VLC was the ultimate app choice. Although it lacks a decent gui/integration, MPV is better/robust/resourceful/... in almost every other factor. Our (at least, my) intention is to make it our new daily/anytime app choice, and it seems to be just a few little steps behind this; thanks to all contributors of MPV...

_By the way, I think a simple cross-platform text-based gl ui can also be considered (many games/frameworks do this), if anyone experienced is available ???_

[zmwangx]

your modified solution (mpv "$@" &>/dev/null

Not at all. That's used in an Automator app (if you read carefully).

(I don't really care anyway)?

To be clear, I don't really care about what problems you encountered with some other solution. Mine does the same thing without problems.

gui (like ncurses)

ncurses is for TUI. You can't play video in a TUI. And honestly I don't want a cross platform GUI with Qt, gtk and such, because they all look crappy, some better than others (Qt afaik is the best). VLC is a perfect example of a horrible GUI.

[basakil]

To be clear, I don't really care about what problems you encountered with some other solution. Mine does the same thing without problems.

Oh, mine runs/executes a new instance for each -clicked- file, which is the solution I wanted/preferred.

ncurses is for TUI

Updated the previous comment.

You can't play video in a TUI.

I did not mean putting mpv library in a full tui framework, some simple clickable osd/tui elements (like the progress/seek bar) would be enough; the end-user would see some available choices/options on the screen so would not be required to google them and change config files, at least for most of the -basic- stuff.

I don't want a cross platform GUI with Qt, gtk and such, because they all look crappy, some better than others (Qt afaik is the best)

I also don't think a heavy gui framework would be a better choice; it would increase app size, memory usage and startup time. Most of them also lack the native Look&Feel. I meant something like a simple game ui, if applicable...

[Akemi]

this is a feature for libmpv users. the core itself has to be rewritten to handle something like this. this is not going to happen and iina for example has such a feature.