[mythtv-users] ivtv yuv_buffers?

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Thu Jan 18 22:28:21 UTC 2007

[ivtv 0.4.0, myth 0.18.1, 5xPVR-250's and ivtv 0.4.1, myth 0.18.1, 1xPVR-350.]

I'm trying to increase my ivtv buffering [1].  There's a mantra for
doing so at [2] which claims
    options ivtv yuv_buffers=32 mpg_buffers=16 vbi_buffers=16 pcm_buffers=16 dec_osd_buffers=2
is the right idea, though I've tried this in the past and discovered
that this adds about 100 meg per card to the system's memory
requirements, which isn't so great on a 1gig system that's also
running mythbackend and mysql and has lots of tuners.  Searching for
yuv_buffers on the web just finds lots of other documents that include
that entire line like a cargo cult, with no actual discussion.

But is that yuv_buffers setting even -necessary- if all I'm doing is
dumping mpeg data directly off the cards?  My understanding was that
yuv is the non-mpeg mode that pretty much nobody uses; why would
increasing that buffering help me?  Should I just use the line above
but exclude the "yuv_buffers=32"?  Can I set it to 0 or some small
number?  [Search results mention problems w/old kernels and yuv_buffers=0
but I don't know if that's still the case in 2.6.12 (mine) and later.]

I'm hoping that by -not- increasing that particular bit of buffering,
I can get more memory to be used by, e.g., the filesystem cache to
improve mysql performance.  (I may also only use mpg_buffers=8 and see
if that's enough, or I might even go to mpg_buffers=32 if [2] is wrong
that 16 is the maximum [is there a hardcoded max somewhere?].)  Note
that I -am- capturing VBI/CC data as well, so I assume I should still
increase both that and the PCM buffering as I'm increasing MPG buffering.

Also:  If I'm using a PVR-350 (for both capture -and playback-), should
I care about a yuv_buffer setting on the machine that owns -that- card?
(I'm also guessing not, but I'm asking for completeness.)  And is
the dec_osd_buffers setting ignored for the 250's?  [If so, I'll
leave it on the machine w/only 250's just so all machines have the
same buffering configuration, but if it's chewing up memory that can't
be used 'cause the machine w/the 250's has no 350, I'll remove it.]

[Note also that I asked on the ivtv/mythtv lists around Sep 1 '06 why
increasing the buffering yielded -such- a large increase per-card, but
got no response; simple math seems to indicate that I was losing lots
more memory (~2x?) to the buffering than the lines above and the syslog
output indicated should be allocated; if someone would like to address
that, i can dig up the original analysis.]

[1] The MythTV scheduler hits MySQL very hard every time it runs, and
even after increasing a number of MySQL buffer-size variables (which
helped substantially, but not completely) and playing with I/O
scheduling priorities (which either hurt or did nothing), I'm still
seeing frequent glitches in recordings if one ends (forcing a
scheduler run) while at least one is still capturing---I get "I/O
bound" errors in the myth log and "ENC Stream 0 OVERFLOW" errors in
syslog, even after ensuring that MySQL's DB files weren't on the same
spindle nor even IDE bus as the disk writing the capture data and
after making sure that the DB was always optimized every day.  [Yes,
the disks are UDMA 133, yes DMA is enabled, yadda yadda.]  I -really-
don't want to have to add a -third- CPU to the mix -just- to run MySQL
on it, just to avoid periodic I/O stalls when that scheduler query
runs [3], hence my hope that I can increase buffering "enough" without
starving the rest of the system.

[2] http://www.mythtv.org/wiki/index.php/Hauppauge_PVR-350

[3] If that would even help (I haven't tested it yet)---after all, Myth
is constantly writing to the recordedmarkup table -while capturing-,
which means that scheduler query might stall the recordedmarkup
writes, which might then stall Myth emptying ivtv's capture buffers
and hence cause the overruns I'm complaining about.  This seems like
it could use some improvement somehow and ISTR there -might- have been
improvements in later versions of Myth but can't remember now if they
got backed out 'cause they caused some other problem.

More information about the mythtv-users mailing list