[mythtv] [ivtv-devel] trunk driver

[Chris Pinkham]

* On Tue Jan 23, 2007 at 11:15:06PM -0500, f-myth-users at media.mit.edu wrote:
>> Date: Tue, 23 Jan 2007 22:45:03 -0500
>> From: Chris Pinkham <cpinkham at bc2va.org>
>
>> Is it the recordedmarkup/seek that is hanging or the update of the
>> filesize in the recorded table.  The scheduler query does a left join
>> on the recorded table and the filesize in the recorded table gets
>> updated whenever a recording ends.
> 
> I have no idea and am not sure how to investigate that.  I was going

If anyone who is having this problem wants to test out this theory,
they can test by searching for "curRecording->SetFilesize" in
libs/libmythtv/mpegrecorder.cpp and comment out the two lines where
that text occurs.

The filesize is updated ever time we update the seektable, which in
the ivtv/mpeg recorder is every 30 keyframes.  It would makse sense
that we can't update the recorded.filesize field until the scheduler
query is finished since it is accessing the recorded table.  A quick
preliminary test on my dev box is confirming that as well.  On my
dev box, my scheduler takes about 19 seconds to run.  While the
scheduler was running, I ran the following SQL update in a mysql
session:

UPDATE recorded
   SET filesize = 0
   WHERE chanid = 1010
      AND starttime = 20061213200000;

The update blocked until the scheduler query was finished.

Inside MpegRecorder::HandleKeyframe(), we call
MpegRecorder::SavePositionMap() which calls curRecording->SetFilesize
which does an "UPDATE recorded" exactly like I show above.  This
means that the main loop that is processing data in the recorder
get blocked trying to update the recorded table while the scheduler
is doing a select on that table.

This same logic would apply to us updating the recordedmarkup/seek
table while another process (ie, mythfrontend, mythcommflag, etc.)
is reading from that table although these reads take much less time
than the time it takes the scheduler to do that big query against
the recorded table.

I can see the recordedmarkup changes being a part of the problem,
but I think the bigger issue is the locking of the recorded table
by the scheduler which blocks the recorder's main processing loop
because it is trying to update the filesize in the recorded table.

> I'd be very interested to know which releases #1660 is in and whether
> it's really helped, especially given the OP's contention in 0.20 that
> he's got the same problem I've got.

The patch in #1660 is not in any releases, it isn't in SVN either.

I think it is best to move the DB updates out to another thread, but
haven't looked the patch in #1660 over.

--
Chris