[mythtv-users] 0.25 SQL CPU Load issues after optimisation
anothersname at googlemail.com
Fri Jul 20 21:54:32 UTC 2012
On 20 July 2012 21:35, Gary Buhrmaster <gary.buhrmaster at gmail.com> wrote:
> On Fri, Jul 20, 2012 at 8:03 PM, Another Sillyname
> <anothersname at googlemail.com> wrote:
>> Anything obviously wrong here?
> Other than I hate wrapped lines, not really.
> But I notice the 753 recording rule (estimated) number. That is a large
> number (much larger than I have by 1.5 orders of magnitude). My WAG
> is that will that many rules, and the select using bit manipulation for
> checks, this is just an intense operation.
> The first thing I would do is review those rules to see if you can
> eliminate or simplify your recording rules substantially.
> mythtv-users mailing list
> mythtv-users at mythtv.org
Sorry about wrapped lines, using gmail web frontend......
That looks like it's given me a fix.....
I cleaned up the rules and while doing so came across something that
could be a conflict.
When I originally built the system as a combined Freeview and Freesat
service the CHANID values get set according to the order that the
source device is chosen.
In my original build I'd actually scanned the DVB-T channels twice
from two different DVB-T tuners as I didn't realise that the source
could be shared by the other tuners. So then when I scanned the DVB-S
channels there was a 4000 offset for the SID and therefore CHANID, for
example BBC HD which has a SID of 6940 got allocated a CHANID of 10940
to allow for the offset.
When I did the recent rebuild I didn't make the same error so the SID
and CHANID were instead 8940 rather then the original 10940. This
means the database had recording rules for CHANID values that just
didn't exist in the database anymore.
I've cleaned the rules down from 750+ to about 150 and will monitor
for a few more days, if I'm right it'll be worth putting this into the
wiki so it doesn't catch out other users later.
Fingers crossed but good job guys.
More information about the mythtv-users