Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

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

 

 

First page Previous page 1 2 Next page Last page  View All MythTV dev RSS feed   Index | Next | Previous | View Threaded


gigem at comcast

Sep 26, 2005, 8:29 PM

Post #1 of 31 (6759 views)
Permalink
Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord

On Thu, Sep 15, 2005 at 12:33:32PM -0000, MythTV wrote:
> #255: Improved scheduling of consecutive programs with pre-roll/overrecord
> [...]
> Comment (by Max Barry <mythtv [at] maxbarry>):
>
> As requested by David, I've modified the patch to include a setting with
> which to control its behaviour.

Sorry for taking so long to get back to this. I was preoccupied with
other things for a while.

First, you are querying a number of settings from within loops. This
causes Myth to needlessly fetch things over and over again from the
database. The relevant settings should be queried once per scheduler
pass.

> 3) Apply always. This turns OverTime into a hard setting, which MythTV
> will always obey even if this means creating a conflict.

Second, I agree with Bruce that this option isn't needed. The
existing per-rule start-early and end-late settings can handle this.
To mitigate the tediousness of always using these, I further agree
there should be default values for these that are always used when a
new recording rule is created.

On Fri, Sep 16, 2005 at 05:57:10PM -0700, Mark Kundinger wrote:
> If we're voting on this sort of thing, just a couple of days ago the

No, we're not voting. If we can't reach a consensus, Isaac, Bruce,
myself and the other core contributors will decide what to do.
Personally, I'm happy with the status quo since I have reasonably
accurate guide data and have no problems manually adjusting my
recording scheduls as needed. However, I am sympathetic with those
users with less reliable guide data and their potential need for some
form of "softer" scheduling.

David
--
David Engel
gigem [at] comcast


bjm at lvcm

Sep 27, 2005, 1:25 AM

Post #2 of 31 (6615 views)
Permalink
Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

David Engel wrote:
...
> Personally, I'm happy with the status quo since I have reasonably
> accurate guide data and have no problems manually adjusting my
> recording scheduls as needed.

Agreed.

> However, I am sympathetic with those
> users with less reliable guide data and their potential need for some
> form of "softer" scheduling.

What's always bothered me about this is that preroll serves a
useful purpose and the fact that this magic behavior is possible by
abusing it lead people to jump to the conclusion that this is what
they're supposed to do and the scheduler is therefore supposed to
take it into account.

I'm thinking now that if there is going to be some sort of "softer"
scheduling it should be just that, part of the schedule planning.
I think it would make more sense to have a pair of variables for
this, expressed in minutes, rather than usurping the preroll
variables. These could be applied to the schedule in the context
of scheduling and shown in the Upcoming Recordings (reclist) for
the users to fix whatever problems they create for themselves.

We should leave the preroll seconds out of it and limit their range
to 0-29 seconds to be applied by the recorder at record time as it
is now.

-- bjm


Pascal.Favre at gmx

Sep 27, 2005, 10:39 AM

Post #3 of 31 (6616 views)
Permalink
Re: Re: Ticket #255: Improved scheduling of consecutiveprograms with pre-roll/overrecord [In reply to]

I tried to follow this thread "Improved scheduling of consecutiveprograms with pre-roll/overrecord" but didn't find out what it is
about.
As far as I understood does it take care for the extra time needed to switch channels (reasonable in seconds) ?

What I like to see in mythtv is that I can add an additional default time, say 20 minutes for each movie.
When I have two or more consecutive recordings on the same channel, the extra time is not take into account except for the last
recording.

With the above feature I do not have to take care which movies overlap. Overlapped movies occupie another tuner, which I do not
want, so I have to take care about the extra time specified for each movie.

Please bare in mind that I still have 18.1-fixes, not looking in or testing the svn version, but I am always interested/learn new
features.
Would you think my proposed feature could be of interest ?

Pascal

----- Original Message -----
From: "Bruce Markey" <bjm [at] lvcm>
To: "Development of mythtv" <mythtv-dev [at] mythtv>
Sent: Tuesday, September 27, 2005 10:25 AM
Subject: Re: [mythtv] Re: Ticket #255: Improved scheduling of consecutiveprograms with pre-roll/overrecord


> David Engel wrote:
> ...
>> Personally, I'm happy with the status quo since I have reasonably
>> accurate guide data and have no problems manually adjusting my
>> recording scheduls as needed.
>
> Agreed.
>
>> However, I am sympathetic with those
>> users with less reliable guide data and their potential need for some
>> form of "softer" scheduling.
>
> What's always bothered me about this is that preroll serves a
> useful purpose and the fact that this magic behavior is possible by
> abusing it lead people to jump to the conclusion that this is what
> they're supposed to do and the scheduler is therefore supposed to
> take it into account.
>
> I'm thinking now that if there is going to be some sort of "softer"
> scheduling it should be just that, part of the schedule planning.
> I think it would make more sense to have a pair of variables for
> this, expressed in minutes, rather than usurping the preroll
> variables. These could be applied to the schedule in the context
> of scheduling and shown in the Upcoming Recordings (reclist) for
> the users to fix whatever problems they create for themselves.
>
> We should leave the preroll seconds out of it and limit their range
> to 0-29 seconds to be applied by the recorder at record time as it
> is now.
>
> -- bjm
>


--------------------------------------------------------------------------------


_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


gigem at comcast

Sep 27, 2005, 8:41 PM

Post #4 of 31 (6604 views)
Permalink
Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

