Mailing List Archive

1 2  View All
Re: Recordings not working [ In reply to ]
On 5/23/21 12:55 PM, Gary Buhrmaster wrote:
> On Sun, May 23, 2021 at 5:53 PM Gary Buhrmaster
> <gary.buhrmaster@gmail.com> wrote:
>
>> Perhaps someone wants to try to add ...
>
> Or, alternatively, start by adding in additional
> debugging logging in that area to report
> what is really going on to know if adding a
> 2013 is the right thing to do, or something
> far more interesting is happening.

Setting wait_timeout = 300 was a great idea, I think.

I also added the check for 2013 and logged the case for 2006 || 2013
results. Unfortunately, I didn't get a log entry.

It appears that I can duplicate the issue now, so I'll start moving the
LOG(...) around.

Thanks for the ideas.
--
Bill
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On 5/23/21 12:55 PM, Gary Buhrmaster wrote:
> On Sun, May 23, 2021 at 5:53 PM Gary Buhrmaster
> <gary.buhrmaster@gmail.com> wrote:
>
>> Perhaps someone wants to try to add ...
>
> Or, alternatively, start by adding in additional
> debugging logging in that area to report
> what is really going on to know if adding a
> 2013 is the right thing to do, or something
> far more interesting is happening.

nativeErrorCode 4031. Adding this seems to fix the problem.

I've only tested a bit and not on my production host.

I asked if anyone on the forum was building from source a few hours
ago, but haven't had any responses yet.

https://dev.mysql.com/doc/mysql-errors/8.0/en/server-error-reference.html

Error number: 4031; Symbol: ER_CLIENT_INTERACTION_TIMEOUT; SQLSTATE: HY000

Message: The client was disconnected by the server because of inactivity. See wait_timeout
and interactive_timeout for configuring this behavior.

ER_CLIENT_INTERACTION_TIMEOUT was added in 8.0.24.

I [35051/35069] Scheduler scheduler.cpp:2309 (HandleReschedule) - Reschedule requested for MATCH 0 0 0 - MythUtilCommand
I [35051/35069] Scheduler mythdbcon.cpp:879 (prepare) - Prepare: Native Error Code: 4031 <-My test LOG()
I [35051/35069] Scheduler mythdbcon.cpp:260 (Reconnect) - MySQL reconnected successfully

--
Bill
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On Mon, May 24, 2021 at 4:15 AM Bill Meek <keemllib@gmail.com> wrote:

> nativeErrorCode 4031. Adding this seems to fix the problem.

Good catch. Now that one knows what to
look for It turns out a number of projects
using the oracle connector library were caught
by this change, and now need to handle
ER_CLIENT_INTERACTION_TIMEOUT
in addition to any other possible errors.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On Mon, 24 May 2021 09:02:24 +0000, you wrote:

>On Mon, May 24, 2021 at 4:15 AM Bill Meek <keemllib@gmail.com> wrote:
>
>> nativeErrorCode 4031. Adding this seems to fix the problem.
>
>Good catch. Now that one knows what to
>look for It turns out a number of projects
>using the oracle connector library were caught
>by this change, and now need to handle
>ER_CLIENT_INTERACTION_TIMEOUT
>in addition to any other possible errors.

And until this fix makes its way into the MythTV code, I can confirm
that my workaround of running "mythutil --resched" from a systemd
timer every hour works. My mother's MythTV box had a 12 hour gap with
no recordings over last night and this morning, and with the
workaround it kept on going without problems.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On Mon, May 24, 2021 at 12:42 PM Stephen Worthington
<stephen_agent@jsw.gen.nz> wrote:

> And until this fix makes its way into the MythTV code, I can confirm
> that my workaround of running "mythutil --resched" from a systemd
> timer every hour works.

And on the mythtv forums, it was validated that
downgrading the libmysqlclient to the previous
bugfix version (before 8.0.24) works too.

I would have thought that an API impacting
change would not be introduced in a patch
(bugfix) update, but apparently some dev
in the Oracle org decided differently.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On 5/24/21 12:37 PM, Gary Buhrmaster wrote:
> On Mon, May 24, 2021 at 12:42 PM Stephen Worthington
> <stephen_agent@jsw.gen.nz> wrote:
>
>> And until this fix makes its way into the MythTV code, I can confirm
>> that my workaround of running "mythutil --resched" from a systemd
>> timer every hour works.
>
> And on the mythtv forums, it was validated that
> downgrading the libmysqlclient to the previous
> bugfix version (before 8.0.24) works too.
>
> I would have thought that an API impacting
> change would not be introduced in a patch
> (bugfix) update, but apparently some dev
> in the Oracle org decided differently.

