[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