[mythtv-users] ivtv says "application is not reading fast enough"
ajlill at ajlc.waterloo.on.ca
Wed Jan 24 23:20:55 UTC 2007
It sounds like the same design flaw in myth that I and a few other
people have run into. The problem is they are trying to do a lot of
database inserts in the same thread that is reading data from the
encoder. If you don't mind compiling your own myth,
there's a patch attached to http://svn.mythtv.org/trac/ticket/1660
that corrects it by offloading the database work to a separate thread.
Tony Lill, Tony.Lill at AJLC.Waterloo.ON.CA
President, A. J. Lill Consultants fax/data (519) 650 3571
539 Grand Valley Dr., Cambridge, Ont. N3H 2S2 (519) 241 2461
--------------- http://www.ajlc.waterloo.on.ca/ ----------------
Understatement of the century:
"Hello everybody out there using minix - I'm doing a (free) operating
system (just a hobby, won't be big and professional like gnu) for
386(486) AT clones"
- Linus Torvalds, August 1991
"Victor Perez" <spectro at gmail.com> writes:
> Hello all, since I upgraded to Knoppmyth R5E50 (mythtv 0.20) and I am
> getting choppiness and framedrops in recordings around the time a
> simultaneous recording starts/ends. There seems to be an issue in Mythtv
> 0.20 that hoses the CPU to the point it forces ivtv to flush its buffers:
> ivtv1: All encoder MPEG stream buffers are full. Dropping data.
> ivtv1: Cause: the application is not reading fast enough.
> The IVTV guys fixed an issue with the driver that may be part of the cause.
> It works better but still have issues with it.
> On 1/11/07, rob+myth at robnet.com <rob+myth at robnet.com> wrote:
>> On Wed, Jan 10, 2007 at 06:35:27AM -0600, rob+myth at robnet.com wrote:
>> > Some 30 seconds or less after starting a recording the %cpu for
>> > climbs to 100% +/-, and I get the "dropping data" messages from ivtv
>> > message below). No message in mythbackend.log, but I need to run again
>> > more logging enabled. Same happens for live tv. The normal ivtv test,
>> > /dev/video0 > test.mpg, works fine with low cpu (around 8%) and nothing
>> > dmesg even when run for more than an hour. I keep thinking it's an ivtv
>> > problem for some reason... but this would seem to imply that it isn't.
>> A quick follow up, in case others have similar problems. After trying
>> combinations of kernel versions and ivtv versions, I'm back in
>> business. So
>> even though the "cat test" worked, it *seems* it was a ivtv (or kernel)
>> The versions that I'm using now (and that seem to work fine):
>> Both of those are masked. Running a masked ivtv isn't new to me, but I
>> usually avoid masked kernels. Oh well... it's recording again!
>> mythtv-users mailing list
>> mythtv-users at mythtv.org
> mythtv-users mailing list
> mythtv-users at mythtv.org
More information about the mythtv-users