Updated the ticket on Github a few minutes ago: https://github.com/MythTV/mythtv/issues/359#issuecomment-847218531

Interesting that MariaDB uses error code for something else: ER_REFERENCED_TRG_DOES_NOT_EXIST.

--
Bill
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On Mon, May 24, 2021 at 5:47 PM Bill Meek <keemllib@gmail.com> wrote:

> Interesting that MariaDB uses error code for something else: ER_REFERENCED_TRG_DOES_NOT_EXIST.

Thanks for the update.

We have known (and seen) for quite some
time that MySQL and MariaDB were diverging
causing issues(*).

While not perfect, since MythTV does not
(currently?) use triggers, it would seem to
me that it probably will not hurt to just test
for 4031 (along with the other timeout/gone
values) and attempt the reconnect (with
a comment that 4031 is problematic due
to divergence?).

At some point, it may be necessary to
do something like a "Select version();"
after the initial connect and remember
which vendor type the app is talking to
in order to perform vendor specific
checks.


(*) There is a list of incompatibilities
on the MariaDB site at:

https://mariadb.com/kb/en/mariadb-vs-mysql-compatibility/
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On 24/05/2021 20:29, Gary Buhrmaster wrote:
> On Mon, May 24, 2021 at 5:47 PM Bill Meek <keemllib@gmail.com> wrote:
>
>> Interesting that MariaDB uses error code for something else: ER_REFERENCED_TRG_DOES_NOT_EXIST.
>
> Thanks for the update.
>
> We have known (and seen) for quite some
> time that MySQL and MariaDB were diverging
> causing issues(*).
>

I would like to report that this issue does not only affect the backend
but also the frontend.

I just came back to a frontend that had been left running for many
hours, but was idle, and it could not find any recordings. The frontend
log also contains the signature "Error preparing query" lines.

I will update the bug with this information.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On 5/25/21 7:35 AM, Jan Ceuleers wrote:
> On 24/05/2021 20:29, Gary Buhrmaster wrote:
>> On Mon, May 24, 2021 at 5:47 PM Bill Meek <keemllib@gmail.com> wrote:
>>
>>> Interesting that MariaDB uses error code for something else: ER_REFERENCED_TRG_DOES_NOT_EXIST.
>>
>> Thanks for the update.
>>
>> We have known (and seen) for quite some
>> time that MySQL and MariaDB were diverging
>> causing issues(*).
>>
>
> I would like to report that this issue does not only affect the backend
> but also the frontend.
>
> I just came back to a frontend that had been left running for many
> hours, but was idle, and it could not find any recordings. The frontend
> log also contains the signature "Error preparing query" lines.
>
> I will update the bug with this information.

Thanks for the info. I don't think we need new data.

The fix is pretty simple, but it's in common code used for
database access. It's currently repeated 3x and I decided
to put it all in 1 place. Also added logging that can
be turned on with general:debug to make it easier if/when this
happens again. So far, on master, my test 20.04 test host
and (unaffected) 18.04 production host are happy with it.

The fix will be against master and after some soak time in the
wild, be back ported to v31.0

I don't have a host with MariaDB handy (and there are reports
that it's affected) and no takers to test the fix there.

In the mean time, you can use the solution in the ticket or on
the Forum to increase wait_timeout. Increasing from the default
8 hours to 48 hours has made everyone happy (happier).

--
Bill
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On Tue, May 25, 2021 at 1:48 PM Bill Meek <keemllib@gmail.com> wrote:

> The fix is pretty simple, but it's in common code used for
> database access. It's currently repeated 3x and I decided
> to put it all in 1 place. Also added logging that can
> be turned on with general:debug to make it easier if/when this
> happens again. So far, on master, my test 20.04 test host
> and (unaffected) 18.04 production host are happy with it.

Have you considered adding in something like

db.setConnectOptions("MYSQL_OPT_RECONNECT=1");

to ask Qt (well, the MySQL connector) to automatically
reconnect?

Something equivalent was done in the zoneminder
plugin at one point (if my memory is not totally
misremembering).

