[mythtv-users] Sluggish watch recordings list after 0.27 upgrade.

[Jonatan Lindblad]

On 2013-12-10 12:48, Jamie Moore wrote:
> Hello. New to the list so I hope I'm doing this right.

Please use bottom posting rather than top posting.
See http://www.mythtv.org/wiki/Mailing_List_etiquette for more information.

> Now that I'm on-list, here's a copy/paste from an e-mail I sent to Bryan
> which might or might not shed more light on things:
>
> ---------------------------------- 8< ---------------------------------
>
> Something I have noticed, if you take an mysql log, each time you scroll
> down between recordings a number of SQL actions are fired, seemingly
> pertaining to the `jobqueue` table.
>
>
>            137 Prepare    SELECT status FROM jobqueue WHERE type = ? AND
> chanid = ? AND starttime = ?
>            137 Reset stmt
>            137 Close stmt
>            137 Prepare    SELECT status FROM jobqueue WHERE type = ? AND
> chanid = ? AND starttime = ?
>            137 Reset stmt
>            137 Close stmt
>            137 Prepare    SELECT status FROM jobqueue WHERE type = ? AND
> chanid = ? AND starttime = ?
>            137 Reset stmt
>            137 Execute    SELECT status FROM jobqueue WHERE type = 1 AND
> chanid = 2052 AND starttime = '2013-11-05 23:11:00'
>            137 Close stmt
>            137 Prepare    SELECT status FROM jobqueue WHERE type = ? AND
> chanid = ? AND starttime = ?
>            137 Reset stmt
>            137 Execute    SELECT status FROM jobqueue WHERE type = 2 AND
> chanid = 2052 AND starttime = '2013-11-05 23:11:00'
>            137 Close stmt
>            137 Prepare    SELECT status FROM jobqueue WHERE type = ? AND
> chanid = ? AND starttime = ?
>            137 Reset stmt
>            137 Close stmt
>
> [SQL continues for a hundred or so lines]
>
>
> Some of these prepare statements seem populated/executed
> 137 Execute    SELECT status FROM jobqueue WHERE type = 1 AND chanid =
> 2052 AND starttime = '2013-11-05 23:11:00'
>
>
> At any rate, a difference between a "working" system and a "broken"
> system seems to be that on the bad system, the frontend "waits" [locks?]
> while the SQL completes before /visually/ reacting to the keypress /
> remote press. I say /visually/ because if you actually press down a few
> times while it's "thinking" and wait - you end up a few programme lines
> down.
>
> ---------------------------------- 8< ---------------------------------

This sounds like http://code.mythtv.org/trac/ticket/8962.

Hopefully we'll see a fix for this in 0.28.

Cheers,
Jonatan