[mythtv-users] Better listings for Schedules Direct users. Free! (was Re: another scheduling strangeness/question)

Dan Wilga 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
>>>> Petersen,
>>>> we've decided to "advertise" this approach.  Since it works in 0.23-fixes
>>>> as
>>>> 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
>>>> argument.
>>>>          
>>> 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
>> system.
>>      
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 
operations.

-- 
Dan Wilga                                                        "Ook."



More information about the mythtv-users mailing list