[mythtv] Changeset 9265: Rebuffering from mythcommflag

Michael T. Dean mtdean at thirdcontact.com
Sun Mar 12 20:16:08 UTC 2006


On 03/12/2006 02:58 PM, Robert Johnston wrote:

>On 3/12/06, John P Poet <jppoet at gmail.com> wrote:
>  
>
>>I noticed that I am getting a LOT of rebuffering message in my log:
>>
>>2006-03-12 12:20:38.833 rebuffering (16385 32768)
>>
>>
>>I upped the requiredBuffer to 60, and those messages went away.
>>
>Is this from comm flagging?
>

Yep.  Recent changes have modified the lag-behind to try to get it 
closer to real-time.  [9176] ( http://svn.mythtv.org/trac/changeset/9176 
) made it stay 30 seconds behind, [9237] ( 
http://svn.mythtv.org/trac/changeset/9237 ) made it 3 seconds behind, 
and [9265] ( http://svn.mythtv.org/trac/changeset/9265 ) made it stay 7 
seconds behind.

> I am getting this a lot from my frontend
>in regular playback, but there is no discernable glitch in playback
>(2xPVR250 and NVidia GeForce 5200). I'll do some testing to see when
>it comes. Though if it's coming from a "requiredBuffer" value, is it
>possible to auto-increment this value (So each time a rebuffering is
>required, the "requiredBuffer" gets 1 added to it). This'd make these
>errors go away in very short order (As the system finds a suitable
>value for itself). Again, though, this does depend on what's causing
>these.
>

This sounds like the right approach.  It seems that different systems 
are coping differently with lower lag-behind values on different 
recordings.  Between each change there was testing to verify that it 
would work, so letting the system find it's own appropriate value would 
be ideal.

Note that in worst-case scenarios, the rebuffering can actually cause 
the commflagger to exit.

Mike


More information about the mythtv-dev mailing list