libmpv is very hard to work with

Expected behavior of the wanted feature

Hi, I'm currently developing a player frontend using libmpv, and I'm facing a lot of problems, because of how the api is designed, particularly that the synchronous calls (even simple property read and writes) can block thread for arbitrary amount of time (in practice can be up to 500ms).

One example is that when you implement a seeable progress bar, you cannot just call mpv_command(['seek', ...]) in the UI thread, because this call doesn't always complete immediately, so instead you have to do mpv_command_async(.... But because the UI progress bar position needs to update instantly after being pressed (for the UI to feel responsive) and because mpv_command_async doesn't update the property instantly, I have to create my own copy of player state (which I can update without any delay) and try to mirror the actual player state via MPV_EVENT_PROPERTY_CHANGE. This even on its own is already bad, because it makes the program more fragile, because the 2 states can get out of sync if something unexpected happens.

But even worse part is that there is no easy way to know whenever a particular event was produced before or after a call to mpv_command_async, this creaes teribble race conditions, e.g.:

1. User presses the progress bar, the position (of my copy of the state) is now 10:00:00, mpv_command_async(['seek', ...] is called
2. MPV_EVENT_PROPERTY_CHANGE event is processed, which in fact took place before the seek started, so the position reverts back to where it was before the seek, e.g. 12:00:12, which is incorrect behaviour
3. Only now there is another MPV_EVENT_PROPERTY_CHANGE with value of 10:00:00

I know there are some workarounds, that can be done, to mitigate these issues, however they too cause risk of incorrect behaviour in case the state would get corrupted for some reason and introduce unncecesary complexity.

I think the DOM video API is a good example of how this should work, if you call video.currentTime = 12371 the state is updated to the new value instantly (even if the player hasn't actually completed the seek yet), if one needs to know when the seek actually finishes then he can listen to seeked event. But more importantly, no timeupdate event will fire for playback progression that happened before this call was made.

So my suggestion would be, to make mpv_get_property(), mpv_set_property() and the majority of commands (like seek) complete immediately and just signal if needed a more detailed completion timing through events.

Alternative behavior of the wanted feature

No response

Log File

No response

Sample Files

No response

Start by reviewing the libmpv API entry points named in the issue: mpv_get_property(), mpv_set_property(), mpv_command(), and mpv_command_async(). Trace how synchronous calls, asynchronous commands, and MPV_EVENT_PROPERTY_CHANGE are ordered, then define the scope and compatibility requirements for immediate state updates and completion timing. Done should include a decided API design and tests covering seek and property-event ordering.