I am not sure it will work appropriately here (one
would hope that the oracle client library will do the
right thing here(*)), but it may help in at least some
other cases, and might even eliminate the need
for MythTV to attempt the reconnect itself.

> I don't have a host with MariaDB handy (and there are reports
> that it's affected) and no takers to test the fix there.

It is the oracle mysql client library where the change
was introduced, which is why it impacts all server
types (no matter your server type, unless you go out
of your way to install the mariadb client library, you
get the oracle mysql client library in ubuntu).

But certainly it would be nice for someone to
personally validate that, rather than just going on
the theory.





(*) I vaguely recall a different bug in the oracle
mysql client which broke auto reconnect, but
it was recognized as a bug and resolved. It
is software, there will be bugs.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On 25/05/2021 16:38, Gary Buhrmaster wrote:

>
> Have you considered adding in something like
>
> db.setConnectOptions("MYSQL_OPT_RECONNECT=1");
>
> to ask Qt (well, the MySQL connector) to automatically
> reconnect?
>
> Something equivalent was done in the zoneminder
> plugin at one point (if my memory is not totally
> misremembering).
>

mythzmserver doesn't use Qt so connects to the ZM DB through the client
library. It does set the reconnect flag but for reliability it still
periodically kicks the DB by sending a dummy "SELECT NULL;" query. It's
very possible that kicking the DB is not required anymore with newer
versions of the client library but I've not tried it.


Paul H.

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On Tue, May 25, 2021 at 5:01 PM Paul Harrison <mythtv@mythqml.net> wrote:

> mythzmserver doesn't use Qt so connects to the ZM DB through the client
> library. It does set the reconnect flag but for reliability it still
> periodically kicks the DB by sending a dummy "SELECT NULL;" query.

As I recall, old (no longer supported?) versions
of mysql automatically reconnected, and then
it was changed to not auto reconnect to avoid
resetting transaction state out from under the
applications without notice, and the option was
made available to revert to the previous behavior.
Belt and suspenders in MythTV was almost
certainly the best (only?) choice during those
various transitions of mysql versions.

> It's very possible that kicking the DB is not
> required anymore with newer versions of the
> client library but I've not tried it.

If the code works, the old adage of not
"improving" it often applies.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On 5/25/21 12:30 PM, Gary Buhrmaster wrote:
> On Tue, May 25, 2021 at 5:01 PM Paul Harrison <mythtv@mythqml.net> wrote:
>
>> mythzmserver doesn't use Qt so connects to the ZM DB through the client
>> library. It does set the reconnect flag but for reliability it still
>> periodically kicks the DB by sending a dummy "SELECT NULL;" query.
>
> As I recall, old (no longer supported?) versions
> of mysql automatically reconnected, and then
> it was changed to not auto reconnect to avoid
> resetting transaction state out from under the
> applications without notice, and the option was
> made available to revert to the previous behavior.
> Belt and suspenders in MythTV was almost
> certainly the best (only?) choice during those
> various transitions of mysql versions.
>
>> It's very possible that kicking the DB is not
>> required anymore with newer versions of the
>> client library but I've not tried it.
>
> If the code works, the old adage of not
> "improving" it often applies.

Just pushed a fix for master. I'll let it soak for some time
before back porting to v31.0.

Users that have the wait_timeout timeout work around should remove it,
or you can set it to a few minutes to have the disconnect happen more
often. mythbackend --seterbose general:debug will allow a new log
message: ...mythdbcon.cpp:947 (lostConnectionCheck) - SQL Native Error Code: n.
The code will be 4031 for 20.04 users with mysql* 8.0.25 or 2006 if
that fix isn't in yet.

It's only slightly improved (in my opinion about the slightly and
or improved parts).

Looking at git log -p mythtv/libs/libmythbase/mythdbcon.cpp,
I believe if reconnecting is successful, the query is retried.
Several changes to improve this were done log ago.

