Mpv: Is it possible to use cycle-values in a script-message?

[UserNaem]

I tried this:
v script-message osc-visibility cycle
It works, cycling between auto, always and never. But I want to only cycle between auto and never. I tried these:
b cycle-values "script-message osc-visibility" "auto" "never"
Got this error: Unknown property: 'script-message osc-visibility'
b script-message osc-visibility cycle-values "auto" "never"
Got this error: [osc] Ignoring unknown visibility mode 'cycle-values'

I saw a mention of "input sections" in the manual, but I can't think of a way to make them overwrite each other.

[avih]

That's unsupported currently. The only supported values for script-message osc-visibility are always/never/auto/cycle .

You could however write a small script which does it for you. E.g. save this code at a file osc-custom-cycle.lua and put it in your mpv scripts dir:

local is_auto = true  -- no way to read the osc mode, so we assume it starts in auto mode.
mp.add_key_binding("b", "osc-cycle-never-auto", function()
    is_auto = not is_auto
    mp.command("script-message osc-visibility " .. (is_auto and "auto" or "never"))
end)

This will bind it to b so no need for anything else in input.conf. But, you can still bind b to something else at input.conf and bind this custom cycle to something else, e.g.
v script-binding osc-cycle-never-auto
or
v script-message osc-cycle-never-auto
Where both will trigger this custom cycle even if b is bound to something else at input.conf.

Note that because it's impossible to read the OSC mode, this will not be in sync if you modify osc visibility via other means (e.g. by pressing DEL). But this is minor, as this custom cycle will still switch between these two modes.

It's unlikely that the OSC itself will support such custom cycles due to its internal complexity, but this script should be enough for your needs.

Shall we close this issue?

[UserNaem]

It randomly does something like this:

[   7.217][w][osc] 
[   7.217][w][osc] stack traceback:
[   7.218][w][osc]  mp.defaults:128: in function 'set_mouse_area'
[   7.218][w][osc]  @osc.lua:134: in function 'set_virt_mouse_area'
[   7.218][w][osc]  @osc.lua:2042: in function 'render'
[   7.219][w][osc]  @osc.lua:1897: in function 'hide_osc'
[   7.219][w][osc]  @osc.lua:2072: in function 'render'
[   7.219][w][osc]  @osc.lua:1897: in function 'hide_osc'
[   7.219][w][osc]  @osc.lua:2072: in function 'render'
[   7.220][w][osc]  @osc.lua:1897: in function 'hide_osc'
[   7.220][w][osc]  @osc.lua:2072: in function 'render'
[   7.220][w][osc]  ...
[   7.221][w][osc]  @osc.lua:2072: in function 'render'
[   7.221][w][osc]  @osc.lua:1897: in function 'hide_osc'
[   7.221][w][osc]  @osc.lua:2239: in function 'enable_osc'
[   7.222][w][osc]  @osc.lua:2346: in function 'handler'
[   7.222][w][osc]  mp.defaults:339: in function 'handler'
[   7.222][w][osc]  mp.defaults:458: in function 'call_event_handlers'
[   7.223][w][osc]  mp.defaults:495: in function 'dispatch_events'
[   7.223][w][osc]  mp.defaults:451: in function <mp.defaults:450>
[   7.223][w][osc]  [C]: at 0x013ffe2030
[   7.224][w][osc]  [C]: at 0x013ffe1630
[   7.224][f][osc] Lua error: stack overflow
[   7.225][v][osc] Exiting...

Apparently osc.lua doesn't like it when its visibility modes aren't cycled the way it expects them to cycle, and breaks randomly. I appreciate the effort, though.

Shall we close this issue?

Not sure.

[avih]

Apparently osc.lua doesn't like it when its visibility modes aren't cycled the way it expects them to cycle, and breaks randomly.

This shouldn't be the case, and if it is then it's an mpv bug. Which mpv version are you using?

Also CC @wiiaboo just in case.

[UserNaem]

0.27.0 on Windows 7 SP1.
Here's a log file if it can help: https://pastebin.com/mLE0hxv7

To add: just pressing\mashing the script's keybinding won't break anything, add some random mouse movements and other keyboard inputs to reproduce the breakage.

[avih]

