[mythtv] Patch proposal for better logging of ivtv select timeouts

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

I'd like to propose changing this line in libs/libmythtv/mpegrecorder.cpp:

  printf("select timeout - ivtv driver has stopped responding\n");

to something like

  printf("%s select timeout - ivtv driver has stopped responding\n", videodevice.ascii());

If I opened a ticket and generated a patch for this, would it be
likely to be accepted?

Rationale:
   
If the ivtv driver stops providing data, there's code in current SVN
that will close & reopen the device, and that code emits the logging
line above.  (The recording will contain an unavoidable glitch when
this happens, whose worst case looks like 5 seconds plus however long
it takes ivtv to start supplying video again.)  But the log doesn't
say which encoder got the fault, which has two drawbacks:

o  If one encoder is more likely to do this than another (perhaps
   because it's going bad or running too hot?  I don't know how
   well-characterized this behavior is), then knowing which one is
   being problematic can help in deciding whether to throw it away, or
   use it for lower-priority recordings, or only LiveTV, or whatever.
o  I'm currently working on a tool (which of course I'll make
   available once it's ready) that monitors ongoing and just-completed
   recordings for a large variety of faults (some originating with the
   recorder, such as this one, and some originating with the studio or
   feed, such as black/missing/snowy video, EAS break-ins, etc).  The
   intent is for the tool to immediately attempt to reschedule any
   faulty recording, since very often there may be an immediate repeat
   (often FX) or within 2-3 hours later that evening (PBS, Discovery,
   History Channel, etc)---and then not again for months, if ever.
   Waiting for a human to notice a bad recording thus means that by
   the time it's noticed, the chance to rerecord a better copy has
   evaporated.  And unless the device is known, it's impossible for
   the automation to know -which- recording got glitched if multiple
   tuners are in use.  (It would be even better to know the actual
   encoder in use, but that would be much more complicated and I don't
   recommend putting it in this patch; the automation could instead
   look the information up in the database in some entirely separate
   process from the currently-recording backend, since its next step
   is to interact with the database & scheduler anyway.)

And if anyone would like to test the line above in their setup
(especially if you've seen this error before), I'd be grateful,
since it seems relatively rare for me but others have complained
about it happening fairly frequently.

Thanks!

P.S.  Is it intentional that the printf is completely unconditionalized
by the logging level, and goes to stdout and not stderr, or am I
misunderstanding what's going on here?