Date: Wed, 24 Jan 2007 09:56:07 -0500 (EST)
From: Brendan Hoar <[EMAIL PROTECTED]>
On Wed, 24 Jan 2007, Matthias Urlichs wrote:
> Victor Perez:
> > helps, heck, I may end up optimizing that slow query.
>
> Right. Please don't try to "fix" this problem in ivtv.
>
> I hate to say this, but if you put your database (or anything else for
> that matter) on the same spindle as your real-time recording, you
> deserve to lose.
And yet, this is exactly what Tivo has been doing for over half of a
decade without problems. If designing real time pro studio equipment,
sure, I agree, but consumer PVRs tend not to have more than one drive in
them. I'm not sure why hobbyists should be forced to go that direction.
And traffic on the mythtv-dev list indicates this has little or nothing to
do w/one drive and everything to do w/excessive locking of DB tables.
[And further discussion should probably be held there; this really
isn't an ivtv bug, unless papering over Myth's bad behaviour by
allowing (say) 60meg of buffering per card is ivtv's responsibility.]
Something in the more recent kernel+ivtv+mysql+mythtv combinations is
breaking where the older kernel+ivtv+mysql+mythtv combinations worked.
No. It's been broken all the way back to ivtv 0.4.0/0.4.1 and mythtv
0.18.1 under Ubuntu Breezy (2.6.12-10), because that's what I run and
it's broken for me.
The 1660 patch points at the mythtv 0.20 possibility of a single thread
being responsible for regular reads from the ivtv mpg buffer as well as
having the potential to be suspended waiting for a very long database
query to return. That seems like a bad design. Last I checked, the
patch entry appeared to have been marked for inclusion into 0.21, so
it's not yet in the release.
It could be other things though.
It could be, but cpinkham (I believe) tried a test that eliminated one
action that was locking two tables (I could dig up the mail; it was in
the last week) and the problem went away fro him.
Has anyone investigated whether mythtv is always properly emptying the
buffer entirely when it pulls data? That is, is mythtv ever getting
into a situation where it believes there's little to no data pending a
read when, in fact, that's not the case?
I don't know.
Alternately, are there other areas where mythtv may be getting blocked
from performing the reads in a timely manner?
I've got three cards, and my MPG buffers all set at 16MB. The problem
continues.
See pretty much all my traffic for the last 6 months to mythtv-users
and mythtv-dev. It's mostly been complaining about this issue, and
all the things I tried to do to resolve it (DB config tweaks, using
more than one disk, giant ivtv buffers, optimizing the DB, trying a
newer ivtv [0.4.9] in case 0.4.0/0.4.1 wasn't -actually- giving me the
giant buffers I was requesting, etc etc). Nothing's worked.
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
