What is the process by which a Windows program can detect when a copy of itself is already running and pass the arguments along to that instead of opening a second process? e.g. like MPC-HC does, when you open a second video file while it's already playing, it replaces the currently playing file with the new one.
I want to do something similar for mpv, since apparently the current Windows version can't.
If you're using a .NET language you can use a mutex (docs.microsoft.com
indian curry magic
it's called shitty programming
Cool, will check that out, thanks.
There's a few ways to do it, each with its own pros and cons. If the first instance of the program has an open window, you can send a window message to it. You can also have the initial instance create a hidden window, so it's always available to receive messages. There are also named pipes and COM local servers. Regardless of which method you choose, it's actually pretty hard to implement this correctly without subtle race conditions. If you do it wrong, launching two instances of the program at the same time might still result in two instances, or maybe no instances, so be careful.
For mpv it might be best to use a named pipe, since mpv doesn't always create a window, and you might be able to reuse parts of mpv's existing named pipe IPC. Sending the command line info is also a pain with window messages, but really easy with named pipes. I'd also consider using a COM local server, because Explorer can call those directly, so when you load files from Explorer, it won't actually need to launch a second instance of mpv.
One problem you could have with mpv is that mpv is a command line program, so it's designed to be launched from scripts and other programs. Someone might write a script that launches mpv to transcode a file or dump a stream, or they could even just write a batch file that does some long task and calls mpv to play a sound when it's finished. Ideally, you wouldn't want these instances of mpv to replace an instance that the user is actually using to play videos. You could consider only replacing instances that have been launched with --profile=pseudo-gui.
What I'm envisioning is something like the unix screen command, where I could supply a user-defined name or handle to a given process and repeated executions would check for that existing process. Like:
>mpv -screen ambient rain.mp4
opens new mpv window and gives it the handle "ambient"
>mpv -screen ambient river.mp4
sees an "ambient" mpv window already exists so it replaces the current file with the new one
>mpv -screen quickview %1
could set this as default file handler for, say, webm files to browse saved files in a directory, reusing the existing window each time.
And then simply calling mpv without the arg would always open a new window.
In retrospect it would probably be better to just write a wrapper that uses the named pipe IPC to do this, and detect if the pipe exists or not first.
Yeah, you could just make a clone of the umpv script as a Windows exe. That user defined name could make part of the pipe name. If you use mpv-install.bat to make file associations, it's pretty easy to switch the .exe it actually points to.
Hell, even if you're NOT using .NET, the standard way of doing this is with a mutex (docs.microsoft.com
A named mutex is the standard way to block multiple instances, but it doesn't solve OP's problem because you can't transfer data with a mutex. You need an IPC method like a window or a named pipe to transfer the command line or a list of files to the original instance. Once you have an IPC method, you don't need a mutex because the existence of the IPC object can tell you whether there's an existing instance or not.
Didn't know what the win32 equivalents name was so didn't mention it.
I was only bothering with answering the part about detecting another instance running. How they wanna do IPC is a whole other question.
It's the same question. Like I said, once you have IPC, you don't need a mutex, because the existence of the IPC channel is your mutex. Yeah, you can check for the existence of a mutex and do IPC as two separate steps. A lot of programs do it that way, but it's bad design. The mutex is redundant and it introduces potential race conditions, since you can't create or destroy a mutex and a named pipe simultaneously.
named pipes
unless your new process is a child of the main, then you could also use anonymous pipes
>linux
>just broadcast a dbus signal everytime you attempt to open something
>windoze
>ackstually there are several ways to go about this, most consist of horrible hacking
Jokes aside, look up singleton process in Windows.
does windows not have an equivalent to dbus?
COM is kind of like D-Bus in Windows. Like D-Bus, it's an enormous fucking pain to use, though unlike D-Bus, at least you can guarantee it's always available. If you make your program rely on D-Bus in Linux, the minimalistfags will get upset.
well, making a named pipe for communicating between instances of yourself in /tmp isn't unusual either
Yeah, a unix socket in /tmp or /run is decent option for Linux, and it's pretty similar in semantics to Windows named pipes. Just make sure it has a different name per-user and session and it's created with the correct permissions.
In traditional WinAPI, we used to create a window class, which should have a unique name. You could search if there were any windows with the same class name already open, and shift the focus to them instead of opening a new one.
you reminded me that cmd doesn't even have a sleep command
Making a wrapper was pretty easy and gets the job done. Now to move on to my next goal, adding arbitrary commands to playlists, like for setting custom volumes on each file.
Feels good to be an mpvnet chad