[mythtv-users] Tracking which encoder shows record on.

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Fri Sep 11 18:22:06 UTC 2009


This seems to come up on the list every month or two.  It's been an
issue for me, too, and having to grovel back through logs for it is
inconvenient.  (It means you might have to keep the logs as long as
the recording, at least, and it also means you have to -have- the
logs, which many users do not.)

I've asked about this before, but haven't gotten a clear answer---is
not storing the encoder id in recorded/oldrecorded a policy decision,
or would a patch to do so simply be incorporated?  It seems like it
would add a trivial amount of space to the DB for a large increase in
all kinds of retrospective debugging ability and (especially) perhaps
the ability to have automation notice that one particular encoder is
having issues and warn the user.

After all, adding a smallint to the DB consumes negligible amounts of
space and only a few machine cycles to populate it, but can really
improve the situation when debugging.  Deliberately fumbling the
information away when you had it, only to make the user recreate it
(if they even had the right kind of logging in the first place) seems
silly.  It's exactly the same reason JTAG exists---sure, it adds a few
transistors to the die, but it's worth it.  [This is, btw, the same
sort of rationale for why I wrote trac #6898 (don't confuse with
6899!)---don't toss information that can be very useful if it's
trivial to keep it around and it consumes negligible space.]

And I'll say it again---not everyone keeps logs, or keeps them
forever, and sometimes you don't see a problem until weeks later when
you actually -watch- the recording, by which point a log might be
gone.  Even if you keep everything forever, it can be a -lot- of work
to grep back through a bunch of logs and pull all this info out,
correlated to failures and encoders, when a MySQL statement could
otherwise have answered the question in five seconds.  And it really
raises the bar on user-written automation to detect things going bad,
which might otherwise, again, just ask the DB directly.

P.S.  Yes, yes, if you rearrange your inputs, you've invalidated the
stored data.  I contend that this corner case is no reason to ensure
lossage for people who -don't- rearrange their inputs or for people
who rearrange them but keep notes about when they did so.  Ditto re
udev vs kernel loading order---presumably if the data was valid in the
log, it's valid in the DB, and depriving the DB of it when it's valid
seems pointless.  (As does saying, "grep it out of the log" if the log
would be wrong for the same reason.  Those people for whom it's right
or who can make it right could find it very handy to have.  Not all of
us have things load in nondeterministic order.)


More information about the mythtv-users mailing list