On Tue, Sep 27, 2005 at 01:25:19AM -0700, Bruce Markey wrote:
> I'm thinking now that if there is going to be some sort of "softer"
> scheduling it should be just that, part of the schedule planning.
> I think it would make more sense to have a pair of variables for
> this, expressed in minutes, rather than usurping the preroll
> variables.

That sounds appealing conceptually. However, I fear the changes to
the scheduler would be more invasive than I would like. The current,
abused, post-roll mechanism is nice to the scheduler in that it is
fire and forget. Making the scheduler more aware of soft padding
would mean keeping track of when the padding has been added and when
it hasn't, informing a recorder when the padding has to be changed
after the fact, etc.

Full soft padding could also open up whole new cans of worms. What if
some, but not all, of the soft padding between two programs could be
honored, should the scheduler split the difference? Should that
behavior be different if the programs ares on the same channel.
Should the scheduler try to force back to back (with or without
padding) programs on the same channel to the same card? ...

> These could be applied to the schedule in the context
> of scheduling and shown in the Upcoming Recordings (reclist) for
> the users to fix whatever problems they create for themselves.

That could lead to some strange things. What if the user tries to fix
things up by adjusting the hard start-early or end-late settings and
instead winds up receiving a whole new scheduling result?

David
--
David Engel
gigem [at] comcast


bjm at lvcm

Sep 28, 2005, 1:18 AM

Post #5 of 31 (6616 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

David Engel wrote:
> On Tue, Sep 27, 2005 at 01:25:19AM -0700, Bruce Markey wrote:
>
>>I'm thinking now that if there is going to be some sort of "softer"
>>scheduling it should be just that, part of the schedule planning.
>>I think it would make more sense to have a pair of variables for
>>this, expressed in minutes, rather than usurping the preroll
>>variables.
>
>
> That sounds appealing conceptually. However, I fear the changes to
> the scheduler would be more invasive than I would like. The current,

Doesn't parse. There are the same issues no matter what the variables
are named. What I'm saying is that the pre-roll is a useful feature
and it should not be abandoned. Whatever this magic behavior is, it
can be implemented using a different set of variables without usurping
the existing leader time. Further, apparently this behavior is thought
of in terms of minutes. I wouldn't expect that someone would insist
that it be set to 6:37 (397sec) or such. Call a spade a spade and
leave preroll out of it.

> abused, post-roll mechanism is nice to the scheduler in that it is
> fire and forget. Making the scheduler more aware of soft padding
> would mean keeping track of when the padding has been added and when
> it hasn't, informing a recorder when the padding has to be changed
> after the fact, etc.

It shouldn't change after the fact. Either it should plan to start
five minutes early or it shouldn't. Recstartts and recendts should
reflect what is planned at the end of placement in a pass after the
initial placement much like SMH. This doesn't need to tracked but
regenerated on each run. Endts + endoffset + magictime if it fits.

> Full soft padding could also open up whole new cans of worms. What if
> some, but not all, of the soft padding between two programs could be
> honored, should the scheduler split the difference? Should that

Guess what? it's problematic. What should happen in this instance
no matter how it's approached. Whatever the decision is should be
reflected in the reclist and not a surprise after the fact.

> behavior be different if the programs ares on the same channel.
> Should the scheduler try to force back to back (with or without
> padding) programs on the same channel to the same card? ...

Same thing. How should that situation be handled no matter how it's
approached? Whatever the algorithm, viewscheduled should show what
that decision will be so the user knows what to expect. Keeping the user
in the dark won't make the behavior any better no matter how strongly
anyone believes that by keeping their eyes shut, an ambiguous feature
will automatically solve all their scheduling problems.

Not letting the user know what was going to happen until it came
time to start recording is, I believe, one of the many reasons that
SonicBlue went bankrupt.

>>These could be applied to the schedule in the context
>>of scheduling and shown in the Upcoming Recordings (reclist) for
>>the users to fix whatever problems they create for themselves.
>
>
> That could lead to some strange things. What if the user tries to fix
> things up by adjusting the hard start-early or end-late settings and
> instead winds up receiving a whole new scheduling result?

Currently, changing the offsets for consecutive recordings can result
in a whole new schedule so I fail to see the point as far as making
changes affecting other things in the schedule. That's a given. If
you mean that it would become like herding kittens to try to control
your schedule, I agree and this is one of my concerns. I wouldn't
want to field question like 'why can't I record one of my favorite
shows on card 1 no matter how I set the priority' or 'why can't I
get this to record on my digital input rather than analog' or 'I
can't record Nova on Tuesday unless I "Don't record" Nip/Tuck even
though they are on at different times'.

-- bjm


gigem at comcast

Sep 28, 2005, 3:33 PM

Post #6 of 31 (6596 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

On Wed, Sep 28, 2005 at 01:18:14AM -0700, Bruce Markey wrote:
> David Engel wrote:
> >That sounds appealing conceptually. However, I fear the changes to
> >the scheduler would be more invasive than I would like. The current,
>
> Doesn't parse. There are the same issues no matter what the variables
> are named. What I'm saying is that the pre-roll is a useful feature
> and it should not be abandoned. Whatever this magic behavior is, it

I think we agree. My point is that if we want to support soft
scheduling, we should add first class support for it and not let it
just fall out as a result of mis-using pre/post-roll.

> >abused, post-roll mechanism is nice to the scheduler in that it is
> >fire and forget. Making the scheduler more aware of soft padding
> >would mean keeping track of when the padding has been added and when
> >it hasn't, informing a recorder when the padding has to be changed
> >after the fact, etc.
>
> It shouldn't change after the fact. Either it should plan to start
> five minutes early or it shouldn't. Recstartts and recendts should
> reflect what is planned at the end of placement in a pass after the
> initial placement much like SMH. This doesn't need to tracked but
> regenerated on each run. Endts + endoffset + magictime if it fits.

