[mythtv-users] tv_grab_zz_sdjson returning zero-length files

[f-myth-users at media.mit.edu]

    > Date: Wed, 28 Dec 2022 09:52:28 +0000
    > From: Mike Perkins <mikep at randomtraveller.org.uk>

    > Just a note to say, if you do add ",xmltv" to your logging the log files could
    > become extremely large, depending on what changes are being made to schedules.

    > Make sure you have enough logging space!

I'll keep an eye on it.  So far, adding that only added 20 or so lines
to mythfilldatabase.log, but I'll watch it run for a day or so and
ensure that.  If it gets huge, I'll turn it off again.  (And if that's
true, then it's quite unfortunate that detailed-enough logging to catch
simple grabber errors like "DB locked" will generate so much output that
such logging can't be left on by default; seems there should be an
intermedaite solution.)

    > Also, you point up a general rule: never, ever, run anything mythtv related except as the mythtv 
    > user. The number of problems caused by running as, say, yourself or root, are legion.

Yeah.  It would not have occurred to me that -anything- which touches
sqlite, even a read-only query, might leave extra files sitting around
in the DB dir owned by the user and which would then get in the way of
other use.  I'm guessing that sqlite3 aborted in some way (for no reason
I can see, and with no diagnostic) and didn't clean up those files, but
still, its behavior in this situation was extremely poor---not only not
warning about them in normal use and instead declaring the DB locked,
but also infinite-looping when I tried to back it up.  It's also
unfortunate that MFDB doesn't handle an aborted grabber better and give
a more informative error message, since it papered over the underlying
error and just complained that the grabber's output file was empty---
the grabber returning an error code should have caused MFDB to abort
immediately, propagating the error, instead of acting like nothing was
wrong and then instead complaining about the empty file.  Correctly
propagating the error would have had me looking at the grabber first
thing, instead of assuming it was a temporary server issue, especially
given that default logging didn't show the error.