Mailing List Archive: MythTV: Users

0.25 SQL CPU Load issues after optimisation

1 2

View All

Index | Next | Previous | View Threaded

gary.buhrmaster at gmail

Jul 20, 2012, 1:35 PM

Post #26 of 39 (603 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

On Fri, Jul 20, 2012 at 8:03 PM, Another Sillyname
<anothersname [at] googlemail> 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
http://www.mythtv.org/mailman/listinfo/mythtv-users

anothersname at googlemail

Jul 20, 2012, 2:54 PM

Post #27 of 39 (597 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

On 20 July 2012 21:35, Gary Buhrmaster <gary.buhrmaster [at] gmail> wrote:
> On Fri, Jul 20, 2012 at 8:03 PM, Another Sillyname
> <anothersname [at] googlemail> 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
> 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.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mikep at randomtraveller

Jul 21, 2012, 3:24 AM

Post #28 of 39 (593 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

On 20/07/12 22:54, Another Sillyname wrote:
> On 20 July 2012 21:35, Gary Buhrmaster <gary.buhrmaster [at] gmail> wrote:
>> On Fri, Jul 20, 2012 at 8:03 PM, Another Sillyname
>> <anothersname [at] googlemail> 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
>> 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

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

joe at thefrys

Jul 21, 2012, 4:32 PM

Post #29 of 39 (586 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

>
>
>>> <anothersname [at] googlemail> 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
>>> 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?

mtdean at thirdcontact

Jul 23, 2012, 7:02 AM

Post #30 of 39 (571 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

On 07/21/2012 06:24 AM, Mike Perkins wrote:
> On 20/07/12 22:54, Another Sillyname wrote:
>> 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
http://www.mythtv.org/mailman/listinfo/mythtv-users

anothersname at googlemail

Jul 23, 2012, 8:14 AM

Post #31 of 39 (574 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

On 23 July 2012 15:02, Michael T. Dean <mtdean [at] thirdcontact> wrote:
> On 07/21/2012 06:24 AM, Mike Perkins wrote:
>>
>> On 20/07/12 22:54, Another Sillyname wrote:
>>>
>>> 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
> 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.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mtdean at thirdcontact

Jul 23, 2012, 8:35 AM

Post #32 of 39 (572 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

On 07/23/2012 11:14 AM, Another Sillyname wrote:
> 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.

That's why there's an option to show or not show the Deactivated
recordings in MythWeb's Upcoming Recording page. Unchecking the option
removes all those "Earlier"/"Later" showings.

Mike
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

joe at thefrys

Jul 23, 2012, 10:39 AM

Post #33 of 39 (563 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

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

anothersname at googlemail

Jul 23, 2012, 10:40 AM

Post #34 of 39 (568 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

On 23 July 2012 16:35, Michael T. Dean <mtdean [at] thirdcontact> wrote:
> On 07/23/2012 11:14 AM, Another Sillyname wrote:
>>
>> 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.
>
>
> That's why there's an option to show or not show the Deactivated recordings
> in MythWeb's Upcoming Recording page. Unchecking the option removes all
> those "Earlier"/"Later" showings.
>
>
> Mike
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users

I know that, but removing information from the Mythweb display means
sometimes you miss information you may need to see - for example on
the BBC channels 301 Red Button Channel is not a channel I'd normally
look at in my listings unless I was looking for something specific,
it's useful to see in mythweb upcoming that it is reshowing extended
highlights of Formula 1 that are longer then the showing on BBC 1 even
though it uses the same PROGID and therefore not scheduled to record.

My point is not that your way is wrong, it's that sometimes people
have to go a different way for good reasons.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mikep at randomtraveller

Jul 23, 2012, 10:54 AM

Post #35 of 39 (567 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

On 23/07/12 16:35, Michael T. Dean wrote:
> On 07/23/2012 11:14 AM, Another Sillyname wrote:
>> 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.
>
> That's why there's an option to show or not show the Deactivated recordings in
> MythWeb's Upcoming Recording page. Unchecking the option removes all those
> "Earlier"/"Later" showings.
>
Doesn't always work, at least in the UK. We /also/ have other channels like
Dave, Yesterday, etc which show recycled programs from the main group of
BBC/ITV/Cannel4/Channel5.

When programs pop up on these other channels, they may not be marked as repeat
(or as recently, "rerun") and may have different program ids as well.

My rules list is cluttered with exceptions where I've had to remove extraneous
showings of series from two seasons back.

Sometimes, 'On this channel' (or perhaps, 'On this group of channels?') is what
we need to filter out the repeats.

--

Mike Perkins

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mtdean at thirdcontact

Jul 23, 2012, 11:35 AM

Post #36 of 39 (562 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

