[mythtv] [ivtv-devel] trunk driver

[Attila Nagy]

On 1/24/07, Chris Pinkham <cpinkham at bc2va.org> wrote:
> * 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
>
> 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.
>
> 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.

What if you try to transform your tables (or at least the recorded
table) into InnoDB type tables? Those tables support transactions, so
a long select does not block the updates on the table. As I've seen
the scheduler does not lock the tables implicitly, so it is the MyISAM
engine, that blocks the update.

-- 
Nagy Attila Gabor
nagy.attila.gabor at gmail.com