[mythtv-users] Scheduler seems to think I am recording too many programs at once

Stephen Worthington stephen_agent at jsw.gen.nz
Mon May 6 07:43:10 UTC 2013


On Mon, 06 May 2013 11:37:34 +1200, you wrote:

>On Sun, 05 May 2013 12:17:37 -0500, you wrote:
>
>>On Sun, May 05, 2013 at 09:06:37PM +1200, Stephen Worthington wrote:
>>> On Sat, 04 May 2013 13:55:20 -0500, you wrote:
>>> 
>>> >On Sat, May 04, 2013 at 10:03:42PM +1200, Stephen Worthington wrote:
>>> >> On Fri, 03 May 2013 13:33:48 -0500, you wrote:
>>> >> 
>>> >> >On Sat, May 04, 2013 at 03:50:30AM +1200, Stephen Worthington wrote:
>>> >> >> On Fri, 03 May 2013 09:35:46 -0500, you wrote:
>>> >> >> 
>>> >> >> >On Fri, May 03, 2013 at 02:19:52PM +1200, Stephen Worthington wrote:
>>> >> >> >> On Thu, 02 May 2013 13:26:44 -0500, you wrote:
>>> >> >> >> 
>>> >> >> >> >On Fri, May 03, 2013 at 03:01:42AM +1200, Stephen Worthington wrote:
>>> >> >> >> >> On Thu, 02 May 2013 09:25:17 -0500, you wrote:
>>> >> >> >> >> 
>>> >> >> >> >> >On Fri, May 03, 2013 at 12:04:03AM +1200, Stephen Worthington wrote:
>>> >> >> >> >> >> On Thu, 02 May 2013 07:18:50 -0400, you wrote:
>>> >> >> >> >> >> 
>>> >> >> >> >> >> >On 05/02/2013 12:56 AM, Stephen Worthington wrote:
>>> >> >> >> >> >> >> I was just checking the scheduling for the new EPG received today, and
>>> >> >> >> >> >> >> I found that one program "Seven Sharp" was not recording at its usual
>>> >> >> >> >> >> >> time of 19:00 on TV ONE, but instead was recording at 20:00 from the
>>> >> >> >> >> >> >> TVONE PLUS1 channel which retransmits TV ONE an hour later, but in SD
>>> >> >> >> >> >> >> instead of HD.  I have occasionally seen this sort of thing happen
>>> >> >> >> >> >> >> before, always when I am recording lots of programs at the same time.
>>> >> >> >> >> >> >> It has always seemed to me that the scheduler must have some limit for
>>> >> >> >> >> >> >> the number of programs it will record at one time and when it goes
>>> >> >> >> >> >> >> over that limit, it tries to reschedule one or more of them.  If I add
>>> >> >> >> >> >> >> an override to force "Seven Sharp" to record from TV ONE at 19:00, the
>>> >> >> >> >> >> >> scheduler is happy to do that and does not seem to make any other
>>> >> >> >> >> >> >> changes.
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> Here is the schedule for that time period, without the override:
>>> >> >> >> >> >> >> [Time]       [Callsign]-[Program name]
>>> >> >> >> >> >> >> 17:30:18:30  DISCO - Mythbusters
>>> >> >> >> >> >> >> 18:00-19:03  TV ONE - One News At 6pm
>>> >> >> >> >> >> >> 18:00-19:03  TV3 - 3 News
>>> >> >> >> >> >> >> 18:30-19:03  ChoiceTV - Bath Crashers
>>> >> >> >> >> >> >> 19:00-19:33  TV ONE - Seven Sharp  (yellow, "Find Daily -3 Later
>>> >> >> >> >> >> >> Showing")
>>> >> >> >> >> >> >> 19:00-19:33  TV ONE-S - Seven Sharp (yellow, "Find Daily -7 Later
>>> >> >> >> >> >> >> Showing")
>>> >> >> >> >> >> >> 19:00-19:33  TV3 - Campbell Live
>>> >> >> >> >> >> >> 19:30-19:33  TV2 - Police Ten 7
>>> >> >> >> >> >> >> 19:30-20:30  HISCH - Mysteries At The Museum (yellow, "Channel Record
>>> >> >> >> >> >> >> +0 Later Showing")
>>> >> >> >> >> >> >> 19:30-20:30  KNOWLGE - Who Do You Think You Are? Aus
>>> >> >> >> >> >> >> 19:30-20:33  PRIME - Great Rift: Africas Wild
>>> >> >> >> >> >> >> 19:30-20:33  TV3 - Grand Designs Revisited
>>> >> >> >> >> >> >> 20:00-20:30  CRIME&  - Traffic Blues (yellow "Channel Record +0 Later
>>> >> >> >> >> >> >> Showing")
>>> >> >> >> >> >> >> 20:00-20:33  TV2 - RBT
>>> >> >> >> >> >> >> 20:00-20:33  TVONE PLUS1 - Seven Sharp
>>> >> >> >> >> >> >> 20:29-21:33  TV3 - Bones
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> In the above, TV ONE, TV2 and TVONE PLUS1 are transmitted on the same
>>> >> >> >> >> >> >> DVB-T multiplex, PRIME and ChoiceTV are on the same DVB-T mux, and TV3
>>> >> >> >> >> >> >> is on the third DVB-T mux.  TV ONE-S is an SD version of TV ONE on a
>>> >> >> >> >> >> >> DVB-S mux.  The other channels are all on Sky TV which is recorded
>>> >> >> >> >> >> >> from a set top box via one S-Video card (so there is only one tuner
>>> >> >> >> >> >> >> for those channels).  The three DVB-T muxes are on one source, the
>>> >> >> >> >> >> >> DVB-S muxes on another source, and Sky TV is on the third source.  All
>>> >> >> >> >> >> >> the DVB-T and DVB-S tuners are set up with 4 multirec virtual tuners
>>> >> >> >> >> >> >> each, and I have 3 DVB-T tuners and 2 DVB-S ones.  Since I have as
>>> >> >> >> >> >> >> many DVB-T tuners as there are DVB-T muxes being transmitted, I should
>>> >> >> >> >> >> >> never have to use the TVONE PLUS1 channel at all as I should always
>>> >> >> >> >> >> >> have enough tuners to record everything I need on the first showing.
>>> >> >> >> >> >> >>
>>> >> >> >> >> >> >> So, does anyone know if there is some sort of limit in the scheduler
>>> >> >> >> >> >> >> on the number of programs that will record at any one time?  And if
>>> >> >> >> >> >> >> so, what it is and how it works?  Is there a setting I can adjust for
>>> >> >> >> >> >> >> it?
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >No limit.  The only limit is the number of tuners (physical and virtual) 
>>> >> >> >> >> >> >you have.  MythTV will gladly work your system so hard that the hardware 
>>> >> >> >> >> >> >fails to keep up and everything fails miserably if you tell it to.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >> I have 5 recording drives, so whatever is causing this sort of
>>> >> >> >> >> >> >> rescheduling is not taking that into account, as I can easily record
>>> >> >> >> >> >> >> at least 10 programs simultaneously, and probably more, as long as the
>>> >> >> >> >> >> >> recordings use all the drives (and they normally do).
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >It is almost definitely a priority modifier on the other showing causing 
>>> >> >> >> >> >> >it to be preferred.  This could be channel or input or HDTV or any of a 
>>> >> >> >> >> >> >number of other priority modifiers.  You can see what's happening by 
>>> >> >> >> >> >> >running:
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >mythbackend -v schedule --loglevel debug --printsched
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >before the shows air and without the override in place.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >> Also, is there a way to mark the TVONE PLUS1 channel as SD and the TV
>>> >> >> >> >> >> >> ONE channel as HD and tell the scheduler to always record the HD
>>> >> >> >> >> >> >> programming unless there is an actual clash?
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >No, there's no such thing as an "HD" channel--only channels that have 
>>> >> >> >> >> >> >programs which may or may not be HDTV.  So, it's up to your guide data 
>>> >> >> >> >> >> >to properly mark programs as HDTV or not.
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >You can set priority modifiers on channels (and starting with 0.27, 
>>> >> >> >> >> >> >they'll work the way you think they would work), but then again, 
>>> >> >> >> >> >> >priority modifiers you've already set are probably what's causing MythTV 
>>> >> >> >> >> >> >to record shows in such a way that you think the scheduler is wrong...  ;)
>>> >> >> >> >> >> >
>>> >> >> >> >> >> >Mike
>>> >> >> >> >> >> 
>>> >> >> >> >> >> The --printsched option looks like it is really useful.  I have put
>>> >> >> >> >> >> the result on my web server here:
>>> >> >> >> >> >> 
>>> >> >> >> >> >>   http://www.jsw.gen.nz/mythtv/sched.txt
>>> >> >> >> >> >> 
>>> >> >> >> >> >> If I paste it into a post, its gets word wrapped and unreadable.  For
>>> >> >> >> >> >> readability I also cut down the output to just the bit between times
>>> >> >> >> >> >> where there is nothing recording, so in theory nothing before or after
>>> >> >> >> >> >> the bit posted would affect the scheduling at the problem time.
>>> >> >> >> >> >> 
>>> >> >> >> >> >> If, as I am assuming, the P=Priority column is the fully calculated
>>> >> >> >> >> >> priority value for the scheduled recording, the I do not understand
>>> >> >> >> >> >> what is going on.  The "Seven Sharp" scheduled to actually record from
>>> >> >> >> >> >> TVONE PLUS1 has a priority of -4, but the one that is not going to
>>> >> >> >> >> >> record from TV ONE has a priority of -3.
>>> >> >> >> >> >> 
>>> >> >> >> >> >> The channel priorities are: TV ONE is 0, TVONE PLUS1 is -1, which
>>> >> >> >> >> >> explains the difference between the two recording priorities.  But it
>>> >> >> >> >> >> is still going to record the wrong one.
>>> >> >> >> >> >
>>> >> >> >> >> >I'm pretty sure Mike meant that to be --testsched and not
>>> >> >> >> >> >--printsched.  And don't snip any of the output.  It's the cryptic
>>> >> >> >> >> >details that explains what is going on and why.
>>> >> >> >> >> >
>>> >> >> >> >> >David
>>> >> >> >> >> 
>>> >> >> >> >> OK, that has a lot more detail.  I have put it here:
>>> >> >> >> >> 
>>> >> >> >> >>   http://www.jsw.gen.nz/mythtv/testsched.txt
>>> >> >> >> >
>>> >> >> >> >Here's what's happening in a nutshell.  In the initial scheduling
>>> >> >> >> >pass, none of the HD showings can be scheduled due to conflicts.  In
>>> >> >> >> >the first retry scheduling pass, none of the conflicting programs can
>>> >> >> >> >be moved.  In the second retry pass, lower priority showings are tried
>>> >> >> >> >and the SD showing at 20:00 is chosen.
>>> >> >> >> >
>>> >> >> >> >The reason adding an override sometimes works is it essentially limits
>>> >> >> >> >the second retry pass to the current showing.  FWIW, there are some
>>> >> >> >> >minor changes to this area in master (aka pre-0.27).  They might or
>>> >> >> >> >might ot help in this particular case.
>>> >> >> >> >
>>> >> >> >> >David
>>> >> >> >> 
>>> >> >> >> But what I do not understand is that there are no conflicts at all for
>>> >> >> >> the DVB-T channels.  There are enough DVB-T tuners to record all the
>>> >> >> >> programs, so why are there conflicts to resolve?  The scheduler should
>>> >> >> >> just be able to assign the available tuners.  The conflicts are only
>>> >> >> >> for the S-Video input.
>>> >> >> >
>>> >> >> >There are conflicts with:
>>> >> >> >
>>> >> >> >!Bath Crashers                  12 ChoiceT 09 18:30-19:03  1 1 1  C 1 4/1
>>> >> >> >!Grand Designs Revisited         3 TV3     09 19:30-20:33  1 5 5  C 5 4/5
>>> >> >> >!Great Rift: Africa's Wild -    10 PRIME   09 19:30-20:33  1 10 10  C 10 4/9
>>> >> >> >
>>> >> >> >David
>>> >> >> 
>>> >> >> As I said, I have 3 DVB-T tuners.  There are only 3 DVB-T multiplexes
>>> >> >> being transmitted in New Zealand.  So there is no way to get a
>>> >> >> conflict on DVB-T except by running out of virtual tuners.  Which
>>> >> >> would require recording from 5 channels at once on one of the DVB-T
>>> >> >> multiplexes.  The TVNZ multiplex and the Mediaworks multiplex have
>>> >> >> only 4 channels transmitted on each.  The Kordia multiplex has more
>>> >> >> channels, around 12 I think including the radio ones, but I only ever
>>> >> >> record from 3 of them.  So I always have enough DVB-T tuners and
>>> >> >> enough virtual tuners on each DVB-T tuner so that there is no conflict
>>> >> >> possible.
>>> >> >> 
>>> >> >> So where is the conflict coming from?  The source of the non-existent
>>> >> >> conflict would seem to be the source of the problem.
>>> >> >
>>> >> >I told you exactly where the conflicts were, but you aparently refuse
>>> >> >to see them.  If you close your eyes, do you think you're invisible,
>>> >> >too?
>>> >> 
>>> >> Clearly I do not know what you mean by a conflict here then.  Sure,
>>> >> the scheduler is seeing a conflict - it is saying so.  But there is no
>>> >> actual conflict for me to relate that back to.  Since I have few clues
>>> >> about how the scheduler works, from the outside, it appears to me to
>>> >> be a bug.  If it is actually normal and expected behaviour from the
>>> >> scheduler to decide there is a conflict where there is not one (for
>>> >> reasons known only to the scheduler), then it would be helpful to know
>>> >> that is what it does.
>>> >> 
>>> >> >You seem to have the mistaken impression the scheduler will
>>> >> >automagically utitlize every tuner and multiplex like it's playing a
>>> >> >perfect game of tetris.  It doesn't work that way.  The scheduler
>>> >> >tries to balance many different goals using the priority hints given
>>> >> >to it.  It's not perfect, doesn't claim to be and never will be.
>>> >> >
>>> >> >David
>>> >> 
>>> >> Well, mostly the scheduler does seem to be able to automagically get
>>> >> everything right!  It does very well for me with the difficult job of
>>> >> scheduling my one S-Video input from my Sky set top box.  So when I am
>>> >> seeing it go wrong, if not badly, in the "easier" job of scheduling my
>>> >> DVB-T tuners where conflicts are impossible, I wonder why.  And since
>>> >> I am getting this problem quite repeatably every Thursday at the
>>> >> moment until one of the channels changes their schedule, surely it
>>> >> would be a good idea to use my setup to collect some information on
>>> >> where it is going wrong so that it might be possible to improve the
>>> >> scheduler.
>>> >> 
>>> >> As I said in my original post, the problem feels to me, as a person
>>> >> looking on from the outside with no knowledge of the internals of the
>>> >> scheduler, that it is hitting some sort of fixed limit, such as too
>>> >> many channels to schedule at once.  For example, maybe it is going
>>> >> around a loop N times and is unable to schedule in those N loops, so
>>> >> it declares a conflict and changes the conditions it is working on and
>>> >> then tries another N loops and succeeds, when if N was a bit bigger
>>> >> (to cope with more channels and/or more tuners), it might have been
>>> >> able to schedule properly on the first try.  Or maybe it is filling up
>>> >> a table and stopping when it is full.  Just some wild-ass guesses.
>>> >> 
>>> >> And if I am right and the problem is triggered by recording more
>>> >> things at once, as the number of channels being broadcast increases
>>> >> and people have more tuners, more people are likely to come up against
>>> >> this problem.
>>> >> 
>>> >> So, is there anything more I can do to get data that might illuminate
>>> >> the source of this problem?
>>> >
>>> >I won't go into all of the details (it's all in the testsched output
>>> >if you want to see it), but here is what's happening at the high
>>> >level.
>>> >
>>> >  +Bath Crashers                     12 ChoiceT 09 18:30-19:03  1 1 1  C 1 4/1
>>> >  +Police Ten 7                       2 TV2     09 19:30-20:03  1 1 1  C 1 4/1
>>> >
>>> >Bath Crashers and Police Ten 7 have the relatively high priority of 4
>>> >and are scheduled on input 1.
>>> >
>>> >  #Grand Designs Revisited            3 TV3     09 19:30-20:33  1 1 1  C - 4/1
>>> >     !Police Ten 7                    2 TV2     09 19:30-20:03  1 1 1  C 1 4/1
>>> >  +Grand Designs Revisited            3 TV3     09 19:30-20:33  1 5 5  C 5 4/5
>>> >
>>> >Grand Designs Revisited also has priority 4, but comes later in the
>>> >scheduling order.  It conflicts with Police Ten 7 on inputs 1-4, so it
>>> >is scheduled on input 5.
>>> >
>>> >  #Grand Designs Revisited            3 TV3     09 19:30-20:33  1 1 1  C - 4/1
>>> >     !Police Ten 7                    2 TV2     09 19:30-20:03  1 1 1  C 1 4/1
>>> >  #Great Rift: Africa's Wild - Hea   10 PRIME   09 19:30-20:33  1 5 5  C - 4/5
>>> >     !Grand Designs Revisited         3 TV3     09 19:30-20:33  1 5 5  C 5 4/5
>>> >  +Great Rift: Africa's Wild - Hea   10 PRIME   09 19:30-20:33  1 10 10  C 10 4/9
>>> >
>>> >Great Rift: Africa's Wild also has priority 4, but it also comes later
>>> >int the scheduling order.  It conflicts with Police Ten 7 on inputs
>>> >1-4 and Grand Designs Revisited on inputs 5-8, so it is scheduled on
>>> >input 10.
>>> >
>>> >  #Seven Sharp                        1 TV ONE  09 19:00-19:33  1 1 1  d - -3/1
>>> >     !Bath Crashers                  12 ChoiceT 09 18:30-19:03  1 1 1  C 1 4/1
>>> >  #Seven Sharp                        1 TV ONE  09 19:00-19:33  1 5 5  d - -3/5
>>> >     !Grand Designs Revisited         3 TV3     09 19:30-20:33  1 5 5  C 5 4/5
>>> >  #Seven Sharp                        1 TV ONE  09 19:00-19:33  1 10 10  d - -3/9
>>> >     !Great Rift: Africa's Wild -    10 PRIME   09 19:30-20:33  1 10 10  C 10 4/9
>>> >
>>> >Seven Sharp has the relatively low priority of -4 and the attempt to
>>> >schedule it comes much later.  It conflicts with Bash Crashers on
>>> >input 1-4, Grand Designs Revisited revisited on inputs 5-8 and Great
>>> >Rift: Africa's Wild on inputs 10-13.
>>> 
>>> Right, so this is where it first gets into trouble.  It looks as
>>> though the scheduler has assigned two different tuners to record the
>>> same multiplex at the same time, leaving it without a spare tuner when
>>> the third multiplex needs to be recorded.  If Bath Crashers and Great
>>> Rift had been scheduled on different virtual tuners of the same tuner,
>>> there would have been a spare tuner for Seven Sharp.
>>
>>The scheduler does not do anything special to group programs by
>>multiplex.  As I said before, it uses the priorities given to it and
>>schedules the programs accordingly.  In doing so, it uses the first
>>available tuner.  If that results in the same multiplex being used on
>>multiple tuners, then so be it.
>>
>>> >  /Seven Sharp                        1 TV ONE  09 19:00-19:33  1 13 13  d - -3/12
>>> >     >Great Rift: Africa's Wild -    10 PRIME   09 19:30-20:33  1 10 10  C 10 4/9
>>> >     %Great Rift: Africa's Wild -    10 PRIME   09 19:30-20:33  1 1 1  C L 4/1
>>> >        !Police Ten 7                 2 TV2     09 19:30-20:03  1 1 1  C 1 4/1
>>> >     %Great Rift: Africa's Wild -    10 PRIME   09 19:30-20:33  1 5 5  C L 4/5
>>> >        !Grand Designs Revisited      3 TV3     09 19:30-20:33  1 5 5  C 5 4/5
>>> >
>>> >Attempts to move Great Rift: Africa's Wild from input 10 fail.
>>> 
>>> This should have succeeded - Great Rift on Prime is on the same Kordia
>>> multiplex as Bath Crashers on ChoiceTV, and Bath Crashers is still
>>> recording when Great Rift starts.  But it never looked at moving Great
>>> Rift to the same tuner as Bath Crashers, for some reason.
>>
>>Please read the output I painstakingly deciphered for you.  The
>>programs which prevented Great Rift: Africa's Wild from being moved
>>are marked with a '!'.
>
>So far I have not found a key that deciphers the meanings of those
>characters.  But working from your deciphering of the output I had
>guessed that ! meant that the scheduler could not move Great Rift onto
>that program's tuner, and that > meant it was trying to move a
>program.
>
>My question here is still why the scheduler did not seem to have even
>looked at moving Great Rift onto the tuner that Bath Crashers is on.
>Surely if it had done that check, would it not have displayed that in
>the debug output?  If it had checked the Bath Crashers tuner, it would
>have found itself able to move Great Rift to that tuner.  It seems to
>have checked the other two tuners that are assigned at this point. Why
>did it not even check the Bath Crashers tuner?  It seems very strange
>to me that it would not check all the tuners, just two out of the
>three.
>
>>> >  /Seven Sharp                        1 TV ONE  09 19:00-19:33  1 8 8  d - -3/8
>>> >     >Grand Designs Revisited         3 TV3     09 19:30-20:33  1 5 5  C 5 4/5
>>> >     %Grand Designs Revisited         3 TV3     09 19:30-20:33  1 1 1  C L 4/1
>>> >        !Police Ten 7                 2 TV2     09 19:30-20:03  1 1 1  C 1 4/1
>>> >     %Grand Designs Revisited         3 TV3     09 19:30-20:33  1 10 10  C L 4/9
>>> >        !Great Rift: Africa's Wild   10 PRIME   09 19:30-20:33  1 10 10  C 10 4/9
>>> >
>>> >Attempts to move %Grand Designs Revisited from input 5 fail.
>>> >
>>> >  /Seven Sharp                        1 TV ONE  09 19:00-19:33  1 4 4  d - -3/4
>>> >     >Bath Crashers                  12 ChoiceT 09 18:30-19:03  1 1 1  C 1 4/1
>>> >     %Bath Crashers                  12 ChoiceT 09 18:30-19:03  1 5 5  C L 4/5
>>> >        !3 News                       3 TV3     09 18:00-19:03  1 5 5  T 5 -3/5
>>> >     %Bath Crashers                  12 ChoiceT 09 18:30-19:03  1 10 10  C L 4/9
>>> >        !One News At 6pm              1 TV ONE  09 18:00-19:03  1 10 10  d 10 -3/9
>>> >
>>> >Attempts to move Bath Crashers from input 1 fail.
>>> 
>>> Again, this should have succeeded as Bath Crashers can be moved to the
>>> tuner Great Rift is on, but it never considered that.
>>> 
>>> >  ?Seven Sharp                        1 TV ONE  09 19:00-19:33  1 13 13  d - -3/12
>>> >     >Seven Sharp                     1 TV ONE  09 19:00-19:33  1 13 13  d - -3/12
>>> >     -Seven Sharp                     1 TV ONE  09 19:00-19:33  1 13 13  d L -3/12
>>> >     +Seven Sharp                     7 TVONE P 09 20:00-20:33  1 3 3  d 3 -4/3
>>> >
>>> >At this point, the scheduler will look for any other showing of even
>>> >Sharp that can be scheduled before trying (slightly) harder to move
>>> >other programs.  It finds showing on TVONE PLUS1 is free and schedules
>>> >it.
>>> >
>>> >Okay, so where does that leave you?  
>>> >
>>> >Not counting start-early and end-late complications, you have enough
>>> >physical tuners to cover all of your channels and multiplexes.  That
>>> >is by far not the norm.  Most users have way more channels than
>>> >tuners.  They should use recording priorities to indicate importance
>>> >of programs so the most important programs always get scheduled and
>>> >the less important one get scheduled when possible.  You should
>>> >probably use recording priorities differently.  You can use recording
>>> >priorities to cause recordings on the same channels to try to use the
>>> >same tuners.  Here's one way to do that.
>>> >
>>> >Say you have the following 3 multiplexes4 with 4 channels each:
>>> >
>>> >  multiplex 1: channels 1a, 1b, 1c and 1d
>>> >  multiplex 2: channels 2a, 2b, 2c and 2d
>>> >  multiplex 3: channels 3a, 3b, 3c and 3d
>>> >
>>> >Give them the following channel priorities:
>>> >
>>> >  1a = 20, 1b = 19, 1c = 18, 1d = 17
>>> >  2a = 16, 2b = 15, 2c = 14, 2d = 13
>>> >  3a = 12, 3b = 11, 3c = 10, 3d = 9
>>> >
>>> >Now, if you have 4 virtual tuners per physical tuner and set all of
>>> >your other priorities to 0 (and don't use start-early or end-late),
>>> >the scheduler will fill up all of your virtual tuners in the most
>>> >efficient way.  Note that the way things currently work, any use of
>>> >start-early or end-late could negatively affect that.  The only
>>> >solution to that right now is to add more virtual tuners.
>>>
>>> >David
>>> 
>>> I am mystified as to why the scheduler never tried to move Bath
>>> Crashers onto Great Rift's tuner or vice versus - it seems it never
>>> even considered that possibility.  Instead it considered the other two
>>> tuners which were on different multiplexes.  That seems to be where it
>>> went wrong.  So I am wondering if I have something wrong in my
>>> database setup that prevented it from doing that.
>>> 
>>> The only other thing I can think of is that it did not consider Bath
>>> Crashers because it did not consider Bath Crashers to be running at
>>> that time because it was taking the time it finished as the scheduled
>>> end time instead of with the plus 3 minutes of hard post roll on Bath
>>> Crashers.  Is a bug like that a possibility?
>>> 
>>> Just in case, I did try increasing the virtual tuners to 5 on each
>>> DVB-T and DVB-S2 tuner but that did not change anything.
>>
>>Sigh.  I guess I'm just wasting my time.  No matter what I say, you
>>hold to the delusion the scheduler should work pefectly every time,
>>even when you use priorities that exacerbate the problem.  It won't
>>and it never will.  It's intended to do a good job on a very wide
>>range of cases and it does that.  I told you how you can change your
>>priorities to get a better result.  If you don't want to even consider
>>that, I can't help you anymore.
>>
>>David
>
>Your suggestion of changing the priorities came with a very important
>proviso "and don't use start-early or end-late", which renders it
>useless to me.  I have to have post-roll on most DVB-T programs as the
>start and stop times in the EPG for DVB-T here in New Zealand are
>accurate only to the nearest 5 minutes - most programs run over by at
>least one minute, and typically up to 3 minutes.  The actual start
>times normally fall after the EPG start time, except on TV2, where
>some programs can actually start a little early requiring a minute of
>pre-roll.  Setting programs to stop on the EPG stop time virtually
>guarantees that many programs will be missing some time at the end
>(and not just credits).  Before I added post-roll when I first started
>using MythTV I used to get programs such as murder mysteries where I
>would never find out who the murderer was!
>
>And for the past couple of years some channels have a pernicious new
>practice where they are actually starting the next program over the
>top of the credits of the previous one during peak time (they cut off
>the bottom of the new program and run the credits of the previous
>program squeezed up into that space at the bottom of the screen). This
>appears to be because they want people who are not recording programs
>and are watching directly to not have the chance to change channels
>between programs.  For the same reason, many years ago, they stopped
>putting advertising between programs and moved it all into ad breaks
>inside the programs.
>
>I can certainly try changing the priorities as suggested if you think
>it will still help even with pre and post roll - I was already
>intending to find the time to experiment with that today.

OK, I have now done some experimenting with the priorities.  I first
removed the overrides and then went to "Seven Sharp" and "Campbell
Live", and changed the priority in their recording rules to "Normal
priority" ie recpriority=0.  That fixed the problem - "Bath Crashers",
"Seven Sharp" and "Campbell Live" would now all record the first
showing.

So I then did a bit of SQL to see what other programs I had recording
from my DVB-T tuners (sourceid=1) with non-0 recpriority:

  select
recordid,type,chanid,starttime,endtime,title,subtitle,station,recpriority
from record r where (select c.sourceid from channel c where
r.chanid=c.chanid)=1 and recpriority !=0 order by title;

That showed up a few more rules with non-0 recpriority.  Some of them
were old "Do not record" overrides for particular dates, so I just
deleted those rules.  For the remainder, I went to each rule in
mythfrontend and changed it to "Normal priority".  Two of the programs
that had reduced priority settings were "One News At 6pm" and "3
News", which are the programs preceding "Seven Sharp" and "Campbell
Live" respectively on those channels.

Then I went back to Thursday's schedule, and my problem was back
again, but not quite the same.  "Bath Crashers" was once again going
to "Record later showing", and overriding it to "Record anyway" caused
"Seven Sharp" to go to "Record later showing".  But setting "Seven
Sharp" to "Record anyway" fixed the problem without "Campbell Live"
going to "Record later showing" and having to also be overridden.

I left the DVB-T programs' recpriority values all at 0.

Next, I looked at your suggested setting of all the DVB-T channels
with different graduated priorities.  The current channel priorities
were all channels with recpriority=0 except for the two "Plus 1"
channels which were -1.  I changed that to make all the important and
HD channels high priority numbers, in a graduated scheme.  There are
21 channels (plus one that is no longer broadcast but is still in my
database as I still have recordings made from it: TVNZ 7), so I
started my priority numbers at 23 and worked downwards:

mysql> select
chanid,channum,sourceid,callsign,mplexid,recpriority,visible from
channel where sourceid=1 order by mplexid,recpriority desc;
+--------+---------+----------+--------------+---------+-------------+---------+
| chanid | channum | sourceid | callsign     | mplexid | recpriority | visible |
+--------+---------+----------+--------------+---------+-------------+---------+
|   1001 | 1       |        1 | TV ONE       |       1 |          23 |       1 |
|   1002 | 2       |        1 | TV2          |       1 |          22 |       1 |
|   1006 | 6       |        1 | U            |       1 |          21 |       1 |
|   1007 | 7       |        1 | TVONE PLUS1  |       1 |          20 |       1 |
|   1107 | 107     |        1 | TVNZ 7       |       1 |           0 |       0 |
|   1003 | 3       |        1 | TV3          |       2 |          19 |       1 |
|   1004 | 4       |        1 | FOUR         |       2 |          18 |       1 |
|   1009 | 9       |        1 | C4           |       2 |          17 |       1 |
|   1008 | 8       |        1 | TV3 PLUS1    |       2 |          16 |       1 |
|   1018 | 18      |        1 | Shopping     |       2 |          15 |       1 |
|   1010 | 10      |        1 | PRIME        |       3 |          14 |       1 |
|   1012 | 12      |        1 | ChoiceTV     |       3 |          13 |       1 |
|   1005 | 5       |        1 | Maori TV     |       3 |          12 |       1 |
|   1050 | 50      |        1 | RNZ National |       3 |          11 |       1 |
|   1051 | 51      |        1 | RNZ Concert  |       3 |          10 |       1 |
|   1022 | 22      |        1 | Parlmnt      |       3 |           9 |       1 |
|   1071 | 71      |        1 | BaseFM       |       3 |           8 |       1 |
|   1028 | 28      |        1 | ChineseTV    |       3 |           7 |       1 |
|   1029 | 29      |        1 | TV9          |       3 |           6 |       1 |
|   1011 | 11      |        1 | Trackside    |       3 |           5 |       1 |
|   1026 | 26      |        1 | Firstlight   |       3 |           4 |       1 |
+--------+---------+----------+--------------+---------+-------------+---------+
21 rows in set (0.00 sec)

Despite all the pre-roll and post-roll on my programs, the new
graduated channel priorities have fixed the problem.  I have had a
quick look through the rest of the schedule, and I can not see it
having created any new problems either.  Indeed, it has solved another
problem I was having where occasionally I would get one of the
satellite channels that are the same as the DVB-T channels recording a
program that was set to record once a week.  The DVB-T version was
recording, but the satellite one also recorded - but not now with the
graduated channel priorities.

This seems a very good solution, thank you.  It is much better than
having to mess around with the priorities of individual programs, or
override things.


More information about the mythtv-users mailing list