<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 10, 2023 at 6:24 PM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz">stephen_agent@jsw.gen.nz</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mon, 10 Apr 2023 14:08:45 -0700, you wrote:<br>
<br>
>Stopped mythbackend and performed the repair steps<br>
><br>
>> sudo mysqlcheck --repair mythconverg recordedseek<br>
>> sudo mysqlcheck --optimize mythconverg recordedseek<br>
>> sudo mysqlcheck --analyze mythconverg recordedseek<br>
>><br>
>No errors reported.  Did same for recordedmarkup, also no errors.<br>
><br>
>Then I tried (had to delete the final Z in the timestamp)<br>
>INSERT INTO recordedseek (chanid, starttime, type, mark, `offset`) VALUES<br>
>(10501,'2023-04-08T04:59:00',9,0,376);<br>
>result:<br>
>MariaDB [mythconverg]> ERROR 1062 (23000): Duplicate entry<br>
>'10501-2023-04-08 04:59:00-9-0' for key 'PRIMARY'<br>
>I verified that there was an existing entry already.  As with the<br>
>duplicates in recordedmark, this doesn't actually seem to be a problem with<br>
>the database, but a problem with the program or, in this case, me, for<br>
>trying to insert a duplicate.<br>
<br>
Using mythcommflag --rebuild should not cause duplicates, as<br>
mythcommflag deletes all recordedseek rows that match the recording<br>
before it creates the new ones. </blockquote><div><br></div><div>Since mythcommflag shouldn't cause duplicates but it does apparently, several possibilities occur:</div><div>1. The delete operations that clear things out are failing, in part or in full.<br></div><div>2. The delete operations are not getting sequenced by the db ahead of the subsequent writes.</div><div>3. mythcommflag is producing duplicates.  As odd as that sounds, it's the same thing that seems to be happening with the original problems of duplicates in the recordedmarkup table, which is somehow getting attempted writes of 2 different times for total duration.</div><div>4. My manual experiment  got a duplicate warning because the bulk insert from which the single insert was taken succeeded partially.  So that particular record was written.  That leaves the source of the original errors unclear.<br></div><div>5. The duplicate warning is itself spurious. <br></div><div><br></div><div>I'm having trouble imagining how a problem with the database would cause the program to start producing duplicates, if it is not a failed deletion.  Then again, I'm having trouble imagining why it would produce 2 different total durations at all.</div><div><br></div><div>It might be relevant that I run commercial flagging while recording the show.  The end of the recording and of the processing of the commercials may happen fairly soon after one another, and I suppose each could generate a total time for the recording.  But wouldn't it be the same total time?<br></div><div><br></div><div>Thanks for  your other points too.  I understand the db may not be shutdownable.  Debian probably has more recent drivers available for more cutting edge flavors; I might try them.</div><div><br></div><div>I'll consider more frequent backups once I have a database that doesn't seem messed up.</div><div><br></div><div>Does the backup produce valid results even if the db has other activity going on?<br></div><div><br></div><div>Ross<br></div></div></div>