[mythtv] [mythtv-commits] Ticket #1772: Allow Multiple Channels rom 1 Transponder...

[Bruce Markey]

Martin Long wrote:
...
> Bruce Markey:
> 
>> This issue has come up time and time again and each time
>> people come to this wrong conclusion. The scheduler already
>> knows how to assign shows to multiple inputs on multiple
>> cards with multiple video sources in any combination and
>> deal with overlaps, choosing the preferred input, "L"atering
>> shows to make them fit, etc.
> 
> Yes, I'm aware that the scheduler is capable of doing this. What it is
> not capable of is being aware of shows which are on the same mux, and
> can be assigned to the same tuner. 

Right, and that is the problem in need of a solution. There
needs to be a mechanism to describe what can and can't record
simultaneously. Once that is described, filling the reclist
is status quo. My point is that ~80% of the code needed would
go into mythtv-setup for the UI to configure what is and isn't
allowed, ~15% in managing this new info in capturecard, cardinput
etc. and ~5% in the scheduler to replace the assumption that the
cardid is the factor that determines what inputs are and aren't
mutually exclusive.

>> But there is no way to configure this. That is the missing
>> piece. There would need to be a mechanism to tell the system
>> that the same device can be used as two independent inputs
>> that are not mutually exclusive. The other side of the coin
>> is that there in no way to tell the system that two inputs
>> on different cards share a resource and need to be mutually
>> exclusive.
> 
> This is exactly what I'm talking about, but the scheduler also needs
> work to understand how to use this additional information. It could be

Somehow, this doesn't quite parse for me. "This additional
information" doesn't exist. What I'm telling you is that the
task is putting "this additional information" into the system's
card and input configuration. Once there, substituting the
premise of 'one cardid, one encoder' is trivial and issues of
how to manage assigning conflicting and non-conflicting inputs
have long since been resolved.

> possible to assign up to 32 'virtual' inputs to a single tuner card for
> example (Multiplex 2 in the UK has 30 channels!). This would mean that
> you could record 32 programs at the same time, only using up a single
> tuner.

Incorrect =). Let's nip this at the bud. You cannot "record 32
programs at the same time". Two, maybe three but at some point
the card/driver/bus/disk cache/virtual memory/(most certainly)
disk head seeking, becomes Lucy in the chocolate factory. You
cannot record an unlimited number of streams without all the
streams becoming damaged and unwatchable.

The premise must be that the user can configure a finite number
of virtual inputs to the device. For example, let's say there
is only one DVB card in a standalone system that would become
horribly I/O bound if it tried to store 4 streams at a time. The
users should be able to create three virtual inputs associated with
that card. If there is one show at 8:00 on Mux 2, it is assigned
to input 1. Another at 8:00 on Mux 2 gets input 2. Maybe a third
but the fourth show is SOL as all four shows would be damaged.

Now, let's say the highest priority show is at 8:00 on Mux 1 and
the next highest is on Mux 2. These could not record at the same
time even though they are from the same 'video source', right?
So, the mux could be thought of as a subset of a video source.
DVBProvider+Mux1 and DVBProvider+Mux2 are in conflict. A solution
would be to add a map (yes, this part would be now code in the
scheduler.cpp file =) to list what muxes are in use at what times.
This would be filled in as the schedule is filled.

If no mux is in use (DVBProvider+Mux0, null, -1, whatever) then
any channel for the video source "DVBProvider" is available for
a show to be placed on an input. If input 1 is using Mux 1 at 8:00
in this example, inputs 2 and 3 are only available for lower
priority shows on channels that are in the subset DVBProvider+Mux1.
Our second show on Mux 2 would initially be a conflict if it has
no later showings, however, if SchedMoveHigher finds that the
first show could be recorded at a later time, then it could be
moved and both shows can be recorded.

The only thing new would be the list of cardid/mux start and end
times and checking this list before assigning another show to a
virtual input of the card.

> The rules for the scheduler are already quite complex, and this would
> certainly add complexity to that. For example, on a SINGLE tuner system:
> 
> Two priority 0 programs are scheduled for 8am - 9pm on Mux 1, a new
> program is added on Mux2 priority 1, should this trump BOTH of the
> programs on Mux1? The answer may or may not be obvious, but the question
> has to be asked, and the tuner doesn't currently know what to do in this
> situation.

If I had one analog tuner and a high priority baseball game from
7:00-10:30 and there where other lower priority shows at 8:00,
9:00 and local news at 10:00 the scheduler would mark the ball
game as rsWillReocrd and the other three as rsConflict. The
scheduler will not mark a higher priority show as a conflict in
order to favor lower priority shows. Period. That's the point
of having priorities. The system may be allowed to record a later 
showing of a higher priority show in order to resolve conflicts
with lower priority shows.

If you decide that you were wrong and would prefer to record one
or both of the other shows and forego the show on Mux 2, then you
would want to change the rule priorities to reflect your real
preference or add an override to reflect what you, the human in
the equation, would prefer in this case.

This is a perfect example of why I'm trying to dissuade you from
this kind of thinking. The answer is obvious and the issue was
resolved years ago. And BTW, the tuner doesn't "know" anything.
The system needs to tell the scheduler what the inputs can and
can't do and that is the problem you need to address. Wrong
tree, you're barking it up ;-).

> Here's one which would create an interesting situation, 2 tuner inputs:
> 
> Already set to record:
> 
>    1. Mux 1 (BBC 1) 7:00 - 8:00   - allocated to Tuner 1
>    2. Mux 2 (ITV 1) 8:10 - 9:10   - allocated to Tuner 1
> 
> I want to add in the following program:
> 
>    3. Mux 1 (BBC 2) 7:30 - 9:30

> This would sit fine with recording 1 on BBC 1, but because it would
> clash with recording 2 on ITV 1, the scheduler would probably allocate
> it to Tuner 2. This would mean 2 tuners are tied up for a longer period,
> leaving less resources for other new recordings or live TV. 

"Probably"? There is nothing random in filling the reclist. It
must be deterministic so that there will be the same result each
time the scheduler is run. If the ITV 1 show was higher priority
than the BBC 2 show, the ITV show would be placed on the first
(lowest numbered) available input.

There is no conflict here other than the suggestion that there
may be "other new recordings". I'm not sure if it's better to
have two recordings from one card or one recording each for two.
I think an opinion of what is ideal here is debatable but is
really inconsequential. Now if there was another request for
7:00-7:30 on Mux 3, depending on the priorities it would either
get paired with ITV in the first place or SchedMoveHigher would
find that 1. and 3. fit on the same tuner and 2. and 4. on the
other.

> I may of course be wrong, and this can already be done, but looking at
> the code, it does only seem to handle allocating recordings to distinct
> tuner inputs. 

And... right back to square one ;-). The system needs to be able
to describe what distinct tuner inputs are available and which
can and can not be used simultaneously. The tacit assumption seems
to be that this should be left unknown and somewhere deep in the
scheduler logic, this should be figured out after the fact.

By analogy, say we are going to make a doghouse and paint it blue.
You are worrying about re-inventing blue paint and what if it runs
or blisters. The paint works. You need to build the doghouse =).

--  bjm