[mythtv-users] Slow scheduling response

Lane Roberts roberts.lane at gmail.com
Tue Nov 17 01:34:22 UTC 2009

On Mon, Nov 16, 2009 at 6:59 PM, Michael T. Dean
<mtdean at thirdcontact.com> wrote:
> On 11/16/2009 07:20 PM, Lane Roberts wrote:
>> On Mon, Nov 16, 2009 at 1:13 PM, Michael T. Dean wrote:
>>> On 11/16/2009 10:51 AM, David Engel wrote:
>>>> On Sun, Nov 15, 2009 at 11:28:57AM -0600, Lane Roberts wrote:
>>>>> I've got a fresh install of ubuntu 9.10 Server, running myth .22-fixes
>>>>> r22824. Performance when adding or changing a recording schedule seems
>>>>> extremely slow. In both mythweb and the program guide, saving a change
>>>>> results in a 25-30 second wait, where mysqld spikes cpu usage to
>>>>> ~100%.
>>>>> When I installed, I did migrate recording history and schedules. Am I
>>>>> missing an Index on one of the tables? Does anyone else see the same
>>>>> thing or have any ideas?
>>>> 25-30 second reschedules is not normal.  A missing or corrupted index
>>>> could be the cause.  Backup your database and restore it.  If the
>>>> problem persists, what does the output look like when you add "-v
>>>> schedule" to your mythbackend command line?
>>> And, if it is a corrupt schema (meaning missing indices), you may need to
>>> do
>>> a partial restore.  To do this you'd backup DB, drop DB, create DB with
>>> mc.sql, start mythtv-setup to create the schema (including the missing
>>> indices), then restore only the non-recreatable data into the new
>>> database.
>>> http://www.mythtv.org/wiki/Database_Backup_and_Restore#Partial_restore_of_a_backup
>>> read the instructions carefully and follow all of the instructions.
>> Mike, David,
>> Thanks for pointing me in the right direction - there was definitely
>> something wrong with the schema. Scheduling is back down to sub-2
>> seconds, which is good enough for me.
>> The only issue I ran into was that my backup had an `offset` column in
>> recordedmarkup, that is not present in the new schema. I truncated the
>> partial restore tables, added the `offset` column, and re-ran the
>> restore without any problems.
> You can only do a partial restore from/to the same version of MythTV schema.
>  If you did a partial restore from your 0.21-fixes database into a
> 0.22-fixes schema, it will corrupt some of your data.  (Most noticeable, in
> this case with seeking in old recordings and with bookmarkes, etc.)
> If you want to do the partial restore from your 0.21-fixes database, you'll
> need to follow instructions at
> http://www.gossamer-threads.com/lists/mythtv/users/406111#406111 (which
> includes a "blank" 0.21-fixes database--use that instead of start
> mythtv-setup to create the schema).
> Mike

ok, I did see that part in the docs. The two issues you mentioned, I'm
not too concerned about (I've only got a few existing recordings). How
likely am I to run into anything more serious?

Since I only added the offset column for the restore, then dropped it,
I should be alright going forward, correct? I'm only really concerned
about what happens when I go to upgrade to .23. I'm assuming that
since the schema is now correct, I should be alright?

More information about the mythtv-users mailing list