[mythtv] [mythtv-commits] Ticket #2782: automatic simultaneous jobs scaling

[Yeechang Lee]

f-myth-users at media.mit.edu <f-myth-users at media.mit.edu> says:
> That means that a recording that ended while another was ongoing
> cause the ongoing one to drop many seconds at a time.  Not always,
> but often.

This is why I--with three HDTV recording streams and a not-so-fast NAS
to store recordings on--long since switched to manually patching the
ATrpms MythTV SRPMs with, among other things, significantly-increased
values in ThreadedFileWriter.cpp. See attached patch. This patch made
the single biggest difference in letting my frontend-backend system
record from all three streams simultaneously without dropping video
back when I was getting started with MythTV a year ago. (Switching to
CIFS was #2.) Even adding a 24x7 mythtranscode or mythcommflag process
didn't worsen things. Playback stutters are still almost impossible to
avoid on my setup when all three streams are recording away (and often
with only two), but at least the recordings are always intact; I much
prefer this to perfect playbacks with spotty recordings.

Please note that the patch is the result of a non-coder's
experimenting; I'd especially be curious to hear those who actally
know what they're talking about comment on the divisors I use for
TFW_MAX_BUF_SIZE and TFW_MIN_BUF_SIZE, and what the optimal values for
them would be in a typical remote recording-directory situation.

I submitted a ticket long ago but it was rejected, and properly so,
for forcing everyone, including non HDTV-using folks, to use
significantly-larger amounts of memory to record. That said, I
strongly suspect that the current values are simply too low.

> Some parameter that can be set without recompiling.  Lots of people
> use prepackaged distributions; having to recompile just to turn this
> off would shaft them.  So presumably a mythtv-setup value or at
> least a flag in the DB that can be set via a MySQL statement.

Absolutely. I'd *much* rather be able to tweak these settings from a
proper interface rather than recompiling. If not that, I'd take a
MythWeb-configurable setting.

Having more options are, nine out of ten times, a good thing. Yes,
there already are many pages of options between mythfrontend and
mythtv-setup. Those who don't want to add any more had better never,
ever claim that "the ability to configure things the way I want" is a
reason why they started MythTV in the first place!

-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-ThreadedFileWriter.cpp
Type: application/octet-stream
Size: 1002 bytes
Desc: patch-ThreadedFileWriter.cpp
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20061209/22be3572/attachment.obj 
-------------- next part --------------

-- 
Yeechang Lee <ylee at pobox.com> | +1 650 776 7763 | San Francisco CA US