[removed151214]

This is one of those ideas where I'm sure I'm missing something so obvious, I'm going to be apologising profusely for days for having overlooked why it's such an idiotic idea but ... why isn't debug logging (that is to say, always producing a full xbmc.log file) just enabled by default?

It seems like this file is only ever accessed by users when there is actually an issue - where the full debug log is therefore useful (and in several cases, of someone who doesn't have to look at these logs too often, not enabled properly by the user). In other cases, it doesn't seem like it makes any issue whether a full debug log is being captured or not. And in those cases where it is, the need for the end users to manually enable debug logging would be removed, increasing the chances that a full debug log would actually be provided.

As I say, I'm sure I'm missing something obvious, so my apologies are on standby.

[nickr]

They can get very big very quickly. Some smaller devices might choke. Just think how big it gets if you leave xbmc on for 6 months...

[removed151214]

That'll be the one, and may I say straight away: my apologies for having such a stupid idea

Though, actually thinking about this some more, and I get that I'm going to have to apologise even more. When someone provides a debug log, they don't provide a six-month debug log. They (generally) provide a log where the issue has been reproduced after reboot. So a situation where the debug log is enabled by default, it then gets disabled if the system appears stable - based on being running for (for example) an hour plus?

(taking into account that scripts can actually check for and enable debug logging (with relatively recent json changes) - I actually have a script on the repo that does just this - so, assuming full debug for an hour (or even half an hour), initial startup would always be captured and the user has plenty of time to reproduce any errors. Then the system would automatically reduce debug logging. Either the script enables debug logging on error (as script.skinshortcuts does on menu build failure, before offering to upload it with script.xbmc.log.uploader - though one user has still been unable to link to a largely auto-generated and completely auto-uploaded debug log, which annoys me and confuses me in equal measure), or the user later reproduces the error on a reboot without having to enable debug logging when they do.)

[nickr]

Those are promising ideas. don't forget there are now debugging levels too, and some addons have their own debug settings.

[MassIV]

Just think how big it gets if you leave xbmc on for 6 months...

Are there reasons for 6 months of continuous log recording?
What are arguments against starting a new file every x days?
3 days of logging + 3 days of old log should be able to catch any event you are looking for i'd think.

[levi.baker88]

I know I'm thread digging a little, but saves making a new thread on the same topic.

Just wanted to bring this to the surface again, it was mainly after I watched the KordKutters episode on the DevCon last year and how there are minimal people doing testing during alpha phases and only a little more during beta phases and so on and of those an even smaller amount that submit debug logs and the other issue of debug log management.

I feel that for a general user the effort and process of actually submitting a debug log to try and better Kodi could seem somewhat tedious and a solution to this could be to somehow integrate background logging and then have a pop up when an error occurs with submit report (you get the idea). There is other software out there that currently does this so it isn't a foreign concept and could be a cross-platform feature, also submitting a report to a central location (?) would also solve the management issue. 2c.

[zag]

We certainly as a team have discussed this in the past. The auto log uploader add-on is a good compromise but I agree creating and uploading a log file at the moment is hard for the normal user.

Anything that makes that process a little easier would be welcome.

[robwebset]

Interesting - but for my addons, I don't think you'd want logging on my default - it would chuck out a lot of data - and make it a lot harder for other users trying to debug their problems, as my logging would be all over the place. This is why I always have an enable/debug option in the addon settings for logging.

However one thing that may be possible (From an addon error support point of view) would be to detect when there is a python script error and grab the log at that point - parse it to find the addon causing the error - and post that log somewhere for them?

I think this could be very useful for the addons in the official repo, would certainly improve quality!

Thanks

Rob