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

[Joseph Fry]

>
> >>> 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.
> >
> >
> > Yes, this is why "this channel" rules are generally discouraged--because
> > they require you to re-create the rules after any changes to your
> channels.
> >
> >
> >> 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.
> >
> >
> > FWIW, they are tied to callsign--the callsign of the channel referenced
> by
> > the given ID.  Note, also, that on rescanning it's /quite/ common for
> > callsign to change, too--so changing the code/DB to reference callsign or
> > station would only trade one problem for another, and you'd almost
> > definitely have to keep re-creating any "this channel" rules.
> >
> > "Any channel" rules work before and after rescans, regardless of what
> > changes.
> >
> > Mike
> >
> > _______________________________________________
> > mythtv-users mailing list
> > mythtv-users at mythtv.org
> > http://www.mythtv.org/mailman/listinfo/mythtv-users
>
> The other side of the equation is that "record on any channel" can be
> a problem where you have multiple similar channels....
>
> For example in the UK you can have...
>
> BBC 1
> BBC 1 HD
> BBC 1 Scotland
> BBC 1 Wales
> BBC 1 Northern Ireland
> 301 Red Button Sports Event
>
> or
>
> Channel 4
> Channel 4 +1 - 1 Hour timeshift
> Channel 4 HD
> More 4
> More 4 +1
>
> In the BBC case 95% of the programming is identical but sometimes a
> sports event will only be covered on the regional channel, say for
> example a Scottish football game would only be on BBC Scotland.
>
> During the Olympics the BBC are also transmitting on an extra 20
> channels for Olympics coverage - No that's not a typo it's an extra 20
> channels.
>
> In the case of Channel 4 programmes shown on Channel 4 will be
> simulshown on the HD version and shown on the +1 channel an hour
> later.  They can also be shown later that week on the More 4 channel,
> usually with the same PROGID but occasionally a different PROGID.
>
> So mythweb can become incredibly cluttered with non recording versions
> of a program if you don't use the 'record on this channel only'
> option.
>
> I appreciate what you're saying but please don't think people aren't
> having to use 'this channel only' for a reason.
>
>
I use ONLY "record on any channel" schedules, and the majority of my shows
are shown in SD on 2 channels (analog cable, digital cable) and in HD on 2
other channels (HD antenna, HD digital cable).  Using recording priorities,
channel priorities, and other options, I can tweak things so that it always
records the highest quality recording (usually HD antenna) possible for a
particular show... if there are conflicts with a higher priority show, it
will bump down to the next highest, and so on.

The only time that you MIGHT see redundant recordings is if the PROGID and
description are different... or, sometimes the program details were not
available at last mythfilldatabase run, so it tries to record all of them
with generic show information.  I have eliminated that problem creating a
cron job to run mythfilldatabase --refresh-today at 5pm everyday (chosen
because the problem was only occurring with primetime shows).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mythtv.org/pipermail/mythtv-users/attachments/20120723/1f30334d/attachment.html>