Idle frontend "wakeup" delay

[stichnot@…]

Several users have noticed that sometimes when the frontend has been idle for a while, there is an extra 5-second delay in loading pages like Watch Recordings. This seems to be due to something in Qt's mysql driver, which apparently keeps track of the number of open DB connections, and when it hits 0, calls my_thread_global_end(). The mysql library then assumes the application is ending and that all threads that created DB connections have already exited. This is rarely true, and may result in the mysql library pausing 5 seconds and printing a message like "Error in my_thread_global_end(): 1 threads didn't exit".

The PurgeIdleConnections?() routine deletes all pooled DB connections that have been idle for more than an hour, and may trigger this 5-second delay. I have seen this when selecting Watch Recordings and MythVideo?, and also sometimes when exiting playback.

This patch simply creates an extra DB connection before all pooled connections are purged so that my_thread_global_end() won't be called.

To try to reproduce the delays, and for helping to verify this fix, I recommend changing the idle timeout in PurgeIdleConnections?() from 3600 seconds to 15 seconds, to trigger the purge far more frequently.

[stichnot@…]

I forgot to say a couple things about this patch.

First, my fix triggered an existing bug in the MDBManager class. The m_connID field was being used for two purposes: to keep track of the number of existing DB connections, and to create a unique connection name for new DB connections. This could potentially allow a new connection to be opened with an existing connection's name, causing the existing connection to be closed. I separated out this field into two different fields. I suppose this means something like bumping the binary version.

Second, it seems that a cleaner solution may be to create a separate thread to do all the opening and closing of DB connections. I started out on that path, but it seemed like an awful lot of machinery to deal with a small oddity in the mysql driver, so I took this simpler approach instead.

[danielk]

(In [23057]) Fixes #7836. Open one new connection in MDBManager::PurgeIdleConnections?() if all connections are to be closed. This avoids an issue with the Qt mysql driver where it assumes that if all connections are close it should shut down entirely, which causes a long delay when we next want to connect to the DB.

[warpme@…]

stichnot,

Big thanx for this patch. It allows to increase WAF significantly as this 5 sec delay after FE resume from sleep was quite annoying.

If we are speaking about FEs used in sleep-resume way - I see another issue which is quite annoying: -after S3 resume, scheduling via EPG isn't refreshed on EPG.

Scenario to reproduce: 1.Start system, launch FE. 2.Enter system into S3 sleep for longer than approx 15min. 3.Resume system form S3 sleep. 4.Go to EPG. 5.Select show and press Enter. 6.Choose desirable schedule options, press Save. 7.After return to EPG there is no this show refreshed state.

EPG refresh is working OK if sleep is shorter than approx 15 min, so it looks like sleeping longer that approch 15 minutes somehow broke FE-BE communication.

This issue is quite annoying and strongly decreasing WAF, as scheduling via EPG hasn't feedback to user (and my wife is complying that myth is not recording her lovely shows...)

As 7836 seems to be closed - should I fill separate bug report for this issue ?

br

[noisymime@…]

It may not be (easily) possible, but any chance of a backport of this to 0.22-fixes? The issue is certainly affecting 0.22 and is a really frustrating problem for those on the stable revisions.