[mythtv] Re:Experimental pvr 350 output patch

[Mike]

I've been following this patch as it evolves and have been very pleased with
the improvements.  It seems there was (and, maybe, still is?) significant
potential to customise myth for the PVR-350.

With the latest version of the patch I also experienced "Waited too long for
decoder to pause" errors, however in my case these appeared only in Live TV
mode.  The problem would arise reliably on every attempt to pause, and would
lock the frontend in an infinite playback loop -- live TV continues, but all
further commands are ignored (including exit back to menu).  Meanwhile the
log is being filling with the "waited.." message.

A bit of investigation suggests that the frontend enters
IvtvDecoder::GetFrame() in ivtvdecoder.cpp, and never returns.

My reading of this patched function is that it loops, reading from the
ringbuffer and writing to the PVR for as long as data is available to be
read, and accepted by the PVR.  In theory when the PVR output buffer has
been filled, GetFrame() returns and the NuppelVideoPlayer continues its
processing in the outer loop.

It would appear that in my case, in Live TV mode, the PVR output is
consuming data faster than, or as fast as, GetFrame() is writing it.  Thus
the IvtvDecoder::GetFrame() loop executes indefinitely and control is never
returned to NuppelVideoPlayer.  I theorize that this only happens in Live TV
mode either due to the increased CPU load, or something related to the speed
at which data is read from the ringbuffer.  CPU speed (VIA EDEN here)
probably plays a role.

In any case, a simple counter on this loop which prevents it from executing
more than a certain number of times appears to solve the problem, and
ensures that control is always returned to NuppelVideoPlayer periodically so
it can do its work.  The NVP loop does not appear to block at any time, so
is there actually any need for the loop in GetFrame() at all?  I found no
obvious problems with removing it and allowing only one call to ReadWrite()
within a single call to GetFrame()

In any case, great work!  Hopefully this information will prove valuable in
some way.

Mike