[mythtv-users] INSERT INTO recordedmarkup fails w/duplicate; recording status changes

[Bill Meek]

On Tuesday 11 April 2023 09:48:29 PM (-05:00), stinga via mythtv-users wrote:


On 12/04/2023 10:41, Ross Boylan wrote:





On Mon, Apr 10, 2023 at 6:24 PM Stephen Worthington <stephen_agent at jsw.gen.nz> wrote:

On Mon, 10 Apr 2023 14:08:45 -0700, you wrote:

>Stopped mythbackend and performed the repair steps
>
>> sudo mysqlcheck --repair mythconverg recordedseek
>> sudo mysqlcheck --optimize mythconverg recordedseek
>> sudo mysqlcheck --analyze mythconverg recordedseek
>>
>No errors reported.  Did same for recordedmarkup, also no errors.
>
>Then I tried (had to delete the final Z in the timestamp)
>INSERT INTO recordedseek (chanid, starttime, type, mark, `offset`) VALUES
>(10501,'2023-04-08T04:59:00',9,0,376);
>result:
>MariaDB [mythconverg]> ERROR 1062 (23000): Duplicate entry
>'10501-2023-04-08 04:59:00-9-0' for key 'PRIMARY'
>I verified that there was an existing entry already.  As with the
>duplicates in recordedmark, this doesn't actually seem to be a problem with
>the database, but a problem with the program or, in this case, me, for
>trying to insert a duplicate.

Using mythcommflag --rebuild should not cause duplicates, as
mythcommflag deletes all recordedseek rows that match the recording
before it creates the new ones. 


Since mythcommflag shouldn't cause duplicates but it does apparently, several possibilities occur:
1. The delete operations that clear things out are failing, in part or in full.

2. The delete operations are not getting sequenced by the db ahead of the subsequent writes.
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.
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.

5. The duplicate warning is itself spurious.



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.


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?



I wonder if this is related to https://forum.mythtv.org/viewtopic.php?f=36&t=5349 "No longer able to delete recordings from Mythfrontend"

The Z on the end of the date could be the issue, which is unsupported in mysql.


He's on mariadb  Ver 15.1 Distrib 10.5.19-MariaDB, (I asked yesterday.)


Easy test. Delete a recording. If it comes back, then the issue matches.


I pushed a fix for master and v33, but stopped because the delete recordings issue isn't the only
user of that type of UPDATE. The forum comment  and links from Roland point at a Qt issue. The
final patch is in my tree and I'm testing now.


-- 
Bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230412/925586b5/attachment.htm>