mpv fatal: Error parsing commandline option wid: option requires parameter

[leaty]

Posting this issue now, meanwhile I'll try to see if I can work around it or see if something else is causing the issue.

• mpv version
  mpv 0.32.0
• Linux Distribution and Version
  5.4.15-arch1-1
• Source of the mpv binary
  Arch repository
• If known which version of mpv introduced the problem
  mpv 0.32.0 I believe.
• Window Manager and version
  i3 version 4.17.1
• GPU driver and version
  nvidia 440.44

Reproduction steps

Both of these commands:

xwinwrap -g 1920x1080+0+0 -ov -ni -s -nf -- mpv --vo=xv --no-audio --loop --wid WID /path/to/video.m4v

mpv --vo=xv --no-audio --loop --wid WID /path/to/video.m4v

Now yield the following error:

Error parsing commandline option wid: option requires parameter

Exiting... (Fatal error)

Expected behavior

Oh, nothing you know, just my sweet and lovely video wallpaper shows up :)

Actual behavior

No video wallpaper, just fatal error.

Log file

It doesn't get that far.

[leaty]

I kinda goofed the title there at first, oops.

[leaty]

Okay so wid=WID technically works, so I suppose the syntax changed or is a different way of providing the argument.

But using it this way makes it expect an integer, which yes - it probably should, but WID used to work before and I always thought it had to do with giving it the window of the wrapping command, in this case xwinwrap. I may be wrong here.

[CounterPillow]

Read interface-changes.rst

[leaty]

Thanks, I didn't know about that changelog. The answer here is -wid WID i.e. one dash.

[CounterPillow]

or fix xwinwrap so that it doesn't just straight up iterate argv looking for an exact match of "WID" in the child arguments. Make it a pattern match and replace instead.

[leaty]

Valid point, now I actually know how it works as well.

[ghost]

The answer here is -wid WID i.e. one dash.

God, I hate users so fucking much. At least I don't have to feel bad about breaking your shit.

[leaty]

No, you don't. But you shouldn't expect every user to be omniscient, that really won't be good for your psyche. We all do with time as we please, we may create or help projects, or even just read up on them when one finds them interesting. But not for every, single, project.

It's just a wallpaper that I'm using these two (xwinwrap/mpv) unrelated projects for. In both, all I know is the man page. But I apologize for using mpv I guess.

[CounterPillow]

I'm pretty sure he was commenting on you choosing to use legacy command line syntax instead of improving xwinwrap.

[ghost]

Yes, plus that syntax makes mpv not only complain that it's legacy, but also mentions the correct syntax to use. Concluding that the legacy syntax is the "right thing" when mpv basically slaps your face when using it is just.

[leaty]

I know what he was referring to, it's very plain. I also ran my answer with a wm reload at work, so yes I did miss the slap to my face and I did skim the changelog. Until @CounterPillow mentioned fixing xwinwrap, I did not know it was a legacy option, which is why I re-read and replied with _"valid point"_.

@wm4 Look, I understand your stance fully and agree in general, we need not argue. But with how you come off shouting you'd make anyone mistake it for how your day was, albeit with less detail than the real story. In this case I will trust that you were just genuinely upset with my uninformed misleading.

Also, it sounds as if you're assuming I worked on or even created xwinwrap, I want to make it clear that I have not. I realize you'd rather see xwinwrap get fixed than supporting a legacy option, I agree. But until this legacy option is removed from mpv, the answer I wrote is still a viable solution for people using mpv with xwinwrap and --wid WID in their scripts. My amazing little wallpaper works just fine for now. Thank you for your help.

[CounterPillow]

diff --git a/xwinwrap.c b/xwinwrap.c
index 2cfb8aa..a34b1c0 100644
--- a/xwinwrap.c
+++ b/xwinwrap.c
@@ -288,6 +288,9 @@ int main(int argc, char **argv)
     bool skip_pager = false;
     bool daemonize = false;

+    char* pre_wid;
+    char* post_wid;
+
     win_shape   shape = SHAPE_RECT;
     Pixmap      mask;
     GC          mask_gc;
@@ -420,10 +423,17 @@ int main(int argc, char **argv)

     for (i = i + 1; i < argc; i++)
     {
-        if (strcmp (argv[i], "WID") == 0)
-            addArguments (widArgv, 1);
-        else
+        char* wid_pos = strstr(argv[i], "{WID}");
+        if(wid_pos != NULL) {
+            size_t num_to_copy = (size_t) wid_pos - (size_t) argv[i];
+            pre_wid = malloc(num_to_copy + 1);
+            strncat(pre_wid, argv[i], num_to_copy);
+            post_wid = malloc(strlen(wid_pos) + num_to_copy - 5 + 1);
+            strncat(post_wid, wid_pos + 5, strlen(wid_pos) - num_to_copy - 5);
+            addArguments(widArgv, 1);
+        } else {
             addArguments (&argv[i], 1);
+        }
     }

     if (!nChildArgv)
@@ -698,7 +708,9 @@ int main(int argc, char **argv)

     XSync (display, window.window);

-    sprintf (widArg, "0x%x", (int) window.window);
+    snprintf(widArg, 255, "%s0x%x%s", pre_wid, (int) window.window, post_wid);
+    free(pre_wid);
+    free(post_wid);

     pid = fork ();

this literally took less time to write than your moaning probably took to write out, despite xwinwrap's incredibly shitty code. It replaces {WID} in an argument with the wid. Now give me money.

[leaty]

Defense and explaining myself after someone goes off on you is not moaning. While I neither asked for nor expected this, I am grateful.

[shmerl]

I noticed this change, and reading through this, checked interface-changes.rst which says:

Now, using the recommended syntax is required for options starting with --, which means an option value must be strictly passed after a =, instead of as separate argument.

I get the details of the change, but what exactly is the reason? Does such syntax improve something?

[CounterPillow]

Does such syntax improve something?

Yes, it makes passing something as an input unambiguous.

Previously, users would sometimes overwrite their input files if you told them to provide a --log-file because they'd do
mpv --log-file input.mp4.

[garoto]

It was a change for the better, can't understand all the hate.

--option value is lame and should be deprecated everywhere tbh.

[shmerl]

Easier to parse, sure. Horrible human readability though. So if anything, it's a trade off, not clearly change for the better.

[garoto]

Horrible human readability though [...]

Can't see how that can be the case.

[ghost]

The old syntax still works with single dash, so you can use that if you insist.

[avih]

--option value is lame and should be deprecated everywhere tbh.

Lame or not, the only standard for long options is gnu getopt, and it supports this syntax. Therefore by rejecting this standard syntax it makes mpv behave unexpectedly.

[shmerl]

Can't see how that can be the case.

That's easy to explain. Wall of text is always harder to read than text broken into words. Anyway, as I said it's a trade-off and if it helps parsing, then there is some point to it.