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

[stinga]

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.

-- 
'ooroo

Stinga...(:)-)
---------------------------------------------------
Email:stinga+mythtv at wolf-rock.com   o
You need only two tools.        o /////
A hammer and duct tape. If it    /@   `\  /) ~
doesn't move and it should use  >  (O)  X<  ~  Fish!!
the hammer. If it moves and      `\___/'  \) ~
shouldn't, use the tape.           \\\
---------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230412/a17e1bcc/attachment.htm>