[mythtv-users] Problem with latest run of optimize_mythdb.pl

[Stephen Worthington]

On Tue, 29 Dec 2015 03:41:54 +0100, you wrote:

>Hoi Mike,
>
>Tuesday, December 29, 2015, 3:09:12 AM, you wrote:
>
>> On 29 December 2015 at 11:45, Hika van den Hoven <hikavdh at gmail.com> wrote:
>
>>> Hoi Mike,
>>>
>>> Tuesday, December 29, 2015, 1:21:33 AM, you wrote:
>>>
>>> > The moral of this story is to finish debugging the issue first, rather
>>> than
>>> > rush in and start deleting data.
>>>
>>> True, but it would not have made any real difference and there was no
>>> data lost as it was all recreatable. The table needed to get cleared
>>> as it had already crashed.
>>> Checking earlier would only possibly have prevented the table crashing
>>> again!
>>>
>
>> No issues this time ...
>
>> That was more a pointer for someone in 6 months' time who has similar
>> issues with a crashed table, and who finds this thread via Google, and
>> who's first action is to truncate their "recorded" table, or their
>> "channel" table by following this advice, and then finds that their backup
>> isn't working properly, or is several weeks out of date, or any number of
>> other scenarios where they wouldn't be able to easily get back to a working
>> system.
>
>Again True. In this kind of situations you always have conflicting
>priorities. You want it up and running as fast as possible to not miss
>future recordings and you don't want to loose any data needlessly.
>As far as I know trying to repair a crashed table is not possible, but
>my knowledge is limited.

In this case though, the table was probably not crashed.  There was
simply insufficient space for the necessary temporary table(s) for
operations on the recordedseek table to complete successfully.  So
truncating was likely a bad idea.  Error messages about crashed tables
do not always mean the table is actually crashed.