[mythtv] Recording multiple channels on a single DVB transport

Stuart Morgan stuart at tase.co.uk
Wed Dec 21 16:04:18 EST 2005

On Wednesday 21 Dec 2005 11:50, Richard Watts wrote:
>   FWIW, when I was doing something similar a while back, the most efficient
> approach I found was to run a greedy knapsack algorithm on all potentially
> overlapping programmes, with costs set by recording priority, and some
> hysterisis at either end to account for tuning delay, overruns, schedule
> mismatch, and so forth.

I'm not sure that the solution need be so complex. I've not looked at current 
scheduling code but I doubt it is this evolved! I've already the skeleton of 
a plan which is much more straightforward and is consistent with current 
scheduling behaviour.

At the very least costing or weighting such things as priority would not sit 
well with me - if I assign a priority I consider it an absolute. I want a 
higher priority schedule recorded regardless of how many lower priority 
recordings are missed! In this scenario a simple sorting by priority is 

If someone wants a more intelligent scheduler then they can write it. All I'm 
interested in doing is enabling concurrent recordings on a single tuner. :)

>   The trouble with that approach is that it leads to very confusing error
> messages:
>   `I am unable to show you this programme for complex reasons to do with
>    a recording that is about to start, one which should have finished,
>    and one I think might finish late or start early. But I can show you
>    many other programmes .. '

The scheduler as currently implemented is self explanatory, I would prefer it 
stayed that way. If you ever reach the situation where your program has to 
explain it's actions to the end-user then you as the programmer have failed.

>   And obviously you have problems reloading EIT data because you don't
> necessarily have a tuner left to tune to the relevant multiplex with
> (this is particularly annoying when it means you miss schedule changes
> because of a background recording or have incomplete programme info
> because the user simply hasn't let you tune to that multiplex recently).

I don't see this as an issue, in fact I'm not even sure what you are talking 
about? What is being proposed wouldn't change the current situation with 
regards to EIT data at all. Well that isn't exactly true - in multi-tuner 
machines it would result in a free tuner more often than, not the reverse.

>   In MythTV, of course, you also have the amusing problem that every
> tuner has slightly different capabilities (even if you can get the
> entire TS stream from a DVB card and filter it yourself, you probably
> shouldn't, and some USB cards don't give you access anyway), which
> will make the implementation decidedly tricky (and unstable).

Well like most things in Myth it would almost certainly be something that the 
end user can turn on/off - maybe even on a card by card basis.
Stuart Morgan

More information about the mythtv-dev mailing list