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

Add new logging infrastructure #199

Merged
merged 1 commit into from
May 8, 2019
Merged

Conversation

dagwieers
Copy link
Collaborator

@dagwieers dagwieers commented May 8, 2019

This PR includes:

  • A predefined set of log_levels: Quiet, Info, Verbose, Debug
  • Default log_level is 'Info'
  • Log all HTTP requests as Verbose
  • Log all invocations as Verbose

This is only the first step of a set of troubleshooting improvements.

@dagwieers dagwieers added the enhancement New feature or request label May 8, 2019
@dagwieers dagwieers added this to the v2.0.0 milestone May 8, 2019
@dagwieers dagwieers force-pushed the logging branch 2 times, most recently from a6dde2e to 1b150b1 Compare May 8, 2019 17:29
This PR includes:
- A predefined set of log_levels: Quiet, Info, Verbose, Debug
- Default log_level is 'Info'
@pietje666
Copy link
Collaborator

I do not really see how it is working, could you explain a bit more please

@dagwieers
Copy link
Collaborator Author

It's not completely where I want this to go, but you can select Quiet|Info|Verbose|Debug in the settings, and this influences what is being logged. When using 'Info' you get the same logging as currently.

When set to 'Quiet', we don't log anything. When set to 'Verbose' you log every HTTP request and plugin invocation. When set to 'Debug' I plan to add a lot more things to be happening, potentially OSD information or notifications, a separate file with all played streams, a dump of the latest stream information, etc.

The idea is that with 'Debug' a user understands how the addon works roughly and can troubleshoot issues herself. That will be part of the unfinished 'Troubleshooting' section in the Wiki.

@dagwieers
Copy link
Collaborator Author

Ah, and obviously we also need to take into account the Kodi log_level. So if you put the Kodi log_level to 'Debug', this affects the Addon logging as well.

@pietje666
Copy link
Collaborator

I would just log using the default kodi loglevels, despite any addon setting. Also you look at it from your view as a developer but i think only a very small fraction of the users will use it

@dagwieers
Copy link
Collaborator Author

@pietje666 Of course only a very small set of our users will be interested in this, but it's that group of users we want to understand what's going on and do great things with the stuff they learn. I don't want to have an addon that we have to keep on developing because people have no clue what's going on (or they need to be experienced/skilled in order to learn how things work). So I think this is critical for a good developer community that contribute amazing things.

The reason why only having the Kodi log_level, is that the stuff from the addon you are interested in will get lost with the stuff coming from Kodi potentially. So if people have a need to understand how the addon works, they do not have a need to find that in the inner workings of Kodi, that's a whole different ball game.

@dagwieers
Copy link
Collaborator Author

Let's see where this goes. We can change it, or improve it before we release this to the public.

@dagwieers dagwieers merged commit f2c4551 into add-ons:master May 8, 2019
@dagwieers dagwieers modified the milestones: v2.0.0, v1.10.0 May 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants