won't play when launched from Finder

[Hill-98]

mpv Information

mpv v0.41.0-dev-g7b70999b6 Copyright © 2000-2026 mpv/MPlayer/mplayer2 projects
 built on May 13 2026 18:52:22
libplacebo version: v7.360.1
FFmpeg version: 8.1.1
FFmpeg library versions:
   libavcodec      62.28.101
   libavdevice     62.3.101
   libavfilter     11.14.101
   libavformat     62.12.101
   libavutil       60.26.101
   libswresample   6.3.101
   libswscale      9.5.101

Other Information

- macOS version: 26.5
- Source of mpv: 7b70999
- Latest known working version: cdbe01c
- Issue started after the following happened: open file

Reproduction Steps

Install mpv and set it as the default file opener, then open any media file from Finder.

Expected Behavior

Normal playback after opening media files

Actual Behavior

After opening the media file only the mpv window appears, no playback.

Log File

mpv.log

Sample Files

No response

I carefully read all instruction and confirm that I did the following:

• I tested and confirmed that the issue exists with the latest release version or newer.
• I provided all required information including system and mpv version.
• I produced the log file with the exact same set of files, parameters, and conditions used in "Reproduction Steps", with the addition of --log-file=output.txt.
• I produced the log file while the behaviors described in "Actual Behavior" were actively observed.
• I attached the full, untruncated log file.
• I attached the backtrace in the case of a crash.

[Akemi]

yeah, i noticed that too and was investigating. the commit that caused this is 81611b4

@na-na-hi any idea why mp_input_drop_files wouldn't work 'at startup' anymore? startup being at [mac/app] Opening dropped files: ["/Volumes/Downloads/[Mysteria] WORKING!! - S01E01.mkv"] in the logs. otherwise the code path works just fine.

working and broken log:
mpv_start_load_file_working.log
mpv_start_load_file_broken.log

[na-na-hi]

@na-na-hi any idea why `mp_input_drop_files` wouldn't 'work at startup' anymore? startup being at `[mac/app] Opening dropped files: ["/Volumes/Downloads/[Mysteria] WORKING!! - S01E01.mkv"]` in the logs. otherwise the code path works just fine.

The likely reason is that the handler calls mp_input_drop_files too early that the dnd client still thinks drag and drop is disabled when the dropped-file property change event happens, because it has not received the value of input-builtin-drag-and-drop yet. I can add a workaround for this, but it would still not work if a user disables input-builtin-drag-and-drop. Any reason mp_input_drop_files is used here? You can use loadfile command directly in the mac client for file loading that is not from drag and drop events. mp_input_drop_files is designed for drag and drop events only, which should never arrive very early to cause this issue.

[Akemi]

Any reason mp_input_drop_files is used here? You can use loadfile command directly in the mac client for file loading that is not from drag and drop events. mp_input_drop_files is designed for drag and drop events only, which should never arrive very early to cause this issue.

tbh i can't say if this has a specific reason. it was like this even before i started contributing. introduced here (code), which replaced the loadfile command. even though the commit message mentions "drop on the Dock icon" (a different d'n'd action) only, the same mechanism is used when files are loaded from Finder/at startup. since it was wrapped in a generic handleFilesArray function it was/is also used for other file open events.

some reasons i could think of:

• simplifying/unifying similar code paths to one
• using the special handling for sub files for example (i guess loadfile won't do that)
• possibly append/replace logic

what do think would be the cleanest change? imo i don't think it would be nice to add a workaround for this case, if we 'dirty' otherwise new clean code. also since it's behind the input-builtin-drag-and-drop, it would make even less sense that normally opening a file wouldn't work when disabled (pretty unexpected behaviour). though i am a bit afraid of some previously working use case breaking even more.

[na-na-hi]

what do think would be the cleanest change?

I think no matter what solution is used, "loaded from Finder" cannot use the same code path as "dropped on window", because it has nothing to do with drag and drop so it should not be affected by input-builtin-drag-and-drop. So it can be changed to use loadfile instead.

Regarding the "drop on the Dock icon" case: from mpv's view, the drag and drop handling is only used for "dropped on window" handling on all other platforms, not for anything else, so I think it should also use loadfile. But it depends on what Apple says in the HIG or what typical macOS users expect it to do. Is it normally expected that dropping a subtitle file on the dock icon, for example, behaves the same way as dropping on window on macOS?

[Akemi]

I think no matter what solution is used, "loaded from Finder" cannot use the same code path as "dropped on window", because it has nothing to do with drag and drop so it should not be affected by input-builtin-drag-and-drop. So it can be changed to use loadfile instead.

i agree on that based on the current code, but not completely how it was handled priorly though.

Regarding the "drop on the Dock icon" case: from mpv's view, the drag and drop handling is only used for "dropped on window" handling on all other platforms, not for anything else, so I think it should also use loadfile. But it depends on what Apple says in the HIG or what typical macOS users expect it to do. Is it normally expected that dropping a subtitle file on the dock icon, for example, behaves the same way as dropping on window on macOS?

trying to state some value-free points from my perspective. with the refactor(s) we redefined what that function does retroactively. which caused a regression. pigoz introduced that functionality here and on the same day he added the usage of the function for the normal file open event. this indicates that it wasn't just meant for file dropping on the window. admittedly the naming might be a bit ill-fated and also he might not have thought about that code path of file open via finder etc, indicated by the commit message. what i meant to say, what the function did was defined by the usage of that function at the time.

i believe the Apple HIG doesn't say anything specific about that case, it's do whatever with the event what is appropriate for your application. what users expect in general is impossible to say like that, without questioning a representative amount of people. from my view it can be expected that dropping files on the Dock icon does the same as dropping files on the window, eg it can be considered an 'extension' of the (main) window/tab and should behave the same (at least for mpv).

though i believe what we can say, some users surely used this feature as it was before and now expect it to work exactly like this. removing some of the functionality is unexpected for those and a regression.

sorry for the wall of text, to sum it up:

• i agree that "file open from finder" can't use same code path d'n'd uses, for obvious reasons like the option input-builtin-drag-and-drop
  • it could use parts of the code (opening, subfile case, etc), that aren't directly related to the d'n'd window case
• i would hate to remove features that previously worked
• there are a few cases that use this functionality to open files and need to be (re)considered
  • open file/url menu entry
  • d'n'd various types on the window (string, urls, files, etc)
  • opening via finder/open with
  • d'n'd on dock icon (when already open, when still closed)

i need to evaluate what was even possibly before, some cases might have been completely theoretical but practically never occurred (no functionality lost), so using loadfile might be completely sufficient in those cases.

[na-na-hi]

trying to state some value-free points from my perspective. with the refactor(s) we redefined what that function does retroactively. which caused a regression. pigoz introduced that functionality here and on the same day he added the usage of the function for the normal file open event. this indicates that it wasn't just meant for file dropping on the window.

In 082c5c1 the mp_input_drop_files function was previously called vo_drop_files. This simply a commit that allows vo_drop_files, which is commented to handle drop on VO window, to be used by other code. In 69d44d9 the commit message mentions refactor files drag and drop on the Dock icon which is clear that mp_input_drop_files function is intended to be used as drag and drop, just a different kind.

So the function overall was intended to be used as general drag and drop handler, not a generic file opener that replaces normal loadfile in all cases.

i believe the Apple HIG doesn't say anything specific about that case, it's do whatever with the event what is appropriate for your application. what users expect in general is impossible to say like that, without questioning a representative amount of people. from my view it can be expected that dropping files on the Dock icon does the same as dropping files on the window, eg it can be considered an 'extension' of the (main) window/tab and should behave the same (at least for mpv).

though i believe what we can say, some users surely used this feature as it was before and now expect it to work exactly like this. removing some of the functionality is unexpected for those and a regression.

If this is the expectation, then dropping files on the Dock icon can be considered drag and drop, so it can use the handling in builtin dnd client.

i need to evaluate what was even possibly before, some cases might have been completely theoretical but practically never occurred (no functionality lost), so using loadfile might be completely sufficient in those cases.

The internal handle_dnd function can be exposed so that other code (like "open file/url menu entry" and "opening via finder/open with") can call it without needing to have dnd enabled. This would keep compatibility.

[forthrin]

$ curl https://github.com/mpv-player/mpv/compare/master...Akemi:mpv:mac_open_file.patch | git apply && mpv-build

+1. Happy to see it's an addressed issue. If I'm doing this right, doesn't open a window, just a non-responding process.

[Akemi]

from the PR

... it might also cause deadlocks ...