What about the in-progress end-time support we just added? It keys
off detecting changes between the new end-time and what it was when
the recording was started. To know if the user changed the end-time,
we would need to remember if (and maybe how much of) a magictime was
added.

> >Full soft padding could also open up whole new cans of worms. What if
> >some, but not all, of the soft padding between two programs could be
> >honored, should the scheduler split the difference? Should that
>
> Guess what? it's problematic. What should happen in this instance
> no matter how it's approached. Whatever the decision is should be
> reflected in the reclist and not a surprise after the fact.

Agreed.

> >That could lead to some strange things. What if the user tries to fix
> >things up by adjusting the hard start-early or end-late settings and
> >instead winds up receiving a whole new scheduling result?
>
> Currently, changing the offsets for consecutive recordings can result
> in a whole new schedule so I fail to see the point as far as making
> changes affecting other things in the schedule. That's a given. If

Boy, I screred up that question. It should been along the lines what
if the user adjust the start-early or end-late settings and nothing
changes? This could happen if partial padding was done.

David
--
David Engel
gigem [at] comcast


bjm at lvcm

Sep 28, 2005, 5:54 PM

Post #7 of 31 (6616 views)
Permalink
Re: Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

David Engel wrote:
> On Wed, Sep 28, 2005 at 01:18:14AM -0700, Bruce Markey wrote:
>
>>David Engel wrote:
>>
>>>That sounds appealing conceptually. However, I fear the changes to
>>>the scheduler would be more invasive than I would like. The current,
>>
>>Doesn't parse. There are the same issues no matter what the variables
>>are named. What I'm saying is that the pre-roll is a useful feature
>>and it should not be abandoned. Whatever this magic behavior is, it
>
>
> I think we agree. My point is that if we want to support soft
> scheduling, we should add first class support for it and not let it
> just fall out as a result of mis-using pre/post-roll.

Right, just so no one misunderstands, I'm not opposed to adding a new
feature that people may feel would be beneficial. I wouldn't use it
myself and wouldn't recommend it others because of some pitfalls.
However, my main point is that it should be addressed up front for
what it is and not snuck in as an extension of mis-using pre/post-roll.

>>>abused, post-roll mechanism is nice to the scheduler in that it is
>>>fire and forget. Making the scheduler more aware of soft padding
>>>would mean keeping track of when the padding has been added and when
>>>it hasn't, informing a recorder when the padding has to be changed
>>>after the fact, etc.
>>
>>It shouldn't change after the fact. Either it should plan to start
>>five minutes early or it shouldn't. Recstartts and recendts should
>>reflect what is planned at the end of placement in a pass after the
>>initial placement much like SMH. This doesn't need to tracked but
>>regenerated on each run. Endts + endoffset + magictime if it fits.
>
>
> What about the in-progress end-time support we just added? It keys

Hey, I'd taken that for granted. If the endoffset is changed, the
scheduler should recalculate any extra overtime during the run.

> off detecting changes between the new end-time and what it was when
> the recording was started. To know if the user changed the end-time,
> we would need to remember if (and maybe how much of) a magictime was
> added.

Not sure I follow. If the magictime is stored in the settings and
the scheduler is run after an endtime change (or adding a new
recording to follow the in-progress show(!) for that matter), the
scheduler should reassess recendts by endts + endoffset + magictime
if it fits.

>>>Full soft padding could also open up whole new cans of worms. What if
>>>some, but not all, of the soft padding between two programs could be
>>>honored, should the scheduler split the difference? Should that
>>
>>Guess what? it's problematic. What should happen in this instance
>>no matter how it's approached. Whatever the decision is should be
>>reflected in the reclist and not a surprise after the fact.
>
>
> Agreed.
>
>
>>>That could lead to some strange things. What if the user tries to fix
>>>things up by adjusting the hard start-early or end-late settings and
>>>instead winds up receiving a whole new scheduling result?
>>
>>Currently, changing the offsets for consecutive recordings can result
>>in a whole new schedule so I fail to see the point as far as making
>>changes affecting other things in the schedule. That's a given. If
>
>
> Boy, I screred up that question. It should been along the lines what
> if the user adjust the start-early or end-late settings and nothing
> changes? This could happen if partial padding was done.

I see. Yes that is another point for confusion. If a system was set
for 7 minutes early and 10 minutes late magic time and there was
a show from 8-9 and a movie started on another channel at 9:20.
The show should record until 9:10 and the movie starts at 9:13.
The user sees that the show started even later and decides she needs
to record the until 9:15. She adds 5min endoffset and now the magic
time doesn't fit so the show ends at 9:05 and the movie doesn't
record until 9:20. Notice that if viewscheduled said all along that
the show's end was 9:00 then 9:05 and the movie always said 9:20,
the user would be left to their own wits to figure out that the
change had the reverse effect and they had blown the magic time.


While I'm on examples, here's a simple example of why the user
should prefer default start/end-offset over magic time. 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.

-- bjm


gigem at comcast

Sep 29, 2005, 3:39 PM

Post #8 of 31 (6564 views)
Permalink
Re: Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

On Wed, Sep 28, 2005 at 05:54:08PM -0700, Bruce Markey wrote:
> David Engel wrote:
> Not sure I follow. If the magictime is stored in the settings and
> the scheduler is run after an endtime change (or adding a new
> recording to follow the in-progress show(!) for that matter), the
> scheduler should reassess recendts by endts + endoffset + magictime
> if it fits.

I was thinking of the inevitable next feature request concerning soft
times. That is, "well, if you can't honor all of the padding, at
least honor some of it." IOW, recendts = endts + endoffset + F *
magictime, where 0 <= F <= 1 and can change from one pass to another.

> to record the until 9:15. She adds 5min endoffset and now the magic
> time doesn't fit so the show ends at 9:05 and the movie doesn't
> record until 9:20. Notice that if viewscheduled said all along that

That's not the case I was thinking about, but it makes the point even
better. Good one.

David
--
David Engel
gigem [at] comcast


gigem at comcast

Sep 29, 2005, 3:48 PM

Post #9 of 31 (6561 views)
Permalink
Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

On Wed, Sep 28, 2005 at 11:51:21PM -0700, Mark Kundinger wrote:
> Here's what I forsee would be the most flexible, power-usery, and
> hardest to understand way of approaching this:
> [...]
> ... I dunno, sounds like a lot of work? I can see it helping out my
> own tv-watching, but only rarely. Kind of like swatting a fly with a
> bulldozer.

You captured my sentiments exactly.

I know this is going to piss off some people, but here is what I now
intend to do.

1. Table any changes which add soft scheduling for the time being.

2. Add default start-early and end-late settings for new recording
rules. Existing rules will have to be edited if wanted.

3. Limit the existing pre-roll and post-roll settings to 30 seconds
maximum.

4. After 3 or 4 weeks, re-open this discussion. Hopefully by then,
the big soft scheduling proponents will have real world experience
with the above changes and how much of a problem there still is.

David
--
David Engel
gigem [at] comcast


hamish at cloud

Sep 29, 2005, 4:03 PM

Post #10 of 31 (6552 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

On Thu, Sep 29, 2005 at 05:48:37PM -0500, David Engel wrote:
> I know this is going to piss off some people, but here is what I now
> intend to do.
>
> 1. Table any changes which add soft scheduling for the time being.
>
> 2. Add default start-early and end-late settings for new recording
> rules. Existing rules will have to be edited if wanted.
>
> 3. Limit the existing pre-roll and post-roll settings to 30 seconds
> maximum.
>
> 4. After 3 or 4 weeks, re-open this discussion. Hopefully by then,
> the big soft scheduling proponents will have real world experience
> with the above changes and how much of a problem there still is.

Is #3 particularly useful/necessary?

Australian television stations are appalling for running late. One
station in particular routinely runs 15-20 minutes late due to live
reality television programs (even though they know this always happen
and could schedule for it).

I'm abusing post-roll by setting it to 20 minutes. This works as poor
man's soft scheduling so far. In my case I could put a hard 20 minutes
on every program as I have three tuners and would probably never get a
conflict. Currently my third tuner only does about 1 hour a week.

However, most Australian users would not (we only have 5 OTA stations
so 3 tuners is excessive); hard extra time would cause conflicts, while
post-roll allows for best effort. Programs are rarely repeated here
so a conflict is a missed program.

Of course I'm really arguing for the soft scheduler, which would be
great for Australians. (I've even glanced at the scheduler code in the
past but found it a bit daunting to start working on this though.)
However I think your interim solution would actually make things worse.

Regards,
Hamish
--
Hamish Moffatt VK3SB <hamish [at] debian> <hamish [at] cloud>


mtdean at thirdcontact

Sep 29, 2005, 6:09 PM

Post #11 of 31 (6576 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

David Engel wrote:

>I know this is going to piss off some people, but here is what I now
>intend to do.
>
>1. Table any changes which add soft scheduling for the time being.
>
>2. Add default start-early and end-late settings for new recording
> rules. Existing rules will have to be edited if wanted.
>
>3. Limit the existing pre-roll and post-roll settings to 30 seconds
> maximum.
>
>4. After 3 or 4 weeks, re-open this discussion. Hopefully by then,
> the big soft scheduling proponents will have real world experience
> with the above changes and how much of a problem there still is.
>
>
I love this plan, but would like to make one suggestion. Can we change
the help text associated with pre-/post-roll to include the text, "up to
30 seconds," so we don't get a slew of, "Global start early/end late
won't let me record more than 30 seconds extra!" posts? If you don't
want the specific value in there (for maintainability), we could say "a
few seconds" or "several seconds" or "a short time" or something.

My recommended help text (with changes "underlined"):

For RecordPreRoll:
This global setting allows the recorder to start _up to 30 seconds_
before the scheduled start time. It does not affect the scheduler. It is
ignored when two shows have been scheduled without enough time in between.

For RecordOverTime:
This global setting allows the recorder to record _up to 30 seconds_
beyond the scheduled end time. It does not affect the scheduler. It is
ignored when two shows have been scheduled without enough time in between.

Hmmm. Now that I think about it, this ingenious plan makes an
assumption that may not hold up--that people will actually read the help
text... ;) Well, at least we could quote the help text in the replies.

Thanks,
Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


ijr at case

Sep 29, 2005, 6:37 PM

Post #12 of 31 (6568 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

On Thursday 29 September 2005 06:48 pm, David Engel wrote:
> You captured my sentiments exactly.
>
> I know this is going to piss off some people, but here is what I now
> intend to do.
>
> 1. Table any changes which add soft scheduling for the time being.
>
> 2. Add default start-early and end-late settings for new recording
> rules. Existing rules will have to be edited if wanted.
>
> 3. Limit the existing pre-roll and post-roll settings to 30 seconds
> maximum.

My global pre/post roll settings have been set to 3 minutes each for several
years now.

Isaac


lists at qucae

Sep 29, 2005, 7:18 PM

Post #13 of 31 (6555 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

Isaac Richards wrote:
> On Thursday 29 September 2005 06:48 pm, David Engel wrote:
>

>>
>>3. Limit the existing pre-roll and post-roll settings to 30 seconds
>> maximum.
>
>
> My global pre/post roll settings have been set to 3 minutes each for several
> years now.
>
> Isaac
>

Same here. 3 minutes has been a very good saftey for both clock drift
and networks that start shows one or two minutes early early/late. I
have had it configured that way for as long as I can remember. I really
fail to see the usefulness for this feature if it is limited to 30 seconds.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


bjm at lvcm

Sep 29, 2005, 7:37 PM

Post #14 of 31 (6559 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

Isaac Richards wrote:
...
> My global pre/post roll settings have been set to 3 minutes each for several
> years now.

Kinda fingured you did. I end 24sec late which is enough to catch
TDS 'your moment of zen' Survivor loser comments and through the
closing logo after American Idol live shows. Never needed more
than that.

Would you want the scheduler to show the actual start and end
times? Would you want the shows moved to other cards or other
times for the sake of including the extra time?

-- bjm


gigem at comcast

Sep 29, 2005, 7:40 PM

Post #15 of 31 (6564 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

On Fri, Sep 30, 2005 at 09:03:55AM +1000, Hamish Moffatt wrote:
> On Thu, Sep 29, 2005 at 05:48:37PM -0500, David Engel wrote:
> > 3. Limit the existing pre-roll and post-roll settings to 30 seconds
> > maximum.
>
> Is #3 particularly useful/necessary?

The main reason is to try to force people to use startoffset and
endoffset. There have been a lot of theoretical arguments, both in
this thread and in the past, that large amounts of soft padding are
needed. However, I don't recall hearing any of those people say they
actually tried using the hard offsets and found they caused serious
problems.

I have a feeling that using hard offsets won't be a serious problem
for most people. As I said, we'll re-evaluate the situation in a few
weeks. If something more is needed, we'll address it, but we'll
address it fully in the scheduler and not as a side effect of recorder
startup and teardown.

David
--
David Engel
gigem [at] comcast


gigem at comcast

Sep 29, 2005, 7:47 PM

Post #16 of 31 (6568 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

On Thu, Sep 29, 2005 at 09:37:21PM -0400, Isaac Richards wrote:
> On Thursday 29 September 2005 06:48 pm, David Engel wrote:
> > 3. Limit the existing pre-roll and post-roll settings to 30 seconds
> > maximum.
>
> My global pre/post roll settings have been set to 3 minutes each for several
> years now.

How often do those 3 minutes actually matter? I use 5 seconds for
pre-roll and 15 seconds for post-roll and has always been enough for
my needs. If 30 seconds is too small, suggest another value.

David
--
David Engel
gigem [at] comcast


ijr at case

Sep 29, 2005, 10:39 PM

Post #17 of 31 (6578 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

On Thursday 29 September 2005 10:37 pm, Bruce Markey wrote:
> Isaac Richards wrote:
> ...
>
> > My global pre/post roll settings have been set to 3 minutes each for
> > several years now.
>
> Kinda fingured you did. I end 24sec late which is enough to catch
> TDS 'your moment of zen' Survivor loser comments and through the
> closing logo after American Idol live shows. Never needed more
> than that.

It's caught some stuff that went late and wasn't scheduled to. Also helps
when my clock's slightly off. =)

> Would you want the scheduler to show the actual start and end
> times?

Doesn't really matter to me. With very few exceptions, all my recordings are
anytime channel-based - I rarely care to look at when it actually recorded.

> Would you want the shows moved to other cards or other
> times for the sake of including the extra time?

I think it makes sense to, if it doesn't cause a conflict. The original
pre/post-roll stuff was written when there was only support for one tuner,
remember.

I don't really see how 'record this much extra if you can without creating
conflicts, and use other tuners if possible' is any less deterministic than
the current behavior, really.

Isaac


Dibblahmythml0015 at pendor

Sep 30, 2005, 12:03 AM

Post #18 of 31 (6573 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

David Engel wrote:
> 3. Limit the existing pre-roll and post-roll settings to 30 seconds
> maximum.

Why 30 seconds? Wasn't this setting added originally for "slow start"
recorders? Such as machines that are WOL woken?

Cheers,

Allan.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


mythtv at edsons

Sep 30, 2005, 12:20 AM

Post #19 of 31 (6578 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

Hamish Moffatt wrote:

>On Thu, Sep 29, 2005 at 05:48:37PM -0500, David Engel wrote:
>
>
>>I know this is going to piss off some people, but here is what I now
>>intend to do.
>>
>>1. Table any changes which add soft scheduling for the time being.
>>
>>2. Add default start-early and end-late settings for new recording
>> rules. Existing rules will have to be edited if wanted.
>>
>>3. Limit the existing pre-roll and post-roll settings to 30 seconds
>> maximum.
>>
>>4. After 3 or 4 weeks, re-open this discussion. Hopefully by then,
>> the big soft scheduling proponents will have real world experience
>> with the above changes and how much of a problem there still is.
>>
>>
>
>Is #3 particularly useful/necessary?
>
>Australian television stations are appalling for running late. One
>station in particular routinely runs 15-20 minutes late due to live
>reality television programs (even though they know this always happen
>and could schedule for it).
>
>I'm abusing post-roll by setting it to 20 minutes. This works as poor
>man's soft scheduling so far. In my case I could put a hard 20 minutes
>on every program as I have three tuners and would probably never get a
>conflict. Currently my third tuner only does about 1 hour a week.
>
>However, most Australian users would not (we only have 5 OTA stations
>so 3 tuners is excessive); hard extra time would cause conflicts, while
>post-roll allows for best effort. Programs are rarely repeated here
>so a conflict is a missed program.
>
>Of course I'm really arguing for the soft scheduler, which would be
>great for Australians. (I've even glanced at the scheduler code in the
>past but found it a bit daunting to start working on this though.)
>However I think your interim solution would actually make things worse.
>
>Regards,
>Hamish
>
>
Australia is not the only country with abominal schedule info. The
commercial broadcasters in the Netherlands also have a tendency to give
schedule info which is close to "we intent this, what we do is something
else".

