Mailing List Archive: MythTV: Dev

Preserve global padding. [UNSTABLE]

Index | Next | Previous | View Threaded

mythtv at longhome

Apr 7, 2007, 5:18 PM

Post #1 of 11 (1045 views)
Permalink

Preserve global padding. [UNSTABLE]

Hi,

I've created a new patch, and I just thought I'd see if anyone is interested
in it.

* PLEASE NOTE... this is a spike solution, I've hard coded the pre/post roll
values. Some help in doing this properly would be a help - I'll give that
bit a go tomorrow :) *

It is based on the assumption that all tuners in the system are equal -
that's how it works in my system, so that's the only way it's been tested.
If you want to test it on a different configuration please do so at your own
risk.

If you have global pre and post roll set, then it will add this to all
recordings, except where a recording immediately follows or precedes it, in
which case, the relevant pre/post roll is removed. This happens regardless
of the channel the recording is on, and whether this is a spare tuner-card
sat doing nothing.

The way it works with this patch, is first it tries to allocate a tuner,
based on preserving the pre and post roll, if it cannot, then it strips it
off and tries again. All this means is that if a tuner is sat idle, doing
nothing, then it will get used. If it's needed for a show which is
subsequently scheduled, then the utilisation is actually the same, and
padding will be stripped as needed.

I don't expect any of this stuff to be committed - I don't think it fits
with everyone's view of the world, but I know of a lot of people who would
find it very useful (eg pretty much anyone in the UK with 2+ identical DVB
cards). If anyone is actually interested in working on this with me then
input would be very useful.