--
Bill
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On 25/05/2021 18:57, Bill Meek wrote:
> On 5/25/21 12:30 PM, Gary Buhrmaster wrote:
>> On Tue, May 25, 2021 at 5:01 PM Paul Harrison <mythtv@mythqml.net> wrote:
>>
>>> mythzmserver doesn't use Qt so connects to the ZM DB through the client
>>> library. It does set the reconnect flag but for reliability it still
>>> periodically kicks the DB by sending a dummy "SELECT NULL;" query.
>>
>> As I recall, old (no longer supported?) versions
>> of mysql automatically reconnected, and then
>> it was changed to not auto reconnect to avoid
>> resetting transaction state out from under the
>> applications without notice, and the option was
>> made available to revert to the previous behavior.
>> Belt and suspenders in MythTV was almost
>> certainly the best (only?) choice during those
>> various transitions of mysql versions.
>>
>>> It's very possible that kicking the DB is not
>>> required anymore with newer versions of the
>>> client library but I've not tried it.
>>
>> If the code works, the old adage of not
>> "improving" it often applies.
>
> Just pushed a fix for master. I'll let it soak for some time
> before back porting to v31.0.
>
> Users that have the wait_timeout timeout work around should remove it,
> or you can set it to a few minutes to have the disconnect happen more
> often. mythbackend --seterbose general:debug will allow a new log
> message: ...mythdbcon.cpp:947 (lostConnectionCheck) - SQL Native Error Code: n.
> The code will be 4031 for 20.04 users with mysql* 8.0.25 or 2006 if
> that fix isn't in yet.
>
> It's only slightly improved (in my opinion about the slightly and
> or improved parts).
>
> Looking at git log -p mythtv/libs/libmythbase/mythdbcon.cpp,
> I believe if reconnecting is successful, the query is retried.
> Several changes to improve this were done log ago.
>

Perhaps I ought to report that my two boxes running master with MariaDB
have not had this problem; I guess that using EIT has kept the DBs
connected.

MariaDB versions 10.4.19 Fedora 33, 5.5.68 (!!) el7



_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On Tue, May 25, 2021 at 8:25 PM John Pilkington <johnpilk222@gmail.com> wrote:

> Perhaps I ought to report that my two boxes running master with MariaDB
> have not had this problem; I guess that using EIT has kept the DBs
> connected.
>
> MariaDB versions 10.4.19 Fedora 33, 5.5.68 (!!) el7

Useful data points, and as expected.

The best current understanding of the root cause is that
this is a mysql (not mariadb) client library issue (and
is independent of which server type (mysql or mariadb)
one uses) and was introduced into the mysql client library
with the 8.0.24 version, and ubuntu made available the
8.0.25 version to replace their 8.0.23 version a bit more
than ten days ago which is when the problem was first
experienced. While one can override various defaults
on platforms, I think pretty much only ubuntu (of the more
well known distributions) uses the mysql client library
(rather than the mariadb client library) as the default for
new(er) installs.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On Tue, 2021-05-25 at 21:24 +0100, John Pilkington wrote:
> On 25/05/2021 18:57, Bill Meek wrote:
> > On 5/25/21 12:30 PM, Gary Buhrmaster wrote:
> > > On Tue, May 25, 2021 at 5:01 PM Paul Harrison
> > > <mythtv@mythqml.net> wrote:
> > >
> > > > mythzmserver doesn't use Qt so connects to the ZM DB through
> > > > the client
> > > > library. It does set the reconnect flag but for reliability it
> > > > still
> > > > periodically kicks the DB by sending a dummy "SELECT NULL;"
> > > > query.
> > >
> > > As I recall, old (no longer supported?) versions
> > > of mysql automatically reconnected, and then
> > > it was changed to not auto reconnect to avoid
> > > resetting transaction state out from under the
> > > applications without notice, and the option was
> > > made available to revert to the previous behavior.
> > > Belt and suspenders in MythTV was almost
> > > certainly the best (only?) choice during those
> > > various transitions of mysql versions.
> > >
> > > > It's very possible that kicking the DB is not
> > > > required anymore with newer versions of the
> > > > client library but I've not tried it.
> > >
> > > If the code works, the old adage of not
> > > "improving" it often applies.
> >
> > Just pushed a fix for master. I'll let it soak for some time
> > before back porting to v31.0.
> >
> > Users that have the wait_timeout timeout work around should remove
> > it,
> > or you can set it to a few minutes to have the disconnect happen
> > more
> > often. mythbackend --seterbose general:debug will allow a new log
> > message: ...mythdbcon.cpp:947 (lostConnectionCheck) - SQL Native
> > Error Code: n.
> > The code will be 4031 for 20.04 users with mysql* 8.0.25 or 2006 if
> > that fix isn't in yet.
> >
> > It's only slightly improved (in my opinion about the slightly and
> > or improved parts).
> >
> > Looking at git log -p mythtv/libs/libmythbase/mythdbcon.cpp,
> > I believe if reconnecting is successful, the query is retried.
> > Several changes to improve this were done log ago.
> >
>
> Perhaps I ought to report that my two boxes running master with
> MariaDB
> have not had this problem; I guess that using EIT has kept the DBs
> connected.
>
> MariaDB versions 10.4.19 Fedora 33, 5.5.68 (!!) el7
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://email.mg.glenb.net/c/eJxNjk0OwiAUhE9TdhJ4_HbBwo33AB60JFBNQRNvbzUmmsxmvplJBl3MHpUkxWmpebImq8gNYlA6oxUzSOu1tRCVidGHiJxG31KdJFtq2gLd0iCr42JmDJgQWeUQECSDzABTTCAxGE-qW8e4TeI8weVQLX102p5jHQ963ZcDNV9q89s3LFu-vuGncbr3tHeyu397PPjtX-s3QQM
> http://email.mg.glenb.net/c/eJxFjUEOgjAQRU8DOxtapqUsunDjSs9g2ukUGgsqDBpvL4kLk796eS8_Okw-aqizM2Ak2S5plF2MQZsUbdsrsN5Yq1B3iD5glAL9RKWCZig0BzET16OTkKAzUvnWA-xNA1Y3DUKvY-qDp7q4kflRtcdKnfa98y2L6cMjv8R9GXZy8bnkebie88pX4vzciJnqxf2sw7bSsu6v_-gLyRw8SQ
> MythTV Forums: http://email.mg.glenb.net/c/eJxFjDkKwzAQAF9jdRG2vKujUJEm_5B2V3bAR5DlQH4fQ4rANMPAcKSSGEE9owU7iHcFaXDMGW1hPwYDPlnvDaEjSpl40JRWWTrop0W2rDdpao4INpBLYkcySGQLSIAeMgo7DJLUEufWXkc33jvzuCh7PVe9ftrc3nqvk6rxJ7fzkHpc-3_7AhJwNHY

same here running 31/fixes on arch. using mariadb 10.5.10 and mariadb-
clients 10.5.10. no problems seen. 
Re: Recordings not working [ In reply to ]
On 05/25/2021 11:38 AM, Gary Buhrmaster wrote:
> On Tue, May 25, 2021 at 1:48 PM Bill Meek <keemllib@gmail.com> wrote:
>
>> The fix is pretty simple, but it's in common code used for
>> database access. It's currently repeated 3x and I decided
>> to put it all in 1 place. Also added logging that can
>> be turned on with general:debug to make it easier if/when this
>> happens again. So far, on master, my test 20.04 test host
>> and (unaffected) 18.04 production host are happy with it.
> Have you considered adding in something like
>
> db.setConnectOptions("MYSQL_OPT_RECONNECT=1");
>
> to ask Qt (well, the MySQL connector) to automatically
> reconnect?

We had that in there ( https://github.com/MythTV/mythtv/commit/dd2d7a14d
), then Daniel K removed it in a rework of the reconnect logic (
https://github.com/MythTV/mythtv/commit/4dfcdb8dd ).

Mike



_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On 5/26/21 7:05 AM, Michael T. Dean wrote:
> On 05/25/2021 11:38 AM, Gary Buhrmaster wrote:
>> On Tue, May 25, 2021 at 1:48 PM Bill Meek <keemllib@gmail.com> wrote:
>>
>>> The fix is pretty simple, but it's in common code used for
>>> database access. It's currently repeated 3x and I decided
>>> to put it all in 1 place. Also added logging that can
>>> be turned on with general:debug to make it easier if/when this
>>> happens again. So far, on master, my test 20.04 test host
>>> and (unaffected) 18.04 production host are happy with it.
>> Have you considered adding in something like
>>
>>      db.setConnectOptions("MYSQL_OPT_RECONNECT=1");
>>
>> to ask Qt (well, the MySQL connector) to automatically
>> reconnect?
>
> We had that in there ( https://github.com/MythTV/mythtv/commit/dd2d7a14d ), then Daniel K removed it in a rework of the reconnect logic (
> https://github.com/MythTV/mythtv/commit/4dfcdb8dd ).
>
> Mike

The v31 fix has been pushed. See: https://forum.mythtv.org/viewtopic.php?f=36&t=4453&p=22004#p22004
for more info.

--
Bill
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
>
> The v31 fix has been pushed. See:
> https://forum.mythtv.org/viewtopic.php?f=36&t=4453&p=22004#p22004
> for more info.


No issues in the last couple of days. I think you've nailed it.

Thanks Bill.

Cheers,
Justin.
Re: Recordings not working [ In reply to ]
On 5/24/21, Gary Buhrmaster <gary.buhrmaster@gmail.com> wrote:
> On Mon, May 24, 2021 at 12:42 PM Stephen Worthington
> <stephen_agent@jsw.gen.nz> wrote:
>
>> And until this fix makes its way into the MythTV code, I can confirm
>> that my workaround of running "mythutil --resched" from a systemd
>> timer every hour works.
>
> And on the mythtv forums, it was validated that
> downgrading the libmysqlclient to the previous
> bugfix version (before 8.0.24) works too.
>
> I would have thought that an API impacting
> change would not be introduced in a patch
> (bugfix) update, but apparently some dev
> in the Oracle org decided differently.

Wow...you've got that right. I just got burned by this on my Gentoo
backend with the update of dev-db/mysql-connector-c from 8.0.23-r1 to
8.0.25. Until I read everything around this issue, I assumed that
minor upgrade couldn't possibly be related.

For reasons I won't get into, I'm still running MythTV 29.1, and the
patch for this would need major rework for that, so for now I just
downgraded dev-db/mysql-connector-c.

But yea...a non-backward compatible API change in a minor version
bump?? Only a developer with no clue as to what an "API" is would pull
that crap.

You know...some time back I switched all my systems from MySQL to
MariaDB and couldn't be happier with it. This makes me wish they'd
fork the client code as well, so we can get the idiots at Oracle out
of the picture entirely....maybe this inexcusable bullshit wouldn't
occur.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On Sun, Jun 13, 2021 at 3:36 PM Tom Dexter <digitalaudiorock@gmail.com> wrote:

> You know...some time back I switched all my systems from MySQL to
> MariaDB and couldn't be happier with it. This makes me wish they'd
> fork the client code as well, so we can get the idiots at Oracle out
> of the picture entirely....maybe this inexcusable bullshit wouldn't
> occur.

They did. The mariadb-connector-c library exists
on most distros, but it may not automatically
replace the mysql connector library for existing
installations in all cases (typically the two
connector libraries are going to be marked as
conflicting, so how that is handled will vary).

That is why (primarily) this was seen on ubuntu
systems as that is the only major distro who has
continued to default to mysql long after others
moved to mariadb.

On the other hand, there was a case where the
mariadb connector did not work with a change
to mysql for a time until corrected, so mixing
and matching can result in at least short term
pain during any update until something gets
fixed.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Recordings not working [ In reply to ]
On 6/13/21, Gary Buhrmaster <gary.buhrmaster@gmail.com> wrote:
> On Sun, Jun 13, 2021 at 3:36 PM Tom Dexter <digitalaudiorock@gmail.com>
> wrote:
>
>> You know...some time back I switched all my systems from MySQL to
>> MariaDB and couldn't be happier with it. This makes me wish they'd
>> fork the client code as well, so we can get the idiots at Oracle out
>> of the picture entirely....maybe this inexcusable bullshit wouldn't
>> occur.
>
> They did. The mariadb-connector-c library exists
> on most distros, but it may not automatically
> replace the mysql connector library for existing
> installations in all cases (typically the two
> connector libraries are going to be marked as
> conflicting, so how that is handled will vary).
>
> That is why (primarily) this was seen on ubuntu
> systems as that is the only major distro who has
> continued to default to mysql long after others
> moved to mariadb.
>
> On the other hand, there was a case where the
> mariadb connector did not work with a change
> to mysql for a time until corrected, so mixing
> and matching can result in at least short term
> pain during any update until something gets
> fixed.

Ahhh, yes you're totally correct. It's been long enough since I
switched that I totally forgot about all that. It was a bit of a
confusing mess for me in fact. As it turns out I have both connectors
installed on my MythTV systems. dev-perl/DBD-mysql is actually using
mariadb-connector-c, but (at least in Gentoo) currently dev-qt/qtsql
has a hard requirement for dev-db/mysql-connector-c.

Tom
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

1 2  View All