[mythtv-users] 0.25 SQL CPU Load issues after optimisation

[Mike Perkins]

On 20/07/12 22:54, Another Sillyname wrote:
> 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
>> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
> 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.
>
That raises an important question that wouldn't have bothered us in the old 
analog days.

In the digital world, channels are getting moved about on a fairly frequent 
basis which means we end up rescanning more than we used to. End result: CHANID 
for any particular channel can get changed from time to time.

This means that "record on channel xxx" rules are likely not going to work after 
a scan. I have some of these, and they are a pain to try and figure out which 
channel they referred to, as they display as "Record on channel ." - that is, 
the history is gone.

Is there any chance that in the future these rules won't be tied to CHANID but 
some other identifier like CALLSIGN, perhaps? (Remembering for those of you in 
the US that CALLSIGN can be a /lot/ longer than 5-6 characters elsewhere in the 
world.) Not necessarily CALLSIGN itself, perhaps, but a uniqueid indexed on 
CALLSIGN.

-- 

Mike Perkins