I don't intend to put any fancy logic into this, so don't ask. The idea is
that it will just be an improvement on the current policy of all padding
being stripped on adjacent shows. I won't be putting in any rules to
prioritise padding over low priority shows (that doesn't happen now), and it
starts to become a very complicated system. You can simply force padding on
a particular recording by using the recording specific pre/post roll
settings.

For critics info - only the global pre/post options work for me, because I
would rather drop padding than drop a recording if it came to the crunch -
but the patch is required because I only want to drop padding if really
necessary. I realise this may not be Isaacs intended use for these options,
but it provides me exactly what I need. In fact, this is how the padding
policy for most UK PVRs (and I've had a few) seems to work, including Sky+.

Discuss...

Thanks

Martin

Attachments:

preservepadding.patch (2.81 KB)

mythtv at longhome

Apr 8, 2007, 4:05 AM

Post #2 of 11 (994 views)
Permalink

Re: Preserve global padding. [UNSTABLE] [In reply to]

Hello,

I've properly slotted in the parameters "RecordPreRoll" and "RecordOverTime"
to the patch, and it seems to work as expected.

Again... comments welcome.

Martin

-----Original Message-----
From: mythtv-dev-bounces [at] mythtv [mailto:mythtv-dev-bounces [at] mythtv]
On Behalf Of Martin Long
Sent: 08 April 2007 01:19
To: 'Development of mythtv'
Subject: [mythtv] Preserve global padding. [UNSTABLE]

Hi,

I've created a new patch, and I just thought I'd see if anyone is interested
in it.

* PLEASE NOTE... this is a spike solution, I've hard coded the pre/post roll
values. Some help in doing this properly would be a help - I'll give that
bit a go tomorrow :) *

It is based on the assumption that all tuners in the system are equal -
that's how it works in my system, so that's the only way it's been tested.
If you want to test it on a different configuration please do so at your own
risk.

If you have global pre and post roll set, then it will add this to all
recordings, except where a recording immediately follows or precedes it, in
which case, the relevant pre/post roll is removed. This happens regardless
of the channel the recording is on, and whether this is a spare tuner-card
sat doing nothing.

The way it works with this patch, is first it tries to allocate a tuner,
based on preserving the pre and post roll, if it cannot, then it strips it
off and tries again. All this means is that if a tuner is sat idle, doing
nothing, then it will get used. If it's needed for a show which is
subsequently scheduled, then the utilisation is actually the same, and
padding will be stripped as needed.

I don't expect any of this stuff to be committed - I don't think it fits
with everyone's view of the world, but I know of a lot of people who would
find it very useful (eg pretty much anyone in the UK with 2+ identical DVB
cards). If anyone is actually interested in working on this with me then
input would be very useful.

I don't intend to put any fancy logic into this, so don't ask. The idea is
that it will just be an improvement on the current policy of all padding
being stripped on adjacent shows. I won't be putting in any rules to
prioritise padding over low priority shows (that doesn't happen now), and it
starts to become a very complicated system. You can simply force padding on
a particular recording by using the recording specific pre/post roll
settings.

For critics info - only the global pre/post options work for me, because I
would rather drop padding than drop a recording if it came to the crunch -
but the patch is required because I only want to drop padding if really
necessary. I realise this may not be Isaacs intended use for these options,
but it provides me exactly what I need. In fact, this is how the padding
policy for most UK PVRs (and I've had a few) seems to work, including Sky+.

Discuss...

Thanks

Martin

Attachments:

preservepadding.patch (2.98 KB)

mythtv at longhome

Apr 8, 2007, 4:38 AM

Post #3 of 11 (996 views)
Permalink

Re: Preserve global padding. [UNSTABLE] [In reply to]

Right... doesn't quite work. Mind got a bit scrambled last night. Needs a
re-think.

-----Original Message-----
From: mythtv-dev-bounces [at] mythtv [mailto:mythtv-dev-bounces [at] mythtv]
On Behalf Of Martin Long
Sent: 08 April 2007 12:06
To: 'Development of mythtv'
Subject: Re: [mythtv] Preserve global padding. [UNSTABLE]

Hello,

I've properly slotted in the parameters "RecordPreRoll" and "RecordOverTime"
to the patch, and it seems to work as expected.

Again... comments welcome.

Martin

-----Original Message-----
From: mythtv-dev-bounces [at] mythtv [mailto:mythtv-dev-bounces [at] mythtv]
On Behalf Of Martin Long
Sent: 08 April 2007 01:19
To: 'Development of mythtv'
Subject: [mythtv] Preserve global padding. [UNSTABLE]

Hi,

I've created a new patch, and I just thought I'd see if anyone is interested
in it.

* PLEASE NOTE... this is a spike solution, I've hard coded the pre/post roll
values. Some help in doing this properly would be a help - I'll give that
bit a go tomorrow :) *

It is based on the assumption that all tuners in the system are equal -
that's how it works in my system, so that's the only way it's been tested.
If you want to test it on a different configuration please do so at your own
risk.

If you have global pre and post roll set, then it will add this to all
recordings, except where a recording immediately follows or precedes it, in
which case, the relevant pre/post roll is removed. This happens regardless
of the channel the recording is on, and whether this is a spare tuner-card
sat doing nothing.

The way it works with this patch, is first it tries to allocate a tuner,
based on preserving the pre and post roll, if it cannot, then it strips it
off and tries again. All this means is that if a tuner is sat idle, doing
nothing, then it will get used. If it's needed for a show which is
subsequently scheduled, then the utilisation is actually the same, and
padding will be stripped as needed.

I don't expect any of this stuff to be committed - I don't think it fits
with everyone's view of the world, but I know of a lot of people who would
find it very useful (eg pretty much anyone in the UK with 2+ identical DVB
cards). If anyone is actually interested in working on this with me then
input would be very useful.

I don't intend to put any fancy logic into this, so don't ask. The idea is
that it will just be an improvement on the current policy of all padding
being stripped on adjacent shows. I won't be putting in any rules to
prioritise padding over low priority shows (that doesn't happen now), and it
starts to become a very complicated system. You can simply force padding on
a particular recording by using the recording specific pre/post roll
settings.

For critics info - only the global pre/post options work for me, because I
would rather drop padding than drop a recording if it came to the crunch -
but the patch is required because I only want to drop padding if really
necessary. I realise this may not be Isaacs intended use for these options,
but it provides me exactly what I need. In fact, this is how the padding
policy for most UK PVRs (and I've had a few) seems to work, including Sky+.

Discuss...

Thanks

Martin

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

mythtv at longhome

Apr 8, 2007, 2:09 PM

Post #4 of 11 (989 views)
Permalink

Re: Preserve global padding. [UNSTABLE] [In reply to]

Ok... the wife's a bit annoyed, but I did it. It's just a case of running 2
passes of a part of the scheduler. The first time padding will clash,
ensuring a new cardinput will be used, however, it may be unable to schedule
some recordings. The second pass will loop through anything that is still
rsUnknown, this time ignoring padding, and allowing those remaining programs
to be scheduled.

It seems to work well, and it all comes out ok when you add new or remove
existing schedules.

I need to take some time and get a better understanding of
TryAnotherShowing, MoveHigherRecords and getConflicting to make sure I've
got the logic right for all the various scenarios, so some help here would
be greatly appreciated.

Hope someone finds this useful.

Martin

Attachments:

preservepadding.patch (4.06 KB)

jppoet at gmail

Apr 8, 2007, 2:30 PM

Post #5 of 11 (992 views)
Permalink

Re: Preserve global padding. [UNSTABLE] [In reply to]

On 4/8/07, Martin Long <mythtv [at] longhome> wrote:
>
> Ok... the wife's a bit annoyed, but I did it. It's just a case of running
> 2
> passes of a part of the scheduler. The first time padding will clash,
> ensuring a new cardinput will be used, however, it may be unable to
> schedule
> some recordings. The second pass will loop through anything that is still
> rsUnknown, this time ignoring padding, and allowing those remaining
> programs
> to be scheduled.
>
> It seems to work well, and it all comes out ok when you add new or remove
> existing schedules.
>
> I need to take some time and get a better understanding of
> TryAnotherShowing, MoveHigherRecords and getConflicting to make sure I've
> got the logic right for all the various scenarios, so some help here would
> be greatly appreciated.
>
> Hope someone finds this useful.
>
> Martin

This is interesting. I may have to try it sometime, but it may be a while
before I have the time.

Thanks,

John

mythtv at longhome

Apr 8, 2007, 4:37 PM

Post #6 of 11 (982 views)
Permalink

Re: Preserve global padding. [UNSTABLE] [In reply to]

Finally... worked out all of the MoveHigherRecords stuff, putting in
multiple passes where necessary. The logic looks ok, but I use these
functions very rarely - 4 tuners means TryAnotherShowing hardly ever gets
used on my box.

This should be my last build for a while, with any luck. Sorry for the
noise!

Martin

-----Original Message-----
From: mythtv-dev-bounces [at] mythtv [mailto:mythtv-dev-bounces [at] mythtv]
On Behalf Of Martin Long
Sent: 08 April 2007 22:09
To: 'Development of mythtv'
Subject: Re: [mythtv] Preserve global padding. [UNSTABLE]

Ok... the wife's a bit annoyed, but I did it. It's just a case of running 2
passes of a part of the scheduler. The first time padding will clash,
ensuring a new cardinput will be used, however, it may be unable to schedule
some recordings. The second pass will loop through anything that is still
rsUnknown, this time ignoring padding, and allowing those remaining programs
to be scheduled.

It seems to work well, and it all comes out ok when you add new or remove
existing schedules.

I need to take some time and get a better understanding of
TryAnotherShowing, MoveHigherRecords and getConflicting to make sure I've
got the logic right for all the various scenarios, so some help here would
be greatly appreciated.

Hope someone finds this useful.

Martin

Attachments:

preservepadding.patch (8.23 KB)

mythtv at longhome

Apr 10, 2007, 6:42 AM

Post #7 of 11 (956 views)
Permalink

Re: Preserve global padding. [UNSTABLE] [In reply to]

I relise this has been done to death in the softpad discussion, but this
has already proved to be incredibly useful for me, and I'd like to give it
a chance for the others that are screaming out for it.

I've had some positive feedback from some friends that have tried this.
I would, however, like to make it as generic as possible in the hope that
it could be committed. As I see it there are two possible routes to take
this.

1. The current method, by somewhat 'hardening' the global pre and post
roll enough to make it allocate a different tuner, but not enough create a
conflict where there aren't enough tuners to service it. I could enhance
this solution by:
- Providing an option to switch this behaviour on / off.
- Allow higher priority programs to maintain padding, setting lower
priorities as conflicts.

2. Use the per-recording padding instead. I would propose the following:

- A global default setting - I don't believe this exists at the moment,
and I, for example, would want to set 5 mins either side on ALL
recordings. I suppose that even a channel default could be viable, but
not vital.

- A per recording (and global default) hard / soft setting. This would
allow certain recordings to enforce padding, whereas for others it would
be soft.

- Again, as in solution 1, priority could be used in combination with the
softpadded (but not hardpadded) recordings, to ensure that padding
doesn't get dropped for really important stuff.

I _think_ my solution already takes in to account tuner priority**, and
would rather drop padding than allocate to a lower priority tuner - in the
same way that a later showing would be used instead of a lower tuner
priority, so as far as I know my current solution doesn't have any
negative impact, and in theory could be committed as is. I think the only
issue is one of intended use of the pre and post roll functions.

The only reasons I would like to see this committed are that I genuinely
feel that a large number of people would benefit from this, and I would
rather not have to maintain a seperate SVN tree for these changes.

I can potentially also see how I can extend these changes to support show
start triggers (ie PDC, or the new EIT triggers for freeview playback in
the UK)

I would appreciate any more comments before I start on the work.

Thanks

Martin

**I just checked... it does, but not quite in the ideal way. I can change it.

Currently:
- It will try other showings before using a lower priority tuner...
- however, if it can't manage another showing _with_ padding, then it'll
try other tuners before trying other showings _without_ padding.

I think this probably should be:
- It will try other showings before using a lower priority tuner...
- and, it will try them again, without padding, before trying another tuner.

Let me know what you think... the second needs a rearangement of the
logic, which is slightly more complicated, but it is probably preferable -
I don't know really, all my tuners have the same priority.

On Mon, April 9, 2007 12:37 am, Martin Long wrote:
>

> Finally... worked out all of the MoveHigherRecords stuff, putting in
> multiple passes where necessary. The logic looks ok, but I use these
> functions very rarely - 4 tuners means TryAnotherShowing hardly ever gets
> used on my box.
>
> This should be my last build for a while, with any luck. Sorry for the
> noise!
>
> Martin
>
>
> -----Original Message-----
> From: mythtv-dev-bounces [at] mythtv [mailto:mythtv-dev-bounces [at] mythtv]
> On Behalf Of Martin Long
> Sent: 08 April 2007 22:09
> To: 'Development of mythtv'
> Subject: Re: [mythtv] Preserve global padding. [UNSTABLE]
>
>
> Ok... the wife's a bit annoyed, but I did it. It's just a case of running
> 2
> passes of a part of the scheduler. The first time padding will clash,
> ensuring a new cardinput will be used, however, it may be unable to
> schedule some recordings. The second pass will loop through anything that
> is still rsUnknown, this time ignoring padding, and allowing those
> remaining programs to be scheduled.
>
> It seems to work well, and it all comes out ok when you add new or remove
> existing schedules.
>
> I need to take some time and get a better understanding of
> TryAnotherShowing, MoveHigherRecords and getConflicting to make sure I've
> got the logic right for all the various scenarios, so some help here would
> be greatly appreciated.
>
> Hope someone finds this useful.
>
>
> Martin
> _______________________________________________
> 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

mtdean at thirdcontact

Apr 10, 2007, 7:00 AM

Post #8 of 11 (956 views)
Permalink

Re: Preserve global padding. [UNSTABLE] [In reply to]

On 04/10/2007 09:42 AM, Martin Long wrote:
> in the
> same way that a later showing would be used instead of a lower tuner
> priority,

Not that I can provide any input on whether this will be considered for
inclusion, but the above should /only/ reschedule the lower priority
program for later--the higher priority show must be recorded on its
first showing--unless the user explicitly sets:

Reschedule Higher Priorities
Move higher priority programs to other cards and showings when resolving
conflicts. This can be used to record lower priority programs that
would otherwise not be recorded, but risks missing a higher priority
program if the schedule changes.

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

mythtv at longhome

Apr 10, 2007, 7:27 AM

Post #9 of 11 (958 views)
Permalink

Re: Preserve global padding. [UNSTABLE] [In reply to]

Yes, it will /only/ reschedule the lower priorty. I have made sure of that.

Out of interest, do you know what the purpose of the SchedOpenEnd option is?

On Tue, April 10, 2007 3:00 pm, Michael T. Dean wrote:
> On 04/10/2007 09:42 AM, Martin Long wrote:
>
>> in the same way that a later showing would be used instead of a lower
>> tuner priority,
>
> Not that I can provide any input on whether this will be considered for
> inclusion, but the above should /only/ reschedule the lower priority
> program for later--the higher priority show must be recorded on its first
> showing--unless the user explicitly sets:
>
> Reschedule Higher Priorities
> Move higher priority programs to other cards and showings when resolving
> conflicts. This can be used to record lower priority programs that would
> otherwise not be recorded, but risks missing a higher priority program if
> the schedule changes.
>
> Mike
> _______________________________________________
> 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

mtdean at thirdcontact

Apr 10, 2007, 11:47 AM

Post #10 of 11 (960 views)
Permalink

Re: Preserve global padding. [UNSTABLE] [In reply to]

On 04/10/2007 10:27 AM, Martin Long wrote:
> Yes, it will /only/ reschedule the lower priorty. I have made sure of that.
>
> Out of interest, do you know what the purpose of the SchedOpenEnd option is?

Avoid back to back recordings from different channels
If set, the scheduler will avoid assigning shows from different channels
to the same card if their end time and start time match. This will be
allowed when necessary in order to resolve conflicts.

http://svn.mythtv.org/trac/changeset/13007

I'm guessing Bruce put it in to allow people a better chance of getting
global padding on their episodes (since same channel back-to-back, you'd
have the content in one or the other recording), but you'll have to ask him.

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

mythtv at longhome

Apr 10, 2007, 12:23 PM

Post #11 of 11 (956 views)
Permalink

Re: Preserve global padding. [UNSTABLE] [In reply to]

A ha! Simpler version of what I'm trying to acheive. Cunning.

So this method seems to disallow b2b in the normal pass, but then allows
them in MoveHigherRecords and TryAnotherShowing.

Maybe I should just abandon what I'm doing and perhaps work on
developing that idea.

Thanks for the advice Mike.

On Tue, 2007-04-10 at 14:47 -0400, Michael T. Dean wrote:
> On 04/10/2007 10:27 AM, Martin Long wrote:
> > Yes, it will /only/ reschedule the lower priorty. I have made sure of that.
> >
> > Out of interest, do you know what the purpose of the SchedOpenEnd option is?
>
> Avoid back to back recordings from different channels
> If set, the scheduler will avoid assigning shows from different channels
> to the same card if their end time and start time match. This will be
> allowed when necessary in order to resolve conflicts.
>
> http://svn.mythtv.org/trac/changeset/13007
>
> I'm guessing Bruce put it in to allow people a better chance of getting
> global padding on their episodes (since same channel back-to-back, you'd
> have the content in one or the other recording), but you'll have to ask him.
>
> Mike
> _______________________________________________
> 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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads