Mpv: Doesn't autoplay when opening a file from the finder

[tleunen]

mpv version and platform

0.27.0 on Mac OS Sierra
Installed via homebrew with the with-bundle option.

Reproduction steps

• Double clicking on a video file in your file system
• mpv opens with the screen "Drop files or URL to play here"
• The video file never starts

In my dock, it seems the app starts once, then gets killed, and starts again. I'm saying that because I see the icon appearing, then disappearing and re-appearing again.

Opening the file via a command line works.

Expected behavior

• The video file should automatically starts when mpv is opened when opening a file

Actual behavior

• The video file never starts

[Akemi]

0.26 works? if yes it's probably related to 12ee13101ba37d2674974eb8e4777104069c9461. can you try reverting that commit. this doesn't need a rebuild you just need to change this mpv.app/Contents/MacOS/mpv-wrapper.sh file in the bundle. alternatively copy the same file from an older working version.

what is your standard Shell?

also it might be related to issue #4658.

[Argon-]

Before reverting stuff it's probably useful to first generate some kind of log or error message.
Can you open your terminal and paste: /Applications/mpv.app/Contents/MacOS/mpv-wrapper.sh, followed by a space and then drag&drop the file from Finder onto the terminal window. It should insert the file's path.
Now press enter in the terminal and tell us what's happening and printed.

[Akemi]

that won't work because the wrapper script discards all arguments and it also silence the terminal output (when mpv is called).

[Argon-]

Damn, too bad. Problem is - in case this is caused by the commit in question - reverting might make this issue go away but the ones the commit closed will pop up again.
Actually, I think that a lot of these problems stem from incorrect user setups or botched environments (otherwise we'd see a ton more of these problems). We just have no way of telling what the cause is.

This modification should allow to debug it like I proposed, shouldn't it?
https://gist.github.com/Argon-/2661a199d41f29c385b0891eb9cc63f1

[Akemi]

yeah i agree. too bad it's really hard to debug those problems. it would be good if we could narrow the problem down though.

i don't think it will help much since the mechanism of "Open With", double click, dropping a file on the App, etc works differently and not through command line args. the file that is supposed to be opened 'vanishes' somewhere between invoking mpv in the wrapper and the NSApplicationDelegate when the "files to be opened" are requested by cocoa. so somewhere in-between the inner workings of the cocoa framework and the second shell we use in the wrapper. something we don't have much influence over.

[rezzo]

Same issue here with mpv up-to-date and latest macOS.

[nirocfz]

same issue here.

I tried older versions, 0.25.0 works well, and 0.26.0 and 0.27.0 has this issue.

Now I'm using 0.27.0 and copied mpv.app/Contents/MacOS/mpv-wrapper.sh from 0.25.0, everything seems to be ok.

After several experiments, I think -i in args causes the problem (don't know why).

case "$SHELL" in
    *bash) args="-l $args";;
    *zsh) args="-l -i $args";;
esac

[Argon-]

-i is needed to make it source your local/user specific zsh configs. Test for yourself which files are loaded:

zsh -l -o SOURCE_TRACE -c "echo hi"
zsh -l -i -o SOURCE_TRACE -c "echo hi"

Without -i it will only source /etc/zprofile and ~/.zshenv which is not where Mac users define their PATH variable, usually. But getting this PATH is the reason for this wrapper.
My bet is (because that would be the easiest outcome): your zsh config is butchered or contains something leading to this failure.
This is very similar to: https://github.com/mpv-player/mpv/issues/4658#issuecomment-318897371
In his case, removing -i also worked. It turned out this was the case because a script he loaded in his config (some nvm script) did stupid things.

[nirocfz]

@Argon- yes, there's . "$NVM_DIR/nvm.sh", exactly the same situation.
it is a normal config for nodejs developers.

[Argon-]

I'm not sure what we should do about it. I mean we are simply calling zsh to open mpv. All you could claim we do wrong is sourcing the user's config but that's precisely why we do it.
I claim the nvm.sh script is at fault. I don't know exactly what it does (I took a quick look inside and apparently it's doing some PATH shenanigans, including export) but it shouldn't prevent a normal program from starting up. Imo zsh <flags> program should _not_ fail because of sourced configs, otherwise it's the config's fault.
This does not only affect mpv after all. It affects all programs called like that.

[nirocfz]

I traced the script nvm.sh, the call graph:

nvm_process_parameters -> nvm_auto -> nvm use -> nvm_die_on_prefix

then there's the code NVM_NPM_PREFIX="$(npm config --loglevel=warn get prefix)", it calls another node script npm

in this script npm, there's a line of code to change process title process.title = 'npm'

The process.title property returns the current process title (i.e. returns the current value of ps). Assigning a new value to process.title modifies the current value of ps.

if I remove this line of code, mpv work well.

i'm confused, does it have relationship with this issue?

[Argon-]

Maybe this interferes with the magic that delivers arguments (the files to open) to the mpv process?

[Akemi]

fixed via 77021cf6fe6a1813b832c8927c288e958b6f6845.

[huhuang03]

@tleunen Hello, have you solve this when install via brew not the source.
I install mpv by your step and now my mpv version is 0.27.0_5. But the problem is still.
Forgive my poor English.

[tleunen]

Nop, still have the same issue with latest mpv from brew.
cc @Akemi

[AirPort]

It's fixed in mpv 0.28.0. Brew still have 0.27.0 because the latest version doesn't build against the current ffmpeg's stable release.

[Argon-]

You can get the latest version of mpv using

brew install --HEAD ffmpeg
brew install --HEAD mpv