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

browser-client: Downgrade browser console log levels #440

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

tt2468
Copy link
Member

@tt2468 tt2468 commented Apr 12, 2024

Description

Downgrades browser console log messages:

  • Error: LOG_WARNING -> LOG_DEBUG
  • Fatal: LOG_ERROR -> LOG_INFO

Motivation and Context

Throughout time, OBS has logged browser console.log errors as warnings in the OBS log as an easy way for browser source developers to find and fix issues with their pages. Unfortunately, this functionality seems to be almost completely ignored by many browser source providers. This logging does, however, clog up many OBS logs and result in readability issues when troubleshooting unrelated problems.

How Has This Been Tested?

No more log spam in my OBS log from random browser pages

Types of changes

  • Tweak (non-breaking change to improve existing functionality)

Checklist:

  • My code has been run through clang-format.
  • I have read the contributing document.
  • My code is not on the master branch.
  • The code has been tested.
  • All commit messages are properly formatted and commits squashed where appropriate.
  • I have included updates to all appropriate documentation.

Throughout time, OBS has logged browser console.log errors as warnings
in the OBS log as an easy way for browser source developers to
find and fix issues with their pages. Unfortunately, this functionality
seems to be almost completely ignored by many browser source providers.
This logging does, however, clog up many OBS logs and result in
readability issues when troubleshooting unrelated problems.
@Warchamp7
Copy link
Member

Warchamp7 commented Apr 12, 2024

Generally fine with this, but I think there would be value in another PR that added a summarized report to the log when a browser source is reloaded or destroyed, just so that this information isn't totally shoved under the rug.

Ex.

09:57:22.112: [obs-browser: 'Example Page'] Page reported 11 warnings and 24 errors. Enable verbose logging for detailed reporting.

@alinsavix
Copy link

Is it worth considering having an option on the browser source to enable/disable this feature? I support a few streamers where sometimes I have to come in after-the-fact and figure out from the logs why something was misbehaving, and there have definitely been a few times where the logging from the browser sources let me do that -- so for those streamers, having the existing behavior is really valuable, and I could just have those streamers leave that value set appropriately, and I personally am willing to wade through the normal browser source spam to be able to have it there when I actually need it.

@Fenrirthviti
Copy link
Member

From off-thread discussions, I'd be far more in favor of just moving browser messages to a separate file and leaving everything else as-is.

Understandably, this comes with a different set of challenges for things like handling log uploads and such, but I personally feel that this has been such a pain to try and shove in the main OBS log for a long time now, and it's time to just separate it.

@WizardCM
Copy link
Member

@Fenrirthviti This is possible here:

settings.log_severity = LOGSEVERITY_DISABLE;
BPtr<char> log_path = obs_module_config_path("debug.log");

LOGSEVERITY_DISABLE would need to be changed to LOGSEVERITY_WARNING, and we'd probably want to give it a nicer filename than debug.log (stored in the same location as the cookie directories).

@Fenrirthviti
Copy link
Member

Sure, that part is easy, the concern would be adding a new option to upload the browser log file for support purposes. We do far less sanitization on browser logging than we do our own logging, so uploading that to us would make me slightly nervous from a privacy standpoint, but it's just shunting what we're already logging/uploading as part of the main log anyway, so it should be fine. We should have a warning on upload or something, but that can be discussed off-thread here.

As I'm against this specific PR as a solution, I'm voting in favor of closing this and moving the logging/uploading to a separate file.

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

Successfully merging this pull request may close these issues.

5 participants