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

[Joseph Fry]

>
>
>>> <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<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.


I could have sworn that the recording rules already used the call sign
rather than channel id?  I know they used to, because I used to switch from
cable to antenna and back again whenever my cable company was running a
really good promotional bundle with my internet.

That may have changed?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120721/eef8dcb3/attachment.html>