I've also noticed that. I think the problem is that when the inhibit is active it doesn't stop the idle timer. The timer still trigger listeners, but listeners won't fire on-timeout actions due to the inhibit being active.
So if you have 5 minutes timeout set and watch the video without touching anything for 6 minutes, then the 5 minutes timeout will trigger but won't execute. When the video finishes and the inhibit is released, the timer doesn't reset and is still going forward.
This can also have some other consequences. For example if you have one listener with 5 minut timeout and another one with 6 minute timeout and the video finishes between them, then hypridle won't execute actions for 5 minutes timeout, but will execute ones for 6 minutes one.
I've also noticed that. I think the problem is that when the inhibit is active it doesn't stop the idle timer. The timer still trigger listeners, but listeners won't fire
on-timeoutactions due to the inhibit being active.So if you have 5 minutes timeout set and watch the video without touching anything for 6 minutes, then the 5 minutes timeout will trigger but won't execute. When the video finishes and the inhibit is released, the timer doesn't reset and is still going forward.
This can also have some other consequences. For example if you have one listener with 5 minut timeout and another one with 6 minute timeout and the video finishes between them, then hypridle won't execute actions for 5 minutes timeout, but will execute ones for 6 minutes one.
The problem I see is that the timeouts themselves are triggered by the hyprland (or wayland compositor in general) using https://wayland.app/protocols/ext-idle-notify-v1.
I see two probable ways to fix this. When hypridle receives dbus/systemd inhibit request, the it could do one of these: