[mythtv] Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord

Bruce Markey bjm at lvcm.com
Thu Sep 29 21:51:40 UTC 2005


Max Barry wrote:
> 
> Hello,
> 
> Bruce Markey wrote:
> 
>> If you've followed these lists at all, people are often confused
>> by things much less intricate than this. Why scheduling decisions
>> don't make sense is not resolved by -v all and telling them to look
>> through the logs for "+" or "-". That doesn't explain what happened
>> to them last night and why (BTW it should be -v schedule anyway).
> 
> 
> True enough, but just to clear this up, I was responding to your comment 
> that you wouldn't help people until they disabled this feature entirely. 
> I merely meant to point out that you wouldn't need to do that, because 
> you could look at the logs.

But I can't look at someone else's logs for them. I'd have no concern
as to investigating what happens in the scheduling decisions on my
test or production systems. What my concern here is that people will
report that there must be a bug when they see unexpected behavior.
To cite the examples in reply to gigem, I don't want to justify why
it should drop the conclusion of Greatest or subtract 5 minutes when
attempting to add 5 minutes.

The other issue about logging is that running with a verbose flag
and digging through the logs should not be standard operating
procedure for the average user. If the decision is made to plan
to record starting at 7:55, the UI should say so rather than saying
8 and leaving it to the user to look elsewhere to determine if that
really means 8 or 7:55.

>> Also, if the plan is to record an 8 o'clock show from 7:55 until
>> 9:10, the Upcoming Recordings page should reflect this known plan
>> rather than saying 8-9 and leave it to the user to remember, guess
>> or dig through the logs.
> 
> 
> I guess that'd be nice. But it's not what MythTV does now: i.e. a 
> 60-second preroll doesn't get reflected in "Upcoming Recordings." I

Correct.
 
> know, I know, preroll was never intended to record minutes' worth. But 
> I'm not attempting to make big changes, just to turn one hardcoded 
> assumption into a user-malleable setting.

The distinction is that preroll is a feature of the recorder at
runtime independent of the schedule planning and it is none of the
scheduler's business. You are proposing to have soft padding in
the schedule planning stage where decisions are made based on the
additional time. You may want to brush over this by trying to give
the impression that you feel as if you aren't making any big change
but let's at least get on the same page that this distinction does
exist.

If the scheduler is making decisions based on the additional minutes
then there is no reason to keep what it knows as a secret. The
recstartts and recendts should be updated when it is determined that
the padding time will fit. This would be an important improvement
for what you are after because the scheduler can't/won't/shouldn't
show the preroll seconds as, again, this is none of it's business.

>> "Global" isn't the distinguishing feature here. Having a default
>> offset setting for offsets would be global with the advantage that
>> it could then be re-adjusted on a per rule basis rather than blindly
>> applied (or considered) in all cases.
> 
> 
> That would be handy, but only a little, because the great advantage of 
> the preroll/overrecord feature is its softness. You say you don't 
> believe me on this, so I'll address it in detail a little later.

It's not a matter believing you but looking at what will and won't
happen in certain situations. Perhaps you don't believe me that
people will complain, justifiably, that they unexpectedly missed the
conclusion of Greatest, or that something they looked forward to
watching tonight got put off for two days or a recording was moved
to a dual input card blocking a show from the other input. All of
these have been complaints in the past (but obviously due to other
causes).

I understand that you want to maximize the number of shows that have
padding time added. I know that you had simulated the padding
behavior in the past by abusing preroll but get past that and face
up to the fact that planning for padding time in the schedule is
a new and improved feature of the schedule independent of preroll.

I also know that this behavior is not a panacea. It will lead to
disappointments and it not be foisted onto others by default nor
should they be lead to believe that it solve all their woes up
until they find out for themselves that their shows are being
truncated.

> Personally I think default start-early/finish-late is a good idea and 
> should be added to MythTV. But so long as that's a hard setting, it 
> won't address the problem that people with unreliable guide data have.
> 
>> If there are showss that must be recorded consecutively and
>> the times are not reliable then these need to be considered on a
>> case by case basis.
> 
> 
> Sure, if there are only a few shows that are unreliable. But it's not 
> very practical to deal with the majority of recordings (and not just 
> recordings: showings!) on a case-by-case basis.
> 
>>> But more importantly, you end up occasionally creating unintended 
>>> conflicts, because you're changing a hard setting.
>>
>>
>> This is where it becomes magic. I'm thinking of a one hour show at 8PM
>> and another at 9. Can you please tell me if the 8 o'clock show I'm
>> thinking of runs past 21:00:00? Yes or no? Use whatever algorithm
>> you'd like but tell me for a fact if it is okay to stop recording at 9.
> 
> 
> Bruce, you seem set on this idea that programs mostly fall within their 
[Your interpretation is incorrect. The issues remain the same whether
2/100 or 50/100 have content outside the listed time. I know that
people in North America have outright lied about what happened on
national networks in their city ;). You may feel that you can say
whatever you'd like about Australian TV and I can't see for myself.
I don't know what happens there but I do know that later in this
message that you back down from a careless exaggeration when it
turned out to not be advantageous for you. I've also seen posts from
other Australians over the past few years which confirm that times
can be flaky but not to the degree that you are trying to portrait
here.]
> scheduled time. I envy you, but it's not the situation here. The fact 
> is, in Australia it /is/ a lottery as to when shows actually screen. 
> Indeed, MythTV cannot know for a fact when they will screen, as you say, 
[not that it matters but I don't believe I have ever uttered "will
screen" in my entire life but I may from now on .;-]
> but neither can I, as the user.
> 
> You must realize that I'm not here thinking, "I know Battlestar 
> Galactica always starts 12 minutes late, but I can't be bothered just 
> entering that myself, so I want a global default." Rather, I'm thinking, 
> "I don't know exactly when all TV shows will screen, so I want to 
> capture a reasonable buffer around them where possible."

The problem is that you won't get that time you need if some other
crappy show follows.

> Faced with guide data uncertainty and limited resources in terms of hard 
> disk space and tuner cards, the best you can do is stack the odds in 
> your favour. That means applying a pre- and post-recording buffer when 

Agreed. So there is no misunderstanding, I know that is what you
are after.

> it's sensible to do so, but junking it and taking your chances when it's 
> not.
> 
>> Exactly. You, as a human being that watches the shows, know which
>> shows are likely to have content outside the scheduled time and
>> you know what adjustments are appropriate. 
> 
> 
> With respect, this is where you're wrong.

No, I don't believe I am. Humans watch the shows, see what happens,
know a great deal about what the fluctuations and inconsistencies
are, etc. The software has the listings and algorithms then flips
bits. You are in a better position to know what might happen. The
amount of padding time you want is even based on your estimations
and not the system's.

> Most of the time, I don't know 
> that. Sometimes I do, and this is when I manually change the start and 
> end times, just like I'm supposed to. But the fundamental problem is 
> that in Australia TV shows frequently run unexpectedly late (and 
> occasionally unexpectedly early), and you don't know for sure which 
> it'll be.

Which is, of course, why you want extra time. However, the fact
remains that if the extra time is optional, you risk not recording
extra time that you wish you had. This fact does not disappear
because you live in Australia or because it seems too hard to
adjust endtimes or because you can't be sure of the exact minute
it will end.

Your proposed padding should allow moving shows to other cards
and choosing later showings. Both of these would happen with
start/end-offsets. If all the shows fit on the available cards,
the two schedules should be identical. If there is a situation
where the extra time cannot fit then something has to be done. This
was the point of the Greatest vs Who Cares example. Is it better to
assure that you will record the time you anticipate you will need
for your favorite show putting a lower priority show at risk, or
do you want to allow it to silently truncate your favorite show
to record something that you've declared is of less interest to
you?

A question that hasn't come up is; which is worse, missing a
show or missing the ending to a show that you started to watch
but that's not the point. The point is that when shows have to
be recorded consecutively, there is a decision that needs to
be made. Regardless of what scheduling features you use, you should
try to make that decision because you may not like the one handed
to you. This holds true if it happens once a week or several times
in one primetime evening.

It's not cut'n'dired but if I went out of town for a few days and
had shows that I suspected would have content outside the listed
time, I would rather have it record my favorites to completion and
possibly drop some lower priority shows. After all, this kind of
decision is what priorities are for. I'd prefer this over cutting
off the ends of the shows I most looked forward to seeing.

>> If you're going to miss the end of next week's show unless there
>> is time added at the end then you missed the end of this week's
>> show when the time was not added.
> 
> 
> Unfortunately, it doesn't follow that because The Simpsons ran 4 minutes 
> late tonight, it will also run 4 minutes late tomorrow. It might, but it 
> might not. It's precisely because of this uncertainty that there's a 
> need for a soft global pre- and post-recording buffer.

Hard or soft, the same issue exists.

>> The preroll was created to be used by the
>> recorder at record time and deliberately should not impact the schedule.
>> You've decided that the existing variables should be re-interpreted
>> to affect the schedule. I disagree and don't want to have the
>> preroll feature trashed simply because you choose to not see it's
>> value.
> 
> 
> I understand that and respect it, although I will point out that plenty 
> of us are already abusing preroll and overrecord, because it's currently 
> the only way to get MythTV to apply a global soft buffer.

So now it's time to do something better rather than hang a bag
off the side.

> I don't know why you're being hostile; I was just quoting you. I know 
> why preroll and overrecord were created.

At several points you refused to acknowledge the distinction
between the initialization time for the recorder at record time
and planning the schedule. To quote me at this point appeared as
if you were mocking me. If not, I apologize but this appearance
did impact all of my response.

>> And that suggests that there should be default offsets for new rules.
>> Leaving the extra time up to hit or miss happenstance is not a
>> solution.
> 
> 
> Actually, it kinda is. If you have 100% reliable guide data, then no 
> doubt things are nice and easy and you can tell in advance whether you 
> have the resources to fully capture a TV showing.
>
> But when you don't have reliable guide data, you can't avoid 
> happenstance. Even my patch doesn't eliminate that; it just helps users 
> deal with it. You can never be sure that you're going to catch all of 
> any show.

As above. It doesn't matter how often it happens, if you leave
the decision up to the system you may not like what it decides.

>> Based on your own statistics, 49 out of 50 times that the
>> extra time is not applied you will miss content.
> 
> 
> That's prime-time; it's not quite so bad at other times. But I'd guess 
> that around 8 out of 10 Australian TV shows run outside the exact 
> scheduled time by at least 1 minute, often more like 5, and not 
> infrequently 15 - 20.

Same thing. If you're letting it drop the extra time, you're
missing needed content in the majority of cases according to
what you state here.

A better sampling would be, of the times where the extra time
has been dropped for you so far, what percentage of those recording
left you disappointed that you had missed the conclusion. I'm not
talking about credits, promos, previews for next week or such but
how often do you miss the conclusion of the story?

> Now I think you're asking, "If that's the case, why do you want a soft 
> setting? You need a hard one, or you'll miss content." To answer I'll 

Yes, I am.

> give you an example. Let's say I want to record these shows:
> 
> 6:00 - 6:30 Arrested Development
> 6:30 - 7:00 The Simpsons
> 
> For simplicity say they're on the same channel and I only have 1 tuner. 

That's cheating because you know that you'll get the conclusion
of Arrested Development in the recording for The Simpsons.
Arrested Development needs to abruptly end leaving you wondering
what happened.

> Because I have unreliable guide data, I want pre-recording buffers of 2 
> minutes and post-recording buffers of 12 minutes.
> 
> If those buffers are hard (e.g. set manually, as is the only possibility 
> at the moment), here's what MythTV will schedule:
> 
> 5:58 - 6:42 Arrested Development
> The Simpsons -- CONFLICT, NOT RECORDED

It might record The Simpsons over Arrested Development but you
haven't said how you've set the priorities or said which you
prefer.

> If the buffers are soft, though, I get everything, because the 
> in-between buffers are dumped so as to not create a conflict. There's a 
> good chance I'll get the end of Arrested Development on the start of The 

Which invalidates your example. Do I type like I was born yesterday?
Are you suggesting that users should only record shows from one
channel so that this will seem to work out? Or is this the exception
that proves the rule that this doesn't work well unless the back to
back shows are on the same channel?

>> IOW, it's simpler for you to blow off a worthwhile feature and
>> reuse the variables as you see fit? I disagree.
> 
> 
> Well, I would argue that users with unreliable guide data are already 
> (mis-)using this feature in this way, because it makes the software more 
> valuable. My patch doesn't create that situation. It doesn't make it 
> better or worse.

Worse. It heads in the direction that it's supposed to be mysterious
and is supposed to be sneaky and it's supposed continue to abuse
and entirely different but useful feature. Face up to it and do it
right for the long haul rather than another strange hack.

>>> Otherwise you end up with multiple settings for what is, at least at 
>>> first glance,
>>
>>
>> In case you didn't know, I'm well past the first glance.
> 
> 
> Again, Bruce, I'm not sure why you're being so hostile. Clearly I'm not 
> talking about you; I was considering how it might look to a new MythTV 
> user.

The juxtaposition was odd. I meant that I won't be tripped up
by a simple matter of clarifying the UI so that it is obvious
to the user what the differences are. In a way, I look forward
to having soft padding in the scheduler so that the preroll UI
can be set to a max of under a minute and put to rest the belief
that this is supposed to be used for secret, magic behavior.

>> Preroll was created to give the
>> recorder a head start before the scheduled time to allow for
>> initialization. It was not intended to assure capturing content
>> outside of the times in the TV listings. These are very different
>> features to serve very different needs. It is the perception that
>> the ability of the recorder to start a few seconds early could be
>> used as a substitute for planning to have the scheduler include
>> content outside the listings time which is the point of confusion.
>>
>> If you do want minutes of time to record content outside the time
>> in the listings, face up to it, use new variable names, account for
>> the time while planning the schedule and reflect the times that
>> recordings would start and end in the scheduler output.
> 
> 
> I completely understand this.

We'll see.

>  But a global default hard setting would 
> not help me, nor people in my situation.

I disagree. As above prioritizing my favorites that I don't want
to have truncated would be my preference.

But it shows that you didn't completely understand. I wasn't referring
to default start/end-offset, I was referring to making soft padding
part of the scheduler rather than changing preroll.

>> Say "The
>> Greatest Show in the World" has one showing at 8-9 and a priority
>> of +10. "Who Cares?" starring Wink Martindale is on at 9-9:30 with
>> priority -10. Use the same numbers, 7 minutes early and 10 minutes
>> late, doesn't matter. One card (or two cards and the other is
>> recording a long movie or sporting event).
>>
>> With offsets, 'Greatest' is scheduled for 7:53-9:10. Period. It won.
>> Who Cares is marked "C". Now the user can see that and decide if
>> she wants to still record the rest of Wink at 9:10 or if Greatest
>> isn't really going to run late and catch Who Cares from the beginning
>> or whatever.
>>
>> With magic time, The scheduler will simply say 'no problem'. Greatest
>> records from 7:53-9:00 and just as it is about to reach the dramatic
>> season ending cliffhanger, it cuts off to switch over to the crappy
>> game show.
> 
> 
> I agree with your point here, but in this situation users should be 
> using a hard setting, and a manual one. I'm not arguing that soft 
> buffers should replace hard ones. I don't think anybody should rely on a 
> default soft buffer to capture a show that either they know will run 
> late, or is so important that they simply must capture extra buffers.

Agreed.

> The whole idea with soft buffers is that they're non-essential. You use 

But you've said that the content of the shows are most likely to
go outside the listed times so it is essential otherwise the story
will be truncated. You can't have it both way.

> them when you're not sure whether you'll need them: when you'd LIKE to 
> capture extra time, but you don't consider it critical. They work pretty 

I'd consider cutting off my favorite show before the conclusion to
be a critical problem and you've said this would happen for the
majority of the instances.

> well for this (unintended) purpose at the moment, with the exception 
> that they can get dumped while another tuner card sits idle.

Fine, then do it a new intended way for the long haul.

> Anyway. I'm a little concerned that discussion about the utility of my 
> patch has turned into a much wide-ranging debate about pre- and post- 

This isn't a new issue that has come up for the first time. I'm
mot opposed to this functionality (which I won't use), I am opposed
to the implementation. It should not use the preroll variables and
it should display the planned record times in recstartts and recendts.

--  bjm


More information about the mythtv-dev mailing list