I started with abusing the pre-roll / post-roll. Results were most
certainly not to my liking:
- i never could know when the recording would be recorded
- i had several very surprising results (cut endings, which i consider
to be worse than lost recording)
In the end i have taken care to have extra tuner capacity, and at the
moment i consistently add at least 10 min to every recording when
scheduling this recording.
1 recording schedule at the moment has 1 hour extra time, as the
behaviour on that Belgium channel is abominal at the moment. And missing
the end of a thriller like series is really irritating.

Option 2 would ease my life considerably.

Face up to it. Soft scheduling will still result in unexpected
behaviour. Spend 50bucks to get an extra tuner and spare yourself the
disappointment.

Regards,

Rudy
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


willu.mailingLists at cse

Sep 30, 2005, 6:26 AM

Post #20 of 31 (6573 views)
Permalink
Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

On 30/09/2005, at 11:30 AM, mythtv-dev-request [at] mythtv wrote:

> Date: Thu, 29 Sep 2005 17:48:37 -0500
> From: David Engel <gigem [at] comcast>
> Subject: [mythtv] Re: Re: Ticket #255: Improved scheduling of
> consecutive programs with pre-roll/overrecord
> Message-ID: <20050929224837.GB4437 [at] opu>
>
> On Wed, Sep 28, 2005 at 11:51:21PM -0700, Mark Kundinger wrote:
>
>> Here's what I forsee would be the most flexible, power-usery, and
>> hardest to understand way of approaching this:
>> [...]
>> ... I dunno, sounds like a lot of work? I can see it helping out my
>> own tv-watching, but only rarely. Kind of like swatting a fly with a
>> bulldozer.
>>
>
> You captured my sentiments exactly.
>
> I know this is going to piss off some people, but here is what I now
> intend to do.
>
> 1. Table any changes which add soft scheduling for the time being.
>
> 2. Add default start-early and end-late settings for new recording
> rules. Existing rules will have to be edited if wanted.
>
> 3. Limit the existing pre-roll and post-roll settings to 30 seconds
> maximum.
>
> 4. After 3 or 4 weeks, re-open this discussion. Hopefully by then,
> the big soft scheduling proponents will have real world experience
> with the above changes and how much of a problem there still is.

I had tried to stay out of the fight, but the above email seems quite
aggressive, and I want to at least defend the status quo. If you
really implemented the above it would have a large effect on the
utility of my Myth box. Of course, I'd simply revert that revision
in my working copy, but can I request that you not make this regression.

Yes, here in Aus we do need extra soft timing. It is usually a
delay, requiring extra time at the end of a show, but not always. I
have my box set to record 2mins extra before and 7.5 mins after. I
would have them longer, but I didn't want to waste disk space - I
wish I could set them longer on individual shows. I use the hard
time adjustments on individual programs as well. The problem I have
with the hard adjustments is that often shows in Aus are moved
around. If I have extended the record time of a program because it
runs long, and then a program I want to catch gets moved after it on
the same channel, then my extension of the original program will
cause a conflict. What I really want is that both programs are
recorded in this case. Sure, the end of the first program will be on
the start of the second, but that's ok. The end of the second
program will be caught by its time extension.

The above scenario is common for me. With only 5 channels in Aus, it
is not uncommon that programs I want to record follow each other on
the same channel. At the moment I have to review the schedule to
make sure the scheduler is doing what I want. I would rather that
the scheduler was smarter and able to handle this case for me.
Making appliances smarter can often be a problem, because later you
have to outsmart the 'smart' algorithm to get it to do what you
want. :) I think it is possible to come up with a system that works
well, is easy to override, and isn't too complex for the user in the
common cases.

Here are my thoughts on that (because you know you needed more :) :

Imagine there are two shows "Better" and "Worse". Each has both pre
and post soft time adjustments.

Here are the dimensions along which things can change:
- Do soft times overlap
- Do hard times overlap
- Are the shows on the same channel
- Is there a spare tuner
- Does the spare tuner have a lower priority
- Does Worse have another showing
- Is that other showing is on a lower priority channel
- Does Better have another showing
- Is that other showing is on a lower priority channel
- How much better is Better than Worse
- How much more annoying is it to miss the end rather than the
beginning of a show
- Does one program running long delay programs that come after it
on the same channel

While I was trying to be complete, that is a lot of things to
consider. Settings for all of them would be major featureitis.
Especially as there is currently only one setting for scheduling:
"Reschedule higher priorities".

So, here is what I would do:

Separate pre/post-roll and soft time adjustments. Each show gets
gets four settings: hard and soft, pre and post time adjustments.
There are also global defaults that get used as initial values for
these four settings for new shows. There are also the following
global settings:

1a) Reschedule higher priorities (boolean), or
1b) Later showing priority delta (integer)
2) Reschedule soft time adjustments (boolean)
3) Soft end time adjustment priority delta (integer)
4) Propagate soft time adjustments (boolean)

