Login at Kodi Home

**bossanova808** · 2014-11-27, 04:48

It would be handy if addon log lines were automatically prexifed with the addon name (& perhaps even file executing).

Of course many addon makes have implement their own log function but one could very quickly remove all lines with Addon: or whatever at the beginning to help sort the wheat from teh chaff in debu log browsing...

**takoi** · 2014-11-27, 14:03

Well, great news: some people are working on replacing the logging system with a proper one, which should hopefully allow for real log filtering. Would be a good opportunity to rethink the addon logging api as well. Smile

topfs2 · 2014-11-27, 15:53

https://github.com/topfs2/xbmc/tree/log4cplus

Sort of good news. I have kind of lost interest due to the negativity surrounding it.

**takoi** · 2014-11-27, 16:44

(2014-11-27, 15:53)topfs2 Wrote: https://github.com/topfs2/xbmc/tree/log4cplus

Sort of good news. I have kind of lost interest due to the negativity surrounding it.

Please don't lose interest! The current system is sucks, textbook example of how not to do logging. It's time to move on to something proper. Saw all the bikeshedding and just couldn't be bothered to get involved, but I can assure you the majority want this. Smile

**Memphiz** · (This post was last modified: 2014-11-27, 17:34 by Memphiz.)

This doesn't solve the problem you are describing here anyway. What we would need to do to solve it (which is pretty easy to do already i think) is to prefix all logs which come in from our python api with the addon id. This will lead to double printouts for addons which already do this. Log4*** doesn't change this fact imo. The question is - can we reach enough addon developers with this cosmetic, or will we be left with a bunch of non-maintained addons which simply will appear double prefixed in the log? (guess what i think we will end with...)

topfs2 · (This post was last modified: 2014-11-27, 18:02 by topfs2.)

(2014-11-27, 17:33)Memphiz Wrote: This doesn't solve the problem you are describing here anyway. What we would need to do to solve it (which is pretty easy to do already i think) is to prefix all logs which come in from our python api with the addon id. This will lead to double printouts for addons which already do this. Log4*** doesn't change this fact imo. The question is - can we reach enough addon developers with this cosmetic, or will we be left with a bunch of non-maintained addons which simply will appear double prefixed in the log? (guess what i think we will end with...)

With log4foo we could have an API were we prefix by addon id AND whatever the addon user wants. So they can have subloggings aswell. So it doesn't' necessarily solve it but it gives a crapload of power to the API for the addon logging

EDIT: With the assumption we don't share global space with the addons, as then it would be solved in binary addons atleast. IIRC I read something about the global space thing on log4cplus site somewhere.

Also with python they have a good logging tool, which coincidently mirrors log4java. So wouldn't be surprised if its easy to map to that one (or just use that one preconfigured)

**takoi** · 2014-11-27, 18:06

(2014-11-27, 17:33)Memphiz Wrote: This doesn't solve the problem you are describing here anyway. What we would need to do to solve it (which is pretty easy to do already i think) is to prefix all logs which come in from our python api with the addon id. This will lead to double printouts for addons which already do this. Log4*** doesn't change this fact imo. The question is - can we reach enough addon developers with this cosmetic, or will we be left with a bunch of non-maintained addons which simply will appear double prefixed in the log? (guess what i think we will end with...)

With log4* you don't need to prefix anything. That's the point.. With that in place, the existing addons can use a shared legacy logger, and we could make a new api for addons get their own for instance.