--- [EMAIL PROTECTED] wrote: > Date: Wed, 24 Jan 2007 13:17:11 +0100 (CET) > From: "Hans Verkuil" <[EMAIL PROTECTED]> > > > > I've started playing with that query but it's already fairly > optimized. > > > It > > > seems to me that the only real solution is to put the database on > another > > > machine with a whole lot of RAM. Right now I'm up to one backend > which > > > has > > > two PVR-150s for recording, one backend/frontend with a PVR-350 for > > > viewing > > > and recording, one backend which has no encoders for storage only, > one > > > backend/frontend which as the master backend. > > > > > > I thought that isolating each of the jobs would help, but even on the > > > latest > > > trunk with enc_mpg_buffers=16 I'm still getting the: > > > Just verifying that I understand it correctly: this also happens with a > > non-trunk ivtv release, correct? So it is not some ivtv trunk bug that > is > > hiding somehwere. > > It's been happening to me all the way back in ivtv 0.4.1 (see other > traffic of mine today). I'm convinced this is a myth bug related to > stalling the emptying of ivtv buffers while the process responsible > for that waits on a MySQL lock held by the myth scheduler. >
I should mention that I'm using ivtv-svn on a 266MHz ARM cpu with 64MB memory and I can keep up just find streaming a 4mbps stream from a cx23416. So... I would have to agree that the issues this thread is talking about must be something in mythtv thats causing it to not pull data fast enough. Tim > > > Jan 23 23:00:26 mythcorder kernel: ivtv1: All encoder MPEG stream > buffers > > > are full. Dropping data. > > > Jan 23 23:00:26 mythcorder kernel: ivtv1: Cause: the application is > not > > > reading fast enough. > > > Jan 23 23:00:26 mythcorder kernel: ivtv1: All encoder MPEG stream > buffers > > > are full. Dropping data. > > > Jan 23 23:00:26 mythcorder kernel: ivtv1: Cause: the application is > not > > > reading fast enough. > > > Jan 23 23:00:26 mythcorder kernel: ivtv1: All encoder MPEG stream > buffers > > > are full. Dropping data. > > > Jan 23 23:00:26 mythcorder kernel: ivtv1: Cause: the application is > not > > > reading fast enough. > > > Jan 23 23:00:26 mythcorder kernel: ivtv1: All encoder MPEG stream > buffers > > > are full. Dropping data. > > > Jan 23 23:00:26 mythcorder kernel: ivtv1: Cause: the application is > not > > > reading fast enough. > > > > > > It happens on both boxes that do encoding, usually at the beginning > of the > > > recording, but sometimes you'll be watching a recording and it will > have > > > done it halfway through. It's the worst when you miss the build-up > to a > > > joke and you only catch the punchline. > > I'm betting that the "beginning" issues are because you had some other > program that ended just then---which caused the scheduler to run. The > "halfway through" is probably because a you're recording one show from > 1pm to 2pm and another show ends at 1:30pm---causing a scheduler run. > > I'm also betting you'll see this if you -delete- something while > recording, because deletions cause scheduler runs. > > (All of my recordings start/end 1-2m early/late, so I very frequently > get a glitch a minute or two into a recording because other one just > ended at :01 or :02.) > > > With 16 MB of buffers that should give you somewhere between 10-16 > seconds > > of buffering I think. I find it hard to believe that MythTV would take > so > > much time! You can easily check how full the various buffers are by > > running v4l2-ctl --log-status. > > My MythTV scheduler queries take 15-25 seconds. Thus, I frequently > run out of buffers. Others have responded likewise. (There's also > traffic in the last few hours on the myth dev list indicating that > certain types of schedules can make the problem worse, and fixing > -all- of them can bring down the time by a factor of 4 or so---but > asking random end users to correctly predict myth's scheduler > performance is really asking way too much of them, I'd wager.) > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel > _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
