[mythtv-users] Mysql timeouts in 0.19 lead to no upcoming recordings
Michael T. Dean
mtdean at thirdcontact.com
Tue Mar 7 20:00:02 UTC 2006
On 03/07/2006 02:15 PM, Eloy A. Paris wrote:
> I think one of the reasons I missed this is that I see that this fix
> will make the need to restart mythbackend go away, for sure. However,
> I think the connection will still go away during the daily
> mythfilldatase run, as I described in my first post to this thread a
> couple of hours ago, and this is what I was focused on figuring out.
>
> I think the question still remains... why the connection dies? That the
> reconnection logic was broken is a different problem (now resolved.)
>
Basically, MySQL connections have always been timing out--even on MySQL
4.x. MySQL 4.1's (and lower versions') C API creates connections that
will automatically reconnect when the connection has timed out.
However, MySQL 5.x no longer does this--instead of assuming the
developer wants a behavior that could be unsafe depending on the
application--the developer must request a connection that will
automatically reconnect (see the last entry before User Comments on
http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html ).
Myth uses QT's MySQL driver to access the database. Since QT's MySQL
driver does not explicitly request connections that reconnect (it relies
on the defaults) and QT does not provide a way to request connections
that reconnect, Myth has to work around the problem. The changesets I
mentioned fixed the scheduler side of things and a previously-committed
changeset ( http://svn.mythtv.org/trac/changeset/8856 ) fixed the other
usages of database connections.
Mike
More information about the mythtv-users
mailing list