Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

player/client: reduce log level for hooks not sent to clients #15245

Merged
merged 1 commit into from
Nov 3, 2024

Conversation

guidocella
Copy link
Contributor

If a script registers hooks before exiting mpv logs "Sending hook command failed. Removing hook.". (Also there is no function to unregister hooks.) Don't register hooks in auto_profiles.lua before it exits to not log these warnings. Fixes 5dc4047. Fixes #15244.

@guidocella guidocella changed the title auto_profiles.lua: don't log warningh on exit auto_profiles.lua: don't log warnings on exit Nov 2, 2024
Copy link

github-actions bot commented Nov 2, 2024

Download the artifacts for this pull request:

Windows
macOS

player/command.c Outdated
mp_wakeup_core(mpctx); // repeat next iteration to finish
if (mp_client_id_exists(mpctx, h->client_id)) {
MP_VERBOSE(mpctx, "Sending hook command failed. Removing hook.\n");
hook_remove(mpctx, h);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is mp_wakeup_core removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was in the wrong block, I just moved it in below, I have no idea if it needs to run in both cases.

player/command.c Outdated
MP_VERBOSE(mpctx, "Sending hook command failed. Removing hook.\n");
hook_remove(mpctx, h);
} else {
MP_WARN(mpctx, "Sending hook command failed.\n");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the hook removal should be kept, because it results in behavior change if the hook isn't removed. This would break clients which unknowingly assumes that they can take longer time to process the hooks and not blocking the player because the player will eventually unblock itself due to hook removal.

The same is also done on other software, for example Windows which silently removes low level hooks if the clients don't respond in time.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can indeed remove hooks, I think it is clients fault anyway. But could we document this behavior? That hooks are removed on any and all errors?

Also it is kinda tricky, because client doesn't have a way to know if the hooks has been removed, so it might left script in unusable state, as the hooks are not one-shoot events.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed only the log level now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also it is kinda tricky, because client doesn't have a way to know if the hooks has been removed, so it might left script in unusable state,

Funnily, this is also exactly what happens when windows stops sending hooks to apps it thinks misbehave. So mpv is not the first to do that kind of thing.

I think both approaches are valid, but hooks specifically are synchronous and would definitely hurt mpv if not handled on time, so there's a bigger incentive here to break abusing clients.

@guidocella guidocella force-pushed the auto-profiles-hook branch 2 times, most recently from b9d2993 to 1f91242 Compare November 3, 2024 00:25
@avih
Copy link
Member

avih commented Nov 3, 2024

Commit "player/client: reduce log level for hooks not sent to clients" LGTM.

No comment on the autoprofiles commit.

@na-na-hi
Copy link
Contributor

na-na-hi commented Nov 3, 2024

The autoprofile commit shouldn't be needed anymore since script exiting removing hooks is expected behavior, and there are no longer logs at the default level. Scripts shouldn't need to do anything special about the hooks if they want to exit() at any time.

@avih
Copy link
Member

avih commented Nov 3, 2024

"Fixes #15244" should probably be moved to the C commit.

The autoprofile commit shouldn't be needed anymore

I prefer to stay out of autoprofiles, but I think the same.

@guidocella guidocella changed the title auto_profiles.lua: don't log warnings on exit player/client: reduce log level for hooks not sent to clients Nov 3, 2024
If a hook event can't be sent to a client because it no longer exists,
stop logging it as a warning, as there is no way for a client to remove
hooks, so it is expected that the hook can't be sent. This is documented
in libmpv/client.h.

If the hook event can't be sent for other reasons, like the event queue
being full (currently the only other possible reason), keep logging as
warning.

Also add the client and hook type to the message. They are also logged
just above, but only in verbose mode, so when only the warning is logged
you didn't see the client before.

auto_profiles.lua logs these warning since 5dc4047, and this commit
fixes that.

Fixes mpv-player#15244.
@avih
Copy link
Member

avih commented Nov 3, 2024

Thanks for adding the client/hook names to the message. This can be helpful.

The message format change is also OK (I would have only added : client/hook to the original form, but the new form is also OK).

LGTM. I'll merge it a bit later unless there are further comments.

@avih avih merged commit a61518d into mpv-player:master Nov 3, 2024
25 checks passed
@guidocella guidocella deleted the auto-profiles-hook branch November 3, 2024 18:04
@avih
Copy link
Member

avih commented Nov 3, 2024

Thanks.

@na-na-hi thanks for the approach in #15246 which this PR eventualy took.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
4 participants