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

[Mike Carron]

The Z in the time indicates that the time listed is in Zulu (Greenwich 
Mean Time).

On 4/12/23 17:27, Ross Boylan wrote:
> I tried manually deleting one of the records with type 33 in 
> recordedmarkup.  The deletion worked.  Another theory apparently shot 
> down.
>
> The forum post was about deleting recordings from the client; my 
> speculation was about failed deletion of individual database records.  
> So somewhat different.
>
> The Z in the time is kind of weird, since, as I found, it is not legal 
> input syntax.  But I think that's just an output formatting issue, 
> since the errors I'm seeing are duplicate key errors, not invalid data 
> format errors.
> Ross
>
> On Tue, Apr 11, 2023 at 7:48 PM stinga via mythtv-users 
> <mythtv-users at mythtv.org> 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
>     <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.           \\\
>     ---------------------------------------------------
>
>     _______________________________________________
>     mythtv-users mailing list
>     mythtv-users at mythtv.org
>     http://lists.mythtv.org/mailman/listinfo/mythtv-users
>     http://wiki.mythtv.org/Mailing_List_etiquette
>     MythTV Forums: https://forum.mythtv.org
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums:https://forum.mythtv.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230412/949a755f/attachment.htm>