[mythtv] Preserve global padding. [UNSTABLE]

Martin Long mythtv at longhome.co.uk
Tue Apr 10 13:42:18 UTC 2007

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

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.



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

 - 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.org [mailto:mythtv-dev-bounces at mythtv.org]
>  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.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

More information about the mythtv-dev mailing list