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.
> > 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