On 07/23/2012 01:54 PM, Mike Perkins wrote:
> On 23/07/12 16:35, Michael T. Dean wrote:
>> On 07/23/2012 11:14 AM, Another Sillyname wrote:
>>> 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.
>>
>> That's why there's an option to show or not show the Deactivated
>> recordings in
>> MythWeb's Upcoming Recording page. Unchecking the option removes all
>> those
>> "Earlier"/"Later" showings.
>>
> Doesn't always work, at least in the UK. We /also/ have other channels
> like Dave, Yesterday, etc which show recycled programs from the main
> group of BBC/ITV/Cannel4/Channel5.
>
> When programs pop up on these other channels, they may not be marked
> as repeat (or as recently, "rerun") and may have different program ids
> as well.
>
> My rules list is cluttered with exceptions where I've had to remove
> extraneous showings of series from two seasons back.
>
> Sometimes, 'On this channel' (or perhaps, 'On this group of
> channels?') is what we need to filter out the repeats.

And my point was simply that "this channel" rules are, by definition,
more work for the user who selects them when channels change. So, feel
free to use "this channel" rules, but make sure you update them when
channels change.

Mike

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

anothersname at googlemail

Jul 23, 2012, 12:04 PM

Post #37 of 39 (563 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

On 23 July 2012 18:54, Mike Perkins <mikep [at] randomtraveller> wrote:
> On 23/07/12 16:35, Michael T. Dean wrote:
>>
>> On 07/23/2012 11:14 AM, Another Sillyname wrote:
>>>
>>> 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.
>>
>>
>> That's why there's an option to show or not show the Deactivated
>> recordings in
>> MythWeb's Upcoming Recording page. Unchecking the option removes all
>> those
>> "Earlier"/"Later" showings.
>>
> Doesn't always work, at least in the UK. We /also/ have other channels like
> Dave, Yesterday, etc which show recycled programs from the main group of
> BBC/ITV/Cannel4/Channel5.
>
> When programs pop up on these other channels, they may not be marked as
> repeat (or as recently, "rerun") and may have different program ids as well.
>
> My rules list is cluttered with exceptions where I've had to remove
> extraneous showings of series from two seasons back.
>
> Sometimes, 'On this channel' (or perhaps, 'On this group of channels?') is
> what we need to filter out the repeats.
>
> --
>
> Mike Perkins
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users

Actually Mike you've given me an idea......

I spend a fair amount of time Stateside and a fundemental difference
with the way TV is shown exists between the US and the UK, possibly
other Countries as well, Aus and NZ spring to mind.

Overly simplistically in the US TV is easily definable into 3 parts....

Broadcast TV - Mostly ABC, CBS, NBS, Fox, CW and then local variations as well.
The Broadcast Nets are now also having 2 or 3 additional channels on
their Digital transmission although my experience is that more often
then not these additional channels are used as weather or local news
channels.

Can be received in the clear usually via DVB-T

Cable TV - The above + Hundreds of additional channels dependent on
your location. In effect each cable area is a local monopoly and tie
you into their system by forcing you to use their Set Top Box. I
realise that some areas transmit in the clear or can be accessed via
something like a cablecard system.

Can be received via Set Top Box or Cablecard. In my experience you
need one set top box per channel being recorded if encrypted or you
can use some DVB-C cards if your provider still transmits in the
clear.

Satellite TV - Very similar to Cable TV except it comes via Satellite,
two main players.

Can be received via DVB-S card or Set Top Box, some channels in the
clear but most encrypted in some form or another.

In simplistic terms in the US you can usually only receive maybe 10-15
channels 'in the clear' via one form or another with you then having a
limit determined by the number of Set Top Boxes you have to the other
channels you can receive. I realise there are going to be regional
variations to these numbers but it's a reasonable rule of thumb.

In the UK it's a different landscape.

There are 4 major delivery mechanisms.

Freeview - This is delivered via DVB-T and for most households
consists of about 35 channels of Free TV, a further 25 channels of
Free Radio and some paid content if you desire it via a Set Top Box.

The Free TV channels consist of

BBC1, BBC2, BBC3, BBC4, BBC News 24, BBC Parliament, BBC 1 HD, BBC HD.
ITV1, ITV2, ITV3, ITV4 + 1 Hour Timeshifts of them and then ITV HD
Channel 4, More 4, E4, Film 4 + 1 Hour Timeshifts of them and then Channel 4 HD
Five, Five Star, Five USA +1 Hour Timeshifts of some of them
Dave, Quest, Yesterday etc.... secondary channels that usually run
repeats from the main channels above or bought in programming.
Pick, Challenge etc... secondary channels that run populist
programming or narrow range programming i.e. Quiz Shows.
4 Music, Viva etc....Music, Youth programming.

So in a nutshell you have about 15 main channels that show mostly
original programming.
a further 15 channels that show repeats from the main channels a year
or two later or bought in programming.

You can also buy some paid programming via Top Up TV but for the
purposes of this discussion let's exclude them as their user base is
very small.

All these channels are available in the clear via DVB-T and are
available to 97% of the population.

Freesat

Effectively a duplication of the above provided via DVB-S with a few
channel variations.

Sky-TV

Similar to satellite TV in the US, however no effective way to provide
the channels to MythTV that can be discussed on the list due to
Digital Rights issues.

Cable TV

In the UK there is currently only one substantive Cable TV provider in
Virgin TV with the same limitations as US Cable TV. However British
Telecom are currently aggressively rolling out Fibre Optic with some
TV services already provided and a plan to expand substantially.

The majority of people in the UK take just Freeview or Freesat, with
Sky-TV providing services to 10m ish households and Virgin about 1m
ish households.

I have seen setups in the UK where people have installed a Toroidal
dish pointing at more then one satellite feed and Octo LNBs to allow
them to pull 8 Muxs per satellite simultaneously.

The reason to tell you all of this is whereas the US is predominantly
a Cable TV environment in the UK most people will take Freeview or
Freesat for their general entertainment.

To put it in perspective with viewing figures a hit show on US
Broadcast these days is anything with 8m up, with NCIS currently
pulling about 20m. The UK with a population about 16% of the US
population has shows on BBC 1 and ITV 1 that pull 8m viewers 3-4 times
per week. Indeed a program like Top Gear which would never even get
on broadcast TV in the US pulls about 6m viewers on BBC 2 when it's
airing.

The US TV market is incredibly fragmented by both channel and
geography. In the UK the TV service is seen as a national service
without so much local fragmentation and as a result most of it is
provided in the clear. This is obviously partly because the UK is a
single timezone without the "Ten Nine Central" issues you get
Stateside.

I hope this makes sense and helps you understand why choosing 'record
on any channel' is not the same viable option for UK recording that it
is in other areas, our TV structure is different from what you'd see
in the States and therefore our recording requirements are influenced
accordingly.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

edmund.1 at dial

Jul 23, 2012, 12:18 PM

Post #38 of 39 (561 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

Doesn't always work, at least in the UK. We /also/ have other channels
like Dave, Yesterday, etc which show recycled programs from the main
group of BBC/ITV/Cannel4/Channel5.
>
> When programs pop up on these other channels, they may not be marked
> as repeat (or as recently, "rerun") and may have different program ids
> as well.
>
> My rules list is cluttered with exceptions where I've had to remove
> extraneous showings of series from two seasons back.
>
> Sometimes, 'On this channel' (or perhaps, 'On this group of
> channels?') is what we need to filter out the repeats.
>
I've deleted Dave and the rest from my list. The one program a year I
might have wanted to watch that I now miss is more than made up for by
the effort saved in no longer having to delete those old episodes.

I also have deleted all the +1 channels too. However I have only
freeview and three dual tuners so conflicts aren't an issue for me. I
can see that if you have fewer tuners or more channels you would need to
keep them.

After retunes I make sure that the seven or eight channels I care about
retain their chanid. If I cared about more than that I would use an sql
list to maintain them for me.

_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

joe at thefrys

Jul 23, 2012, 12:39 PM

Post #39 of 39 (547 views)
Permalink

Re: 0.25 SQL CPU Load issues after optimisation [In reply to]

>
> Doesn't always work, at least in the UK. We /also/ have other channels
> like Dave, Yesterday, etc which show recycled programs from the main group
> of BBC/ITV/Cannel4/Channel5.
>
>>
>> When programs pop up on these other channels, they may not be marked as
>> repeat (or as recently, "rerun") and may have different program ids as well.
>>
>> My rules list is cluttered with exceptions where I've had to remove
>> extraneous showings of series from two seasons back.
>>
>> Sometimes, 'On this channel' (or perhaps, 'On this group of channels?')
>> is what we need to filter out the repeats.
>>
>> I've deleted Dave and the rest from my list. The one program a year I
> might have wanted to watch that I now miss is more than made up for by the
> effort saved in no longer having to delete those old episodes.
>
> I also have deleted all the +1 channels too. However I have only freeview
> and three dual tuners so conflicts aren't an issue for me. I can see that
> if you have fewer tuners or more channels you would need to keep them.
>
> After retunes I make sure that the seven or eight channels I care about
> retain their chanid. If I cared about more than that I would use an sql
> list to maintain them for me.
>
>
It's a shame you actually have to delete the channel. I could see the
value of an "enable scheduler" flag for channels... so we could simply tell
the scheduler to ignore a given channel on a scheduling run... however a
"record this showing" would still work, and you could still tune it in
livetv, and optionally record while you watch.

Would be handy to be able to exclude channels from searching too... I hate
running a "new series" search and seeing a ton of crap from channels I will
never record but may tune to occasionally (shopping, community access,
local government, etc).

1 2

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads