<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p><br>
    </p>
    <br>
    <div class="moz-cite-prefix">On 28/01/18 21:31, Craig Huff wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAO0hLGr_kHsQCnrFaktdLUtPQ+BhtE3nKiFXubvcXmOStTy_oA@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">On Sun, Jan 28, 2018 at 3:14 PM,
            Craig Huff <span dir="ltr"><<a
                href="mailto:huffcslists@gmail.com" target="_blank"
                moz-do-not-send="true">huffcslists@gmail.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0px 0px 0px
              0.8ex;border-left:1px solid
              rgb(204,204,204);padding-left:1ex">
              <div dir="ltr">
                <div class="gmail_extra">
                  <div class="gmail_quote">On Sun, Jan 28, 2018 at 3:03
                    PM, John Pilkington <span dir="ltr"><<a
                        href="mailto:J.Pilk@tesco.net" target="_blank"
                        moz-do-not-send="true">J.Pilk@tesco.net</a>></span>
                    wrote:<br>
                    <blockquote class="gmail_quote" style="margin:0px
                      0px 0px 0.8ex;border-left:1px solid
                      rgb(204,204,204);padding-left:1ex">Restore from
                      earlier backup?<br>
                      <br>
                    </blockquote>
                  </div>
                  <br>
                </div>
                <div class="gmail_extra">I found an earlier message on
                  the mailing list by Michael Dean from last February
                  that pointed to a web link for myisam table
                  maintenance. The simple table check reported the same
                  table with the same symptom, along with one named
                  #sql-5de_e6a.MYI as corrupted.  I suspect the latter
                  file is a mysql internal table and do not plan to
                  touch it.  As for the recordedseek table, the next
                  step is to use myisamchk to attempt a repair on it
                  using the "easy safe repair" step.<br>
                  <br>
                </div>
                <div class="gmail_extra">For lurkers/future searches of
                  the mailing list, the mail link I found was <a
href="http://lists.mythtv.org/pipermail/mythtv-users/2014-February/360413.html"
                    target="_blank" moz-do-not-send="true">http://lists.mythtv.org/<wbr>pipermail/mythtv-users/2014-<wbr>February/360413.html</a><br>
                  <br>
                </div>
                <div class="gmail_extra">As I _do_ have backups of the
                  database, I can do as you suggested, but I'd like to
                  try this first.<br>
                </div>
                <div class="gmail_extra"><br>
                  --<br>
                </div>
                <div class="gmail_extra">Craig.<br>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
          Hmmm...  The "easy safe repair" step looked like it worked as
          seemingly confirmed by re-running the myisamchk test against
          the recordedseek.MYI file afterwards, but once I restarted
          mysql and mythtv-backend and tried running optimize_mythdb
          again, I get the same error result and a subsequent run of
          myisamchk shows the error is back again.  Maybe I need to fix
          the #sql-5de_e6a.MYI file, too?<br>
          <br>
          Not so sure I'm comfortable with that.  I'll ponder on that
          awhile, whilst hoping someone can chime in with more advice,
          since my last db backup was done before the most recent
          recordings (backup was Saturday morning so recordings done in
          the last 24 hours would be unaccounted for).<br>
          <br>
          --<br>
        </div>
        <div class="gmail_extra">Craig.<br>
        </div>
      </div>
      <br>
    </blockquote>
    <br>
    If you can't repair the recordedseek table one option is to truncate
    it and restore just that table from your old backup. That way only
    the seektables for new recordings will be missing which you can fix
    by running 'mythutil --checkrecordings  --fixseektable'<br>
    <br>
    Paul H.<br>
  </body>
</html>