[mythtv-users] mythbackend "Lost connection to MySQL server during query" error?
digitalaudiorock at gmail.com
Sun Jun 13 13:42:31 UTC 2021
On 6/13/21, Bill Meek <keemllib at gmail.com> wrote:
> On 6/13/21 8:04 AM, Tom Dexter wrote:
>> I'm runing MythTV 29.1 under gentoo, with MariaDB 10.4. Yesterday
>> morning I had something happen that I've never had before. I noticed
>> that the system showed no upcoming recordings at all.
>> What I discovered in the mythbackend log was that, when the reschedule
>> was triggered by myhthfilldatabase at about 9 AM, the SQL queries all
>> failed to prepare. The first of those errors indicated a lost mysql
>> 2021-06-12 09:07:28.346179 E [1492/1708] Scheduler mythdbcon.cpp:872
>> (prepare) - Error preparing query: DELETE recordmatch FROM
>> recordmatch, channel WHERE recordmatch.chanid = channel.chanid
>> 2021-06-12 09:07:28.346221 E [1492/1708] Scheduler mythdbcon.cpp:874
>> (prepare) - Driver error was [2/2013]:
>> QMYSQL3: Unable to prepare statement
>> Database error was:
>> Lost connection to MySQL server during query
>> A simple restart of the mythbackend corrected everything.
>> On Thursday I'd run a pretty big update in gentoo, though I don't
>> think that's related, especially since everything had worked find
>> after that update. The update did include a minor update to
>> dev-db/mysql-connector-c, which I know is used by dev-qt/qtsql, but
>> again, I doubt that's related. Also note that there's no indication
>> that anything happened with mysql itself. It was running the whole
>> time without any errors etc.
>> I know that the mysql wait_timeout is 8 hours, and as it turns out,
>> the backend was in fact pretty idle for quite some time before that
>> failure. For example, the only notable activity in the log before that
>> failure was a reschedule 12 hours earlier.
>> Can a long idle period that exceeds the mysql wait_timeout cause that?
>> I'd think that if that were the case, I would have run into this
>> sometime in all the years of running MythTV.
>> Thanks in advance!
> Lots of history here, but try this one:
Oh man...yup. That's it for sure. So apparently that new mysql client
error code that MythTV isn't handling WAS in fact introduced in that
very minor update I mentioned for dev-db/mysql-connector-c. That is,
the update from 8.0.23 to 8.0.25.
Not to rant, but that seems like a pretty nasty change...introducing
new error codes that, if i understand correctly, are being used in
place of previous codes...to spring on developers in a minor version
update. Just wow.
For now at least, rather than messing with my wait_timeout or trying
to patch MythTV, I'm going back to dev-db/mysql-connector-c-8.0.23-r1.
At least under Gentoo that's easy.
Thanks for that link!
More information about the mythtv-users