[mythtv-users] INSERT INTO recordedmarkup fails w/duplicate; recording status changes [Workaround]
keemllib at gmail.com
Sat Apr 15 22:50:36 UTC 2023
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
> which follows the new scheme used in Maria 10.6, vs
> which follows the old scheme.
> See this proposed patch (against 10.3, however) to undo the transition
> to the new scheme, and discussion in
> 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
> 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?
> *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
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
if all is well will go in v33 and v32. It's been soaking in 2 systems with
affects. But the code is called in 2600+ places, so better to be safe.
More information about the mythtv-users