[mythtv-users] Better listings for Schedules Direct users. Free! (was Re: another scheduling strangeness/question)
mythtv-users2 at dwilga-linux1.amherst.edu
Wed Sep 1 20:01:41 UTC 2010
On 9/1/10 11:45 AM, Ozzy Lash wrote:
> On Wed, Sep 1, 2010 at 1:16 AM, Michael T. Dean<mtdean at thirdcontact.com> wrote:
>> On 09/01/2010 01:39 AM, Ozzy Lash wrote:
>>> On Tue, Aug 31, 2010 at 6:50 PM, Michael T. Dean wrote:
>>>> And, now it's time to come clean. What I hadn't said is that we actually
>>>> have full support for grabbing all days of listings data from TMS in a
>>>> single pull. It's been this way for quite some time (including in
>>>> 0.23-fixes, and possibly even 0.22-fixes).
>>>> After discussion with some of the Schedules Direct board and a lot of
>>>> effort, including testing, by people such as Robert Eden and Chris
>>>> we've decided to "advertise" this approach. Since it works in 0.23-fixes
>>>> well as trunk, users may enable its use immediately.
>>>> However, use of --dd-grab-all has not been optimized, so it can take
>>>> significantly more CPU and RAM than a "normal" run of mythfilldatabase.
>>>> Users with resource-limited backend systems may not be able to use the
>>> I just tried it on a newish AMD quad core system with 4 Gig of RAM
>>> thinking "I don't have a resource limited system". While I was doing
>>> a single recording over firewire and simultaneous commercial flagging,
>>> the run took a little over 45 minutes (only about 2.5 downloading the
>>> data). I feel so humbled! I have 2 source, one for clear QAM which
>>> only has 50 channels or so (maybe less) and one for firewire which has
>>> a few hundred (actually it says 502 in the mythfilldatabase output).
>>> Clearing the data for source 1 for all 14 days took about 3 minutes,
>>> and clearing the data for the firewire source took about 30 minutes.
>>> Does this point to something I need to tune in my database setup? I
>>> have some tweaks to my mysql settings that were suggested a long time
>>> ago on this list if you had a lot of memory (probably 2 gig back then)
>>> Here they are:
>> It's possible that the slow DB update was primarily due to DB locking caused
>> by the fact that the database was in use while recording. It's also
>> possible that lineup--550 channels--may just be asking a lot of even your
One thing I'll say about this possibility: If locking is the reason, it
would probably help to convert your DB tables to innodb. This engine
supports row-level locking, whereas myisam locks the entire table
whenever a write is occurring. The downside of innodb is that it
generally requires more memory and can be somewhat slower for some
Dan Wilga "Ook."
More information about the mythtv-users