Shows are then scheduled as follows:

- If soft times do not overlap then both shows can be recorded -
there is no problem.
- If the hard times overlap then things are scheduled as they
currently are (using 1a). See below for my thoughts about replacing
1a with 1b.
- If the shows are on the same channel, then the overlapping soft
adjustments should be reduced and both shows scheduled on the same
tuner (All the data will be in at least one recording, and this sets
things up for a later change that duplicates the overlapped data into
both recordings while only using one tuner). In this case, option 4
causes the soft end time adjustment of the later show to be set to
the maximum of the soft end times of the two shows. This deals with
the case where the earlier show runs late making the second show run
late.
- If the shows are on different channels and there is a spare
tuner, then use the spare tuner.

We are now down to the case where there is no spare tuner, the shows
are on different channels, and their soft times overlap but their
hard times do not.

- If 2 is set, and either Worse has a later showing or, both
preference 1 is set and Better has a latter showing, then move the
show with the later showing to that later showing. Otherwise there
is a soft conflict.

- In case of an unresolvable conflict between soft times, then you
need to work out which soft time (post of earlier show, or pre of
later show) has priority. Take the number from preference 3 and add
it to the priority of the earlier show. You compare that sum to the
priority of the later show. If the earlier show's adjusted priority
is higher then you keep the soft post-time adjustment of the earlier
show, and reduce the pre-time adjustment of the later show (normal
case). If the later show's number is higher, then you keep the pre-
time adjustment of that later show, and reduce the post-time
adjustment of the earlier show (abnormal case). If you've reduced
one show's soft time adjustment to zero and there is still overlap,
then reduce the other show's soft time adjustment as necessary.

Note that in this last case a priority adjustment was used to
determine if we should record the end of one program or the start of
the next. If the two programs are similar priority, then you
probably want to record the end rather than the start. However, if
the two programs are wildly dissimilar in priority, then I want to
make sure I record the higher priority one, and I don't care if I
miss some of the lower priority one. Having a numeric adjustment
here allows me to set this tradeoff. The other thing about this is
that while the global setting is a little tricky to understand, it
has the nice side effect that simply raising the priority of a
program will, at some point, cause it's pre-roll to take effect. The
details might be tricky, but there is a simple and obvious action
that has the right effect at some point.

It is for this last reason that I mentioned 1b as well as 1a. I'd
replace the current "Reschedule Higher Priorities" setting with a
similar "priority delta" setting. If the priority of Better is
really high, then it will not be re-scheduled. If the priority of
Better is only a little higher than the priority of Worse, then
Better can be rescheduled. While the global settings are more
complex, raising the priority of a show will cause it to be scheduled
earlier, and that is something that is very easy for users to
understand.

Be well,

Will :-}

--
Dr William Uther National ICT Australia
Phone: +61 2 8306 0424 Computer Science and Engineering
Email: william.uther [at] nicta University of New South Wales
Email: willu [at] cse Sydney, Australia

Web: http://www.cse.unsw.edu.au/~willu/ or http://www.nicta.com.au/

NICTA email Disclaimer:
http://www.cse.unsw.edu.au/~willu/NICTAEmailDisclaimer.html
UNSW email Disclaimer:
http://www.eng.unsw.edu.au/emaildis.htm


warlord at MIT

Sep 30, 2005, 8:48 AM

Post #21 of 31 (6574 views)
Permalink
Re: Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

David Engel <gigem [at] comcast> writes:

> On Thu, Sep 29, 2005 at 09:37:21PM -0400, Isaac Richards wrote:
>> On Thursday 29 September 2005 06:48 pm, David Engel wrote:
>> > 3. Limit the existing pre-roll and post-roll settings to 30 seconds
>> > maximum.
>>
>> My global pre/post roll settings have been set to 3 minutes each for several
>> years now.
>
> How often do those 3 minutes actually matter? I use 5 seconds for
> pre-roll and 15 seconds for post-roll and has always been enough for
> my needs. If 30 seconds is too small, suggest another value.

Those extra three minutes have mattered to me (actually, I have mine
set to 60 seconds, but the point remains -- I've actually lost some
trailers because 60 seconds wasn't long enough).

-derek
--
Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
Member, MIT Student Information Processing Board (SIPB)
URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH
warlord [at] MIT PGP key available


mkundinger at yahoo

Sep 30, 2005, 5:15 PM

Post #22 of 31 (6531 views)
Permalink
Re: Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

--- David Engel <gigem [at] comcast> wrote:

> On Thu, Sep 29, 2005 at 09:37:21PM -0400, Isaac Richards wrote:
> > On Thursday 29 September 2005 06:48 pm, David Engel wrote:
> > > 3. Limit the existing pre-roll and post-roll settings to 30
> seconds
> > > maximum.
> >
> > My global pre/post roll settings have been set to 3 minutes each
> for several
> > years now.
>
> How often do those 3 minutes actually matter? I use 5 seconds for
> pre-roll and 15 seconds for post-roll and has always been enough for
> my needs. If 30 seconds is too small, suggest another value.
>
> David


Absent other changes with scheduling, I would recommend one of two
values for the max pre-roll setting:

1) 999 (the max that would presumably fit in the interface)
2) whatever the max currently is.

Just to avoid user disruption.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


gigem at comcast

Sep 30, 2005, 7:25 PM

Post #23 of 31 (6557 views)
Permalink
Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

On Fri, Sep 30, 2005 at 11:26:09PM +1000, William Uther wrote:
> While I was trying to be complete, that is a lot of things to
> consider. Settings for all of them would be major featureitis.

That's still an understatement!

> So, here is what I would do:
>
> Separate pre/post-roll and soft time adjustments. Each show gets
> gets four settings: hard and soft, pre and post time adjustments.
> There are also global defaults that get used as initial values for
> these four settings for new shows. There are also the following
> global settings:
>
> 1a) Reschedule higher priorities (boolean), or
> 1b) Later showing priority delta (integer)
> 2) Reschedule soft time adjustments (boolean)
> 3) Soft end time adjustment priority delta (integer)
> 4) Propagate soft time adjustments (boolean)
> [much more deleted]

Great. When can we expect your patch? :)

I'm only partly joking since I would dearly love to see how someone
else would approach the scheduling task and come up with working code.

My quick hack is attached. It's admittedly going to be somewhat
inefficient due to its brute force nature. However, it leverages the
existing scheduler logic by sticking with the concept of throwing all
combinations into the mix, assigning priorities (either explicitly or
implicitly) and seeing what comes out the other end.

For those that would like to try it, tweak the softstart* and softend*
assignements at the end of the patch. For best results, keep
softendpri >= softstartpri and softendoffset >= softstartoffset.

Please note that it breaks changing the end-time of in-progress
recordings, so that feature is disabled. It can be fixed. Also, the
heuristics used to break ties between equal priorities are
simple-minded. They can be improved if needed.

David
--
David Engel
gigem [at] comcast
Attachments: soft3.patch (4.05 KB)


mythtv at maxbarry

Sep 30, 2005, 9:44 PM

Post #24 of 31 (6551 views)
Permalink
Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

David Engel wrote:
> On Thu, Sep 29, 2005 at 09:37:21PM -0400, Isaac Richards wrote:
>> On Thursday 29 September 2005 06:48 pm, David Engel wrote:
>> > 3. Limit the existing pre-roll and post-roll settings to 30 seconds
>> > maximum.
>>
>> My global pre/post roll settings have been set to 3 minutes each for several
>> years now.
>
> How often do those 3 minutes actually matter? I use 5 seconds for
> pre-roll and 15 seconds for post-roll and has always been enough for
> my needs. If 30 seconds is too small, suggest another value.

It seems odd that you'd deliberately try to implement a ceiling value
for overrecord that's high enough to let Isaac catch the end of shows
that drift late, but low enough to prevent users faced with more
temporally-challenged TV networks from doing the same.

I'm also confused about why my patch should be denied on the basis that
it makes overrecord more effective at a purpose for which it was not
intended (i.e. to catch shows that unexpectedly drift late), when just a
few weeks earlier this changeset was committed:

http://cvs.mythtv.org/trac/changeset/6606

This lets users use overrecord to catch more of sports events that tend
to drift late. Why is it okay to (ab)use overrecord to catch the end of
sports events, but not shows in other categories?

I certainly agree that using overrecord in this way is not perfect, and
a new global soft buffer could provide some additional minor advantages.
But by blocking the patch, it seems like you're denying users a way to
catch more of the shows they want because you'd prefer them to use a
method that doesn't exist yet.

Max.

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


kirwin at ncsu

Sep 30, 2005, 10:37 PM

Post #25 of 31 (6564 views)
Permalink
Re: Re: Re: Ticket #255: Improved scheduling of consecutive programs with pre-roll/overrecord [In reply to]

On Sep 30, 2005, at 3:22 AM, Rudy Zijlstra wrote:
> Face up to it. Soft scheduling will still result in unexpected
> behaviour. Spend 50bucks to get an extra tuner and spare yourself
> the disappointment.
>
> Regards,
>
> Rudy

It's not that simple for all of us. I have one tuner for ATSC
(primarily high definition) digital programming and another for
analog TV programming off of cable. Both sometimes have back to back
recordings. So I'd need two more tuners. I can't fit two more
tuners into my box. The PCI slots are too tightly spaced to put
tuner cards with large "tin can" tuners on them into adjacent slots.
As such, I would need to buy another computer and two tuners.
Realistically, we're talking about a minimum of $450 (basic computer
= $300, ATSC tuner = $100, NTSC tuner = $50). That's significantly
outside my budget.

As a user, I would just like to say that having a few minutes of soft
time is very useful to me. Shows on several networks I watch are
often literally back to back. For instance, That Seventies Show has
jokes during the credit roll. On FX the next show starts five
seconds later. The network's clock is not synchronized with mine to
that kind of margin of error. In fact, it's rare that it's
synchronized to within 30 seconds. I want to be able to capture the
whole show. But I would rather give up a few seconds of the end of a
show than be unable to record a show due to conflicts. Setting
preroll and postroll to a few minutes does this perfectly. If the
official version of MythTV goes to a 30-second limit on preroll and
postroll, I will start patching my own version to avoid this limit.

With soft time, unexpected behavior can occur, yes, but most of the
time it "does the right thing" without my having to tell it what to
do and that's invaluable. Those of you who don't like soft time, -
don't use it-. Don't tell the rest of us that we should be happy
with hard time. If we wanted hard time, we could set it. What the
argument against better soft time support (options such as using a
second tuner rather than killing the preroll) comes down to is "I
don't like soft time, so you shouldn't either." I'm glad for those
of you who can set your preroll and postrolls to a few seconds and
not have problems, but I'll miss beginnings and endings if I do
that. But excuse me if I don't cry for the fact that I'm abusing a
feature. If a significant portion of users are abusing a feature,
perhaps it's time for the feature to change to accommodate that usage.

Keith Irwin
Attachments: PGP.sig (0.18 KB)

First page Previous page 1 2 Next page Last page  View All MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.