roberts.lane at gmail
Nov 16, 2009, 5:34 PM
Post #6 of 8
(369 views)
Permalink
|
On Mon, Nov 16, 2009 at 6:59 PM, Michael T. Dean
<mtdean [at] thirdcontact> 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?
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
|