Well, I cannot reproduce it. I tried with this exact script, (without binding at input.conf so it's b from the script itself), both with and without a video. I kept moving the mouse while pressing b very quickly repeatedly, and it just seems to work.

If you have a more specific description how to reproduce it somewhat reliably, I can try again. Or maybe someone else is able to reproduce it?

Regardless though, the OSC should be (and I believe is) oblivious to the modes order. The approach with the script above is probably the closest to get what you want.

The script crash issue is important, but unrelated. It should work as advertised as as designed.

[avih]

It's unlikely that the OSC itself will support such custom cycles due to its internal complexity

This could be related vaguely. The OSC is a delicate piece of code, with some race conditions fixed over the years, and some more are still there probably. We can probably fix some if we can reproduce an issue, but to do that we'd need a relatively reliable way to reproduce it, and right now I'm unable to.

It might still be possible to track the issue by your stack trace, but a better way to reproduce is still preferred.

[UserNaem]

I renamed input.conf and mpv.conf to input.conf0 and mpv.conf0 to avoid them being loaded and potentially changing the outcome.

Reproduction steps

cmd
C:\Users\user>mpv --v --log-file=out.txt --force-window --idle (make sure the mouse is out of the place where mpv window will spawn)
Hit b four times
Move mouse inside the mpv window
Move mouse out of the mpv window
Hit b another four times
Got the stack overflow error. At this point, hitting q will quit mpv and will be reflected in the cmd window, but won't output anything to the log-file.

[UserNaem]

Almost forgot the log. https://pastebin.com/1TzAaDN2

[avih]

make sure the mouse is out of the place where mpv window will spawn
Hit b four times
Move mouse inside the mpv window
Move mouse out of the mpv window
Hit b another four times

Thanks. I could reproduce it. Not 100% of the attempts, but at least it does happen sometimes.

Initially I thought it's related to the idle mode (where there's no OSC), but it also happened with a video clip.

I'll try to look into it.

One interesting thing I noticed, is that moving the mouse onto the mpv window for the first time didn't always generate the same output (-v). Sometimes it had more output, and on these cases subsequent b presses triggered the issue.

[avih]

[ 7.217][w][osc] [ 7.217][w][osc] stack traceback: [ 7.218][w][osc] mp.defaults:128: in function 'set_mouse_area'
...

I can see the recursion at the code, but not sure which combination of states triggers it. I can also work around it with the following hacky patch:

diff --git a/player/lua/osc.lua b/player/lua/osc.lua
index e4faf6c0cc..1291928d42 100644
--- a/player/lua/osc.lua
+++ b/player/lua/osc.lua
@@ -1887,7 +1887,11 @@ function show_osc()
     end
 end

+local hiding_in_progress = false
 function hide_osc()
+    if hiding_in_progress then return end;
+    hiding_in_progress = true;
+
     msg.debug("hide_osc")
     if not state.enabled then
         -- typically hide happens at render() from tick(), but now tick() is
@@ -1903,6 +1907,8 @@ function hide_osc()
     else
         osc_visible(false)
     end
+
+    hiding_in_progress = false;
 end

 function osc_visible(visible)

I don't like this patch, but it does seem to work...

[UserNaem]

I'm not a developer, this looks like magic to me.
I think I'll settle with this for now:

v set osd-level 0; script-message osc-visibility never
V set osd-level 1; script-message osc-visibility auto

Not as convenient as using one key without modifiers, but it'll do. I hope a more convenient solution will become available in the future without lua magic. Thanks again.

[avih]

... Not as convenient as using one key without modifiers, but it'll do.

No. It has the same issue of the stack overflow. Just use v V v V instead of the 4x b in your error steps. I did, and got the same lua error.

As I said, the issue is not related to doing it from a script or not. The issue is in the OSC not handling some states correctly.

[UserNaem]

That's kind of bad. Fortunately, in my use case I won't need to re-enable the on-screen things after turning them off.
Then how about send several cycle messages? Cycling doesn't seem to break. Ideally I'd like a keybinding that changes its own function on press, like commandline aliases-within-aliases, but the manual doesn't make it clear on how it can be done (if at all) without lua magic.

...Or wait for it to be changed eventually. I believe the developers have more important things to look into, such as un-breaking hardware VP9 acceleration.

[avih]

Let's distinguish between two subjects:

1. You want to cycle the OSC between never and auto. The script I posted does it. Your v and V key bindings do it too. So that's done. I'm closing this issue.

2. An OSC bug where sometimes changing visibility mode results in a lua error. It doesn't matter if it's from a script or from direct input.conf key bindings. I've opened issue #4900 for it. Feel free to subscribe to it.

[avih]

The fix was pushed to master. @UserNaem please confirm it doesn't have the stack overflow issue anymore (if you don't build mpv yourself, then wait till it's available as binary download).