overlay:update() is ignored during pause events

[darsain]

• mpv 0.32.0-821-g38275338ee built on Sun Nov 22 17:00:03 +08 2020
• shinchiro
• Windows 10

Description

Assuming:

local ov = mp.create_osd_overlay('ass-events')

Updating the ov.data and calling ov:update() during pause event on windows will be ignored and not update the overlay.

Reproduction steps

I've isolated the bug into this script: https://0x0.st/i7mf.lua

It renders a pause indicator when playback is paused.

1. install the script
2. open any video on windows
3. spam pause

Most of the time, the indicator won't be rendered when video is paused.

In my tests, at least 40ms delay is needed before calling ov:update() for it to render consistently, but that might differ for others.

Log file

https://0x0.st/i7mW.txt

[avih]

Can reproduce with this smaller test case:

mp.observe_property("pause", "bool", function(n, v)
    mp.osd_message("pause: " .. (v and "yes" or "no"))
end)

It seems that when the ass overlay is updated from the pause observer right after it was changed from playing to paused doesn't get displayed.

However, if the display is further delayed by some ms, then it does seem to work, e.g.

mp.observe_property("pause", "bool", function(n, v)
    mp.add_timeout(50/1000, function()
        mp.osd_message("pause: " .. (v and "yes" or "no"))
    end)
end)

On my system I found out that a delay of 50ms (as above) seem to always work, while 10ms usually is not enough.

This does suggest a possible race condition in mpv when a request to update the ASS overlay happens right after/when mpv is entering paused state.

[avih]

@darsain can you confirm that you only see the issue when you try to update the overlay from the pause observer? or does it also fail to update from other triggers? for instance I tried to update it from a 500ms repeating interval timer, and it always worked.

[darsain]

I've not run into this in any other place yet, but I wasn't hunting for it either.

[avih]

Thanks, so for now we only know that it happens when trying to update the overlay right after/when the player gets paused.

[darsain]

According to tomasklaen/uosc#44 (comment) this might not be windows only.

[po5]

Following up on tomasklaen/uosc#44 (comment)
I do get both "pause: no" and "pause: yes", however "pause: yes" sometimes doesn't display.
Added a print() to pause.lua to make sure it was being registered and can confirm this is only an issue with the osd.
Strangely, with --no-config I could reproduce this much more easily. I think I've isolated it to SSimSuperRes.glsl, go figure.
Having that shader seems to mitigate the issue, but I may just be going crazy.

Attached are logs both with and without --no-config
issue8350-no-config.txt
issue8350.txt

[avih]

@po5 thanks. Does it get "fixed" if you use this instead at pause.lua?

mp.observe_property("pause", "bool", function(n, v)
    mp.add_timeout(100/1000, function()
        mp.osd_message("pause: " .. (v and "yes" or "no"))
    end)
end)

[po5]

It does "fix" it. Pausing no longer randomly skips "pause: yes", and there's only one case I've found where the message doesn't get displayed:
It's possible to make "pause: no" not display if, from a paused state, unpausing and pausing again really fast.
Certainly not as severe as before, because you pretty much have to try to even get that to happen.

[avih]

It's possible to make "pause: no" not display if, from a paused state, unpausing and pausing again really fast.

Is that with the additional 100/1000 delay? or with the original script?

[po5]

Dang, had the words "With this script" in the original edit but removed it for whatever reason.
This is with the updated 100/1000 delay script.

[avih]

:) thanks.

I don't know when it will be looked at, but I'm trying to collect useful info if someone tries to tackle it.

Obviously the additional delay is a workaround hack, but it also serves as an indication to the conditions which affect the issue.

Thanks again.