[mythtv] [ivtv-devel] trunk driver

[f-myth-users at media.mit.edu]

[Added mythtv-dev 'cause patch #1660 was -supposed- to fix this, but might not?]

    > Date: Tue, 23 Jan 2007 09:42:42 -0600
    > From: "Victor Perez" <spectro at gmail.com>

    > I am having the same "buffers are full" issue, yesterday I installed IVTV
    > trunk (0.8.3, 3715) and increased buffers to 16. It seems better but I'm
    > still getting the errors. I wonder if increasing buffers even more would
    > help.

    > I think this is a mythtv 0.20 issue, looking at my logs most of these buffer
    > errors seem to happen at the start/end of recordings and only with
    > simultaneous recordings:

This is -exactly- what I've been battling for about a year.  I've done
all the "canonical" things re multiple spindles, keeping the DB
optimized, and even went from ivtv 0.4.1 to itvt 0.4.9 just a few days
ago to see if it was a buffer-handling problem (didn't help) while
asking for maximal (16meg) buffers in my options line.  [I'm running
Breezy on my Myth machines, hence kernel 2.6.12, hence I can't use
anything more recent than ivtv 0.4.x.]

Also over the last year, patch #1660 (http://svn.mythtv.org/trac/ticket/1660)
seems to claim that the problem hasn't been competition for disk heads
(which would explain why my putting the DB on a different spindle &
IDE channel hasn't helped), but rather that during the reschedule
(which happens after -every- recording ends and can take almost 30
seconds!), it seems that the process that's writing stuff into
recordedmarkup hangs on the DB (why is the DB lock on the scheduler
tables keeping recordedmarkup from being updated?  shouldn't they be
independent?), and since that very same process is responsible for
emptying the ivtv buffers, it winds up requiring 20-30 seconds of
buffers per card, which is insane.

I'm disappointed to hear, however, that you're getting this problem
under 0.20---my understanding (someone please correct me if I'm wrong)
was that #1660 went into 0.20 and therefore that you should have the
benefit of this patch.  (I'm still running 0.18.1, so I can't easily
tell---but this is one more reason for me to upgrade, -if- this patch
is really helping...)  Your mail motivated me to go figure out which
ticket this was and to go read it just now, and it puzzles me that it
hasn't helped you (and depresses me that upgrading to 0.20+ may not
help me, either).

Can someone clarify under what circumstances (and which releases!)
this patch applies?  I see traffic on the ticket all the way up to 3
weeks ago, so I'm not sure offhand (without grovelling over .19, 20,
-fixes for both, and SVN) which releases have this patch.  And does
it make sense that recordedmarkup (or whatever SVN is calling this
table) can't be written to during the scheduler query?  Shouldn't
mysql allow both to proceed independently?

Thanks much for any insight...

P.S.  I'm guessing this isn't more widely seen because it no doubt
depends on the complexity of the scheduler query -and- how many
ivtv-based cards one has---lots of people are using non-ivtv SD cards,
or are capturing HD, and I presume that it's only the ivtv-based
captures that are writing into recordedmarkup in real time and hence
getting stalled by the damned scheduler query.  True?