<br><br><div class="gmail_quote">2009/9/29 Michael T. Dean <span dir="ltr">&lt;<a href="mailto:mtdean@thirdcontact.com">mtdean@thirdcontact.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 09/29/2009 10:05 AM, Nicolas Will wrote:<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im">
On Sun, 2009-09-27 at 19:09 -0400, Michael T. Dean wrote:<br>
  <br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
So, that&#39;s because there&#39;s a &quot;prefix&quot; index on the name column of the people table.  Only the first 41 (of 128) characters are checked to determine if the values are unique.  I&#39;m actually about to commit a<br>

fix to the corruption-detection thanks to your noticing this.  It will actually make it a more-stringent check, so it won&#39;t cause your DB to pass, so don&#39;t worry about updating to get it.  :)<br>
</blockquote></div>
I&#39;ve been hit by the duplicate issue when moving to .22.<div class="im"><br>
<br>
I cleaned my DB, but it was still the same.<br>
<br>
In the clean DB file, I changed the 41 to 51 and it restored properly,<br>
as it was checking more characters for uniqueness.<br>
<br>
Then .22 converted its DB version without any problem.<br>
<br>
Should I expect any ill result from this?<br>
</div></blockquote>
<br>
It may break future upgrades, depending on what happens in the future.  Changing the index prefix length is /definitely/ not a fix as there is no possible way that the first 41 bytes of the UTF-8 data could be unique across all rows (as it would have to be for the data to exist in a properly-encoded UTF-8 in latin1 column MythTV database) but after condensing to actual UTF-8, the first 41 characters are not unique--as the first 41 characters encompass more data than the first 41 bytes, presuming there are /any/ multi-byte characters.  Therefore, it means the table is definitely corrupt--with some latin1 data (which should not be there) and some UTF-8 data, such that there exist dups after conversion.  Therefore, even after changing the prefix length, you still have corrupt data.<br>

<br>
A better approach is to get rid of the people.  They&#39;re only used by the People Search (which, chances are, you&#39;ve never used before), and will be repopulated quite quickly from new listings.<br>
<br>
If <a href="http://www.gossamer-threads.com/lists/mythtv/users/399395#399395" target="_blank">http://www.gossamer-threads.com/lists/mythtv/users/399395#399395</a> (after correcting my copy/paste errors as mentioned at <a href="http://www.gossamer-threads.com/lists/mythtv/users/399413#399413" target="_blank">http://www.gossamer-threads.com/lists/mythtv/users/399413#399413</a> ) where the grep is run against either the &quot;uncorrupt&quot; backup or the original backup doesn&#39;t work, or if after the database upgrade is performed the data doesn&#39;t look right, your best bet is to wait a few days.  If you can&#39;t wait a few days and don&#39;t mind corrupting your data, it&#39;s your data, so it&#39;s your decision.  But, it&#39;s just a few days...<br>

<br></blockquote><div>Hi<br><br>I have also been hit by the corruption issue, when trying to go to 0.22 RC1, currently running 0.21 with a database schema bversion 1215. I have been though the wiki article on how to repair the database several times now this morning, and have followed the various instructions by Mike to no avail.<br>
<br>the error I get (with verbose on) is <br><br>&#39;mysql&#39; --defaults-extra-file=&#39;/tmp/wPMWZ7oQgH&#39; --host=&#39;localhost&#39; --user=&#39;mythtv&#39; &#39;mythconverg&#39;<br>ERROR 1062 (23000) at line 1915: Duplicate entry &#39;JÃÂÃâ¬Ã»ÃÂÃâ¬Ã»rÃÂÃâ¬Ã»&#39; for key 2<br>
<br>I have searched for this string in phpmyadmin, and also ran a grep against the initial backup and the repaired file and cannot find the string. Advice on how to track this and fix would be appreciated.<br><br>My Mysql server config is<br>
<br>mysql  Ver 14.12 Distrib 5.0.32, for pc-linux-gnu (i486) using readline 5.2<br><br>Connection id:          55<br>Current database:       mythconverg<br>Current user:           mythtv@localhost<br>SSL:                    Not in use<br>
Current pager:          stdout<br>Using outfile:          &#39;&#39;<br>Using delimiter:        ;<br>Server version:         5.0.32-Debian_7etch1 Debian etch distribution<br>Protocol version:       10<br>Connection:             Localhost via UNIX socket<br>
Server characterset:    latin1<br>Db     characterset:    latin1<br>Client characterset:    latin1<br>Conn.  characterset:    latin1<br>UNIX socket:            /var/run/mysqld/mysqld.sock<br>Uptime:                 48 min 29 sec<br>
<br>Thanks very much.<br><br>Gary<br></div></div>