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

[Bill Meek]

On Saturday 15 April 2023 05:29:11 PM (-05:00), Ross Boylan wrote:

 > All of the weird behavior I've been  seeing seems to have gone away
 > when I downgraded all mariadb packages from the current stable version
 > in Debian, 1:10.5.19-0+deb11u1, to the previous stable version,
 > 1:10.5.18-0+deb11u1.*  I believe the key difference is in the version
 > information provided in
 > 
https://sources.debian.org/src/mariadb-10.5/1%3A10.5.19-0%2Bdeb11u1/libmariadb/libmariadb/mariadb_lib.c/,
 
> which follows the new scheme used in Maria 10.6, vs
 > 
https://sources.debian.org/src/mariadb-10.5/1%3A10.5.18-0%2Bdeb11u1/libmariadb/libmariadb/mariadb_lib.c/,
 
> which follows the old scheme.
 > 
 > See this proposed patch (against 10.3, however) to undo the transition
 > to the new scheme, and discussion in
 > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031863.
 > Apparently the maria 10.6 scheme reports a major version of 3, while
 > the old one reports a major version of 10, and that is throwing other
 > things off.  In particular, Qt's SQL library (libqt5sql5 on Debian)
 > gets thrown by this.  There are various proposals to patch Qt floating
 > around.
 > 
 > This change in versioning seems likely to screw up the conditional SQL
 > code we discussed a little earlier as well--in fact it makes me wonder
 > which parts of it got run.
 > 
 > Note that this maria versioning explanation is not necessarily in
 > conflict with those centering about the handling of a trailing Z in
 > the datetimestamp; the version problems may be causing the
 > datetimestamp problems.
 > 
 > This is a hack because downgrading is a hack.  Even if it works my
 > package tools want to upgrade immediately; presumably I could pin them
 > to that version.  And the newer release fixes some bugs and security
 > holes, as later releases will too.
 > 
 > More fundamentally, MariaDB is moving to the new versioning scheme,
 > and so other software using it will need to adapt.  Note there are
 > likely 3 different places that adjustments could be made to work
 > around this problem:
 > 1. myth (though it's not clear to me it can work around problems in Qt).
 > 2. Qt's SQL library.
 > 3. Maria.
 > 
 > Apart from the version info maria reports, its handling of trailing
 > Z's in datetimes could be more forgiving, particularly in keys.  Some
 > reports suggest later versions of maria can handle times with Z OK,
 > and possibly earlier versions did as well.
 > 
 > My experience seems to imply that the upgrade to maria 10.5.19, which
 > happened on 3/11 according to my logs, did not take full effect until
 > the system restarted on 4/4.  Which seems surprising, particularly
 > since my recent downgrade became effective immediately.  For the
 > recent downgrade I stopped, myth, the SQL sessions I had open, and
 > maria before downgrading.  Maybe I missed some of those steps earlier
 > (though I thought the packaging system itself stops maria before
 > changing it). Perhaps myth checks maria version info when it starts,
 > and I didn't restart myth?
 > 
 > Ross
 > 
 > *I downgraded them all together out of caution and deference to prior
 > admonitions in another thread to do them all together.  It might be
 > that downgrading libmariadb3 alone, which I believe is where the
 > version reporting code lives, would suffice.  But that's riskier, and
 > the packaging system might not even support it.  BTW, "stable" is an
 > attribute of the entire distribution, not a particular package.
 > "stable" is the mainline version of Debian = Debian 11 = bullseye.
 > Packages in it are supposed to keep a consistent API even if upgraded
 > for critical fixes.  The maria packages obviously have not managed
 > that.

Monday a fix will be pushed tomaster that guarantees that the timezone (Z)
is removed from DATETIME values (like starttime). It will soak for a week 
and
if all is well will go in v33 and v32. It's been soaking in 2 systems with 
no ill
affects. But the code is called in 2600+ places, so better to be safe.
-- 
Bill