[mythtv-users] Scheduler seems to think I am recording too many programs at once
David Engel
david at istwok.net
Mon May 6 14:21:29 UTC 2013
On Mon, May 06, 2013 at 07:43:10PM +1200, Stephen Worthington wrote:
> 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.
Good. I just want to follow up with one more thing. When I earlier
said "Not counting start-early and end-late", that was merely to
simplify the problem. You can still use start-early and end-late, but
you need to account for it. Worst case is you need an additional
virtual tuner for every set of overlapping programs.
David
--
David Engel
david at istwok.net
More information about the mythtv-users
mailing list