[mythtv] [Patch] Logging to database PLUS automatic mythfilldatabase

[Matt White]

Joseph A. Caputo wrote:
> Nice work... I'm glad to see you've incorporated the log flushing into 
> the backend.  However, I'm still concerned.  I've had my /var partition 
> fill up very quickly in the past when something went wonky on the 
> backend.  The problem is/was that a condition occurred that caused the 
> backend to spit out a seemingly infinite stream of errors that filled 
> several gigs before I caught it.  When something happens that causes 
> that kind of log activity, an age-based log expiration algorithm is 
> insufficient.  I'd really like to see a limit on the *number* of total 
> log entries allowed in the table.  Also, it would probably help to have 
> a mechanism to filter out repetitive log entries, like so (warning: 
> crude hack follows, but you'll get the idea):

[snip fixed code]

Fantastic idea!  I haven't had a runaway like that with myth for quite
a while, so I hadn't thought of that.  I've added your code - it pretty
much worked out of the box :-)  I've also added two things that I forgot
to add to globalsettings.cpp in mythfrontend for the log flush routine -
maximum age of acknowledged messages to keep, and maximum age of all
messages to keep.

I'm just going to do some testing here to make sure that the logging
stuff doesn't do anything I don't expect, and then I'll post another
diff.

While I'm testing, I'd like some opinions on another idea, from a
discussion with Mark Edwards (thanks, Mark).  I'm thinking of adding
another config item ("Print logged messages higher than this priority")
and a bit of code in the log function to print the module and message
for matching events to stdout as well as logging them.

That would give us a single logging function that could output both
to the database and optionally to stdout.  The VERBOSE macro is
probably still important for debugging stuff, but this way you wouldn't
need two calls where you want to log to both the database and stdout.
It would also give the advantage of applying Joseph's "no multiple
message" logic to printed messages as well.

Thoughts?

-- 
Matt White                          whitem at arts.usask.ca
Arts and Science Computer Labs      University of Saskatchewan