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

[Ross Boylan]

A couple of different topics, but no good news.

DELETING RECORDINGS
=====================
I can't.  Ignore my earlier report this was working; it seemed to work
because the deleted recording disappears from the frontend display.
But, as in the report cited earlier, it's back after restarting the
frontend.
As in that report, there is no sign of trouble in the myth or maria
logs.  The former does show things like
Apr 14 13:05:37 barley mythbackend[401915]: 2023-04-14 13:05:37.209373
I  Reschedule requested for CHECK 0 740 0 DoHandleDelete1 | ......
but it does not show the execution of the handler I hung off the
system delete event.

The last execution of that handler seems to have been on 2023-04-04
03:23, well before the system lockup at 14:58 the same day.  It's
possible I didn't watch or delete anything in between.

So maybe this is related to the other problems I'm having.  It is
unclear to me, after reading the whole thread at
https://forum.mythtv.org/viewtopic.php?f=36&t=5349 and some of the
bugs referenced from there, what the problem is.  Some say it's the Z
on the time; others say it's the interaction of that with indexing,
others that it's in Qt (but the bugs there reference a change in Maria
10.6, and I'm on 10.5).

And my logs do not show any updates to any of the suspect packages
shortly (2 days) before the problem emerged.

REBUILD
========
I took the last presumed good backup, carved out the SQL for
recordedmarkup (and recordedseek, though I haven't used it yet),
stopped the myth backend, and updated recordedmarkup.
The first step in the update was to delete the old table.

I've attached the script I ran to extract the code, in case it helps others.

I have not issued any mythcommflag commands.  Despite that I can view
some of the shows for which the entries are now missing.

But I continue to get errors about duplicate insertions into recordedmarkup.

There are a couple of things about the generated SQL that seemed odd.
I expected there would be a separate section setting up indices; there
is not.  However, the keys are defined as part of the table creation,
and perhaps that's enough?

The backup script produced a bunch of stuff in comments; should I be
doing something with that material?  E.g.,
---------------------------------------------------------------
DROP TABLE IF EXISTS `recordedmarkup`;
/*!40101 SET @saved_cs_client     = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `recordedmarkup` (
  `chanid` int(10) unsigned NOT NULL DEFAULT 0,
  `starttime` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `mark` mediumint(8) unsigned NOT NULL DEFAULT 0,
  `type` tinyint(4) NOT NULL DEFAULT 0,
  `data` int(11) unsigned DEFAULT NULL,
  PRIMARY KEY (`chanid`,`starttime`,`type`,`mark`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_general_ci;
/*!40101 SET character_set_client = @saved_cs_client */;

--
-- Dumping data for table `recordedmarkup`
--

LOCK TABLES `recordedmarkup` WRITE;
/*!40000 ALTER TABLE `recordedmarkup` DISABLE KEYS */;
---many INSERT here
/*!40000 ALTER TABLE `recordedmarkup` ENABLE KEYS */;
UNLOCK TABLES;

-------------------------------

Ross
-------------- next part --------------
A non-text attachment was scrubbed...
Name: extract.py
Type: text/x-python
Size: 1258 bytes
Desc: not available
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20230414/127790ae/attachment.py>