mpv closes when dropping a windows shortcut (*.lnk) that points at a playable file

[keithnbrown]

Important Information

• mpv version: mpv 0.33.0-46-gdde0189279
• OS version: Windows 10 20H2
• binary source: https://github.com/Moodkiller/MPV-Made-Easy which apparently sources the binary from https://sourceforge.net/projects/mpv-player-windows/files/ using a script in the repo

Reproduction steps

With the program running, drag and drop a windows shortcut that points to an mpv-playable file. Tested shortcuts pointing at multiple different mkv and mp4 files.

Expected behaviour

mpv resolves the shortcut and plays the target file. This is expected behaviour by any app on windows that supports drag-and-drop.

Actual behaviour

mpv closes/crashes without an apparent error code

Log file

first attempt - this one didn't launch the player due to me using the wrong cmmand line
output.txt
second attempt - a better log that shows the load
output.txt

Sample files

Shortcuts are easily creatable on windows, so I'll not burden this ticket with specific files.

[CounterPillow]

Your log file doesn't show you actually trying to play a .lnk, it just shows you running mpv with no arguments.

[keithnbrown]

Your log file doesn't show you actually trying to play a .lnk, it just shows you running mpv with no arguments.

That's because the program didn't actually launch when I used the argument from the command line, so I couldn't demo the behaviour, and I assumed that behaviour was normal for that argument as if you wanted to use it to see any startup options.

I've just discovered that's because the MINGW64 git bash window from git for windows wouldn't do it, but powershell would. so here's a better output.txt. Sorry for the confusion, I have limited experience of the idiosyncrasies of using different command lines and my experience is mainly in windows command prompt.

If I double click the shortcut, it'll launch mpv as usual and play the file. the issue is when I drag and drop the shortcut onto an already-running player.

[stax76]

Crash is not good, but resolving a shell link? Don't seem important to me...

[CounterPillow]

There is no crash. It just quits normally as it fails to demux the file.

I do see the use-case for playing LNK files, but there are some security implications to this.

LNK files can point to remote hosts, including e.g. CIFS shares on the internet. Playlist files in such cases should be treated as untrusted as with other network URLs, but implementing this may be error prone and painful.

[keithnbrown]

My issue is mainly that this is expected behavior on windows, and that closing and saying nothing is not helpful.

As for the security concern, couldn't you resolve a location and then fail if not local?

[CounterPillow]

couldn't you resolve a location and then fail if not local?

Easier said than done. Windows has about 3 different ways to specify paths, and some of them make it very hard to know whether a path is local or not

[keithnbrown]

couldn't you resolve a location and then fail if not local?

Easier said than done. Windows has about 3 different ways to specify paths, and some of them make it very hard to know whether a path is local or not

I'm guessing you're not a windows user then? as the three different types are actually rather easy to differentiate, even based on a quick string search. And that article is organised in order of how common they are to see.

• "Traditional DOS paths" are your bog-standard file path where the only real difference to unix paths are slash direction and that there may be a drive letter
• UNC paths are network paths and are always prefixed with a double-backslash "\\"
• DOS device paths are very rarely used in a normal user environment. they're prefixed with \\.\ or \\?\

The path normalisation section of that article is a pretty standard affair, and besides any cross-platform library you're using should call the appropriate windows functions to resolve the path under the hood anyway. Or if you're not using a cross-platform library (but I assume you are) you'll need to be accessing windows API functions anyway to do anything, so this should be easily handle-able.

And my previous comment about "fail if not local?" is actually bunk as accessing media from a network share is a perfectly normal use-case.

What's exactly is the difference between me putting in a full network path to a file on the command line as an argument for mpv vs mpv asking a dropped *.lnk file for its target? Granted the file target resolution when I click on a shortcut on my desktop is handled by windows, but the question then becomes: how do other programs handle a shortcut being dropped on them? As they act as if the file itself had been dropped and act normally.

[Hrxn]

Granted the file target resolution when I click on a shortcut on my desktop is handled by windows, but the question then becomes: how do other programs handle a shortcut being dropped on them? As they act as if the file itself had been dropped and act normally.

There is no universal standard. Some programs do it one way, other programs the other way.

[keithnbrown]

Granted the file target resolution when I click on a shortcut on my desktop is handled by windows, but the question then becomes: how do other programs handle a shortcut being dropped on them? As they act as if the file itself had been dropped and act normally.

There is no universal standard. Some programs do it one way, other programs the other way.

What's one way or the other? I've never seen an app that supports files being dropped on it reject a shortcut to a file it can handle. Unless you have a common example I've forgotten. sure some Act in some different ways to a file being loaded vs dropped, but dragging the file itself and dragging a shortcut to it should be the same as far as the target file and the program is concerned

[oakkitten]

Easier said than done.

i'm assuming this to mean that currently mpv doesn't differentiate between local and remote windows paths, why handle .lnk differently?

[Hrxn]

What's one way or the other? I've never seen an app that supports files being dropped on it reject a shortcut to a file it can handle. Unless you have a common example I've forgotten.

Try it for yourself: Open a .LNK file to a program in Windows' own Notepad, versus dropping this .LNK into the application window.

sure some Act in some different ways to a file being loaded vs dropped, but dragging the file itself and dragging a shortcut to it should be the same as far as the target file and the program is concerned

It usually is, but again, this is not a universal standard.

i'm assuming this to mean that currently mpv doesn't differentiate between local and remote windows paths, why handle .lnk differently?

Why handle .LNK at all? If you ask me, mpv shouldn't. This behaviour is controlled by the standard GUI shell on Windows, otherwise known as explorer.exe. But on a lower level, so to speak, this is not typical. If you drop/open a file, it will handle the actual file involved. I personally prefer that, actually, so I'm not convinced that mpv should necessarily do anything different here.

Edit:

And my previous comment about "fail if not local?" is actually bunk as accessing media from a network share is a perfectly normal use-case.

Yes it definitely is, and this works in mpv as naturally expected. You can open any media from anywhere the OS itself can handle.
What's the exception here is only .LNK files.

[keithnbrown]

@Hrxn Okay, so I did try your example for notepad, and while I do see your point I argue it's a different kind of program at a base level only designed to read bytes from a file and interpret as windows-formatted text. However, we're talking about a media player here.

While there isn't a universal standard across all programs, there is a general expectation of behaviour from media players, and even in general, the programs that don't "simply open the file" are rather few and what they do aside from that makes sense given the context, even if that's an error saying "I don't know what to do with this".

Windows Media Player, MPC-HC and VLC all do the behaviour that is expected of a media player on windows; which is to resolve the shortcut and play the file. And given that VLC is cross-platform and does what is expected, then there's no real reason for mpv not to.

Hrxn, are you primarily a Windows user? If not, then your presences are skewed away from a windows user's. If you are, then I do query your reason why given that the behaviour I'm mentioning is missing is more common than it not being.

Looking at a cross-platform point of view, I'd expect a program to act the same on all platforms, while still obeying the current platform's expected behaviours. While mpv is Linux-like in a lot of its behaviours, it's also built for windows so in that build windows-like behaviours are expected.

We're also not talking about something as user-unfriendly as a development tool or creation suite, we're talking about something designed to play files and as an *.LNK file is known to be a shortcut to a file, I'd expect this shortcut resolution to happen or for it least to say something instead of just closing.

[Traneptora]

The way to do this properly would be to treat LNK files as a type of playlist with one entry, and that's the location the LNK points to. While this is not necessarily difficult it's in the "patches welcome" sort of standpoint at the moment.

[keithnbrown]

I'd be more than on board with that solution as it would solve the issue beautifully.

By "Patches welcome" you mean the kind of patch that, given a pull request and inspection, would be accepted into the codebase?

[xnoreq]

I could write a patch with the functionality that resolves Windows links into paths if you tell me where to put that code and where to hook it up such that .lnk paths/filenames are replaced with the resolved paths/filenames.
Also, I'd like to change all paths on Windows into UNC paths to circumvent path/filename length limitations.