On Wednesday 24 January 2007 01:28, [EMAIL PROTECTED] wrote: > [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" <[EMAIL PROTECTED]> > > > > 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.] This is what I noticed and asked for 2 months ago: Maybe not-related, maybe it is. From: Henk Schoneveld <belcampo[at]zonnet.nl> Subject: [mythtv-users] 0.20 loves X too much To: mythtv-users[at]mythtv.org Message-ID: <200612071530.00590.belcampo[at]zonnet.nl> Content-Type: text/plain; charset="us-ascii"
Hi all, I think I notice that .20 isn't releasing memory after exiting. Made some comparisons between fixes of .19 and .20. Boot, log free -m, start Mythbackend, log free -m, start Mythfrontend go to Recordings page, log free -m, exit Mythfrontend, log free -m, stop Mythbackend, log free -m. If I do this with 0.19-fixes I get back all resources back. If I do exactly the same with 0.20-fixes I've lost 25-30MB which is 'happily' consumed by X. Both versions are compiled without OpenGL and use QTpainter. With the 0.20-fixes version after closing all down and starting for example firefox and then Mythbackend and Mythfrontend to the Recordings page, then exiting and shutting down Mythbackend and exiting firefox I tend to loose about the same amount of memory 25-30MB according to free -m. Any idea how to solve this ? I tried the above on 2 systems one with old XFree86 with 2.4.22 kernel and one with Xorg 6.9 with a 2.6.17 kernel. Systems do have other chipsets and different videocards. Henk Schoneveld PS. I use DVB-S card, not ivtv > > 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? > > _______________________________________________ > ivtv-devel mailing list > [email protected] > http://ivtvdriver.org/mailman/listinfo/ivtv-devel _______________________________________________ ivtv-devel mailing list [email protected] http://ivtvdriver.org/mailman/listinfo/ivtv-devel
