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. Something in the more recent kernel+ivtv+mysql+mythtv combinations is breaking where the older kernel+ivtv+mysql+mythtv combinations worked. 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. 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? 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. -brendan _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
