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

Ross Boylan rossboylan at stanfordalumni.org
Sun Apr 9 07:50:16 UTC 2023

A few days ago my system locked up with video problems; I was able to
ssh in and execute shutdown.  But since then I see an error like this
in the logs, I think for every show I record:
Apr  8 22:06:30 barley mythbackend[2592]: 2023-04-08 22:06:30.919562 E
 DB Error (Duration insert):
Apr  8 22:06:30 barley mythbackend[2592]: Query was:
Apr  8 22:06:30 barley mythbackend[2592]: INSERT INTO recordedmarkup
 (chanid, starttime, mark, type, data)    VALUES ( 10203,
'2023-04-09T02:54:00Z', 0, 33, 7950000);
Apr  8 22:06:30 barley mythbackend[2592]: Bindings were:
Apr  8 22:06:30 barley mythbackend[2592]: :CHANID=10203,
:DATA=7950000, :STARTTIME=2023-04-09T02:54:00.000Z, :TYPE=33
Apr  8 22:06:30 barley mythbackend[2592]: Driver error was [2/1062]:
Apr  8 22:06:30 barley mythbackend[2592]: QMYSQL: Unable to execute query
Apr  8 22:06:30 barley mythbackend[2592]: Database error was:
Apr  8 22:06:30 barley mythbackend[2592]: Duplicate entry
'10203-2023-04-09 02:54:00-33-0' for key 'PRIMARY'

Type 33 is MARK_DURATION_MS according to
https://www.mythtv.org/wiki/Recordedmarkup_table.  Every one I've seen
is type 33.
To see if there was an existing  value for that index, I checked a
couple of them.  Both had an existing entry, but with a slightly
different time.  For the one above, the existing database has 7977469,
~ 27.5 s later.  For another, the existing entry was 90s earlier
(about the length of my typical lead in).

At the same time, recordings started becoming hard to access.  I have
had the displayed file size flip between ~6GB and 0 for the same
recording.  When I'm viewing things in "watch recordings" some of the
recent ones change state (regular, red, big X) while I'm looking at
the screen--not viewing a show, just looking at the listing.
Sometimes these state changes seem to be triggered by watching the
show, esp if I watch the end (tends to make the size change to 0).

I checked one of those recordings.  filesize in the recorded table was
0; however it still had a basename entry, and the recordedfile table
had the entry as well, with the correct size.  The file continued to
exist on the disk. If I try to play or delete a recording showing as 0
size the program refuses, with an error that there's nothing there.

I speculate that if I watch past the duration expected in
recordedmarkup myth decides something is wrong and changes the state.
Even if that's true, it doesn't account for all the weird behavior, or
for why 2 slightly different durations are attempted insertions.

Any ideas how to diagnose or fix this?  The behavior seems very odd; I
can't imagine why myth would want to write two different lengths of
the recording to the database.

Myth 1:31.0+fixes20220227.git7e4ce1ba98-dmo0+deb11u1 from Marillat's
repository on Debian 11/bullseye
mariadb 1:10.5.19-0+deb11u1
nvidia proprietary driver 470.161.03-1
amd64 architecture

More information about the mythtv-users mailing list