[mythtv-users] All encoder MPG stream buffers are full. Dropping data.

[Roger Heflin]

Kelly Shutt wrote:
> BUMP... noone has any ideas on this one?  I'd rather not have to 
> downgrade, which I don't even think is possible.  Right now it's not 
> usable at all, due to the fact that it's loosing like 25% of the 
> recording per hour from these errors.
> 
> Thanks,
> Kelly Shutt
> 
> 
> Kelly Shutt wrote:
>> I've been getting "All encoder MPG stream buffers are full. Dropping
>> data." for the last week or so and it's causing jitters in my
>> recording.  My machine has been running mythtv fine for over a year now
>> and started doing this after I updated to 2.6.24 kernel and the latest
>> 0.21 mythtv release.  It worked fine with 2.6.23 kernel and 0.20
>> release, but not the updates.  I have started running the database
>> optimization script nightly, but that has not helped.  I have also added
>> "options ivtv enc_mpg_buffers=16" to make sure it's using the maximum
>> buffer size for the PVR-350 card, which did not help either.  I've been
>> looking at load, etc. and don't see any issues there.  The machine is
>> dedicated to MythTV only, so there's not really anything else running
>> that could interfere.  I've even discontinued all my transcoding for the
>> moment to eliminate that as a possible CPU hog.  Anyone have any other
>> suggestions?
>>
>> Thanks,
>> Kelly Shutt


I was getting that error quite a bit, but it no longer appears to be happening 
much anymore.

The only thing I can think of that I changed recently was to use rsync for large 
copies that I was doing (with -bwlimit 10000 to prevent IO starvation), before 
that  I was at times getting remote frontend glitches when the copies were in 
progress, I don't think I noticed large glitches in the recordings, but I may 
not have had enough IO to really mess things up.

And if this is the cause, no matter how fast your disk is, you will have this 
issue as the unlimited streams will just be faster, but will still can cause IO 
starvation.

Check the time that you get those messages at, I just looked at mine, and I was 
getting most of them at 10 minutes after the hour (84 of 116 errors happen 
between xx:10:00 to xx:10:59 after), and most of the rest of the messages seem 
to cluster around certain times (likely certain events happening on the machine 
that cause IO).

                            Roger