[mythtv] [PATCH] Re: policy on using 'VERBOSE' in myth

[Geoffrey Hausheer]

On Fri, 29 Aug 2003 01:06:39 -0400, "Isaac Richards ijr-at-po.cwru.edu
|mythtv/1.0-Allow|" <e6kbhbk35r0t at sneakemail.com> said:
> On Wednesday 27 August 2003 05:55 pm, Geoffrey Hausheer wrote:
> > On Wed, 27 Aug 2003 17:30:58 -0400, "Isaac Richards ijr-at-po.cwru.edu
> >
> > |mythtv/1.0-Allow|" <e6kbhbk35r0t at sneakemail.com> said:
> > |
> > > On Wednesday 27 August 2003 05:23 pm, Geoffrey Hausheer wrote:
> > > > This isn't really an error (it may or may not generate loss of data). 
> > > > So I'm not sure why we want to report this by default.  Checking in the
> > > > encoder if this is causing real data loss would be the right place for
> > > > an error message, it seems to me.  specifically, I get this all the
> > > > time using the transcoder, since I can effectively feed it data at the
> > > > same rate that I read it, and blocking the write has no impact on the
> > > > output....This is why I had changed it to an info message with a
> > > > 'verbose' in my patch.  I'm cool with another solution, but I'd rather
> > > > not generate lots of these messages while transcoding.  Comments?
> > >
> > > That's something you'd want to know during normal playback/recording,
> > > however..
> >
> > Wouldn't that be a perfect use for VERBOSE(VB_IMPORTANT,...)?
> >
> > If nothing else, will you accept a patch that lets me disable these
> > messages either during the creatiion of the RingBuffer, or as a sperate
> > command?
> 
> Can't just redirect stderr?  That's probably be the best way to handle
> actual 
> error messages, as opposed to informational things..
Sure I could do that...hwever for mythtranscode the above message isn't
an error.  In fact it's not even useful as an info message.  If I
redirect stderr, I might miss real errors that i do care about.  Sure,
there are solutions to that too, but they're more messy than I want to
deal with.  In reality, I'm not sure how many errors can actually get
thrown during transcoding, so maybe I'll just add a '2>/dev/null' to the
call and call it done.  This is just one of those cases where blocking on
the RingBuffer isn't always an error, so I don't really agree with
treating it as one in all conditions.  but I don't care strongly enough
to continue debating it, so consider the issue resolved :)

.Geoff