[mythtv-users] Multiplexing in AU (was Re: Help sponsor MythTVMultiplex.)

f-myth-users at media.mit.edu f-myth-users at media.mit.edu
Fri Apr 13 02:17:24 UTC 2007


    Date: Thu, 5 Apr 2007 19:49:48 +0200
    From: Janne Grunau <janne-mythtvusers at grunau.be>

    We will start with the DVB recorder and extend it later to other 
    recorders. But the other recorders aren't strictly part of the job. 

    [ . . . ]

    ivtv might be trickier.

I spent a while last week staring at the patches to scheduler.cpp in
the trac ticket for this patch.  I was surprised at how noninvasive
they were; I was naively assuming it would be a much bigger deal.

As I understand it, the major issues with ivtv to multiple files are:
o  Actually making the stream recoder write to more than one file at a time.
o  Making the scheduler aware of that this is going on.

mpegrecorder (et al) look easy enough to rig for simultaneous writing
(every time you write to a FD, instead iterate over a list of FD's---
though there are the usual issues of maintaining this list in a
race-free way and fixing their callers, etc etc).

I'm guessing that the scheduler implications are much more severe.
Once we have some experience with the DVB-multiplex patch, it might be
worthwhile revisiting the ivtv (etc) case, but I'm afraid that it will
be blown up into insoluability unless we're careful.  If I recall
correctly, the typical problem when this has been discussed (in the
past few months, anyway) is priorities---"how can you do this while
respecting all of the ways the user might specify program/source/
tuner/whatever priorities?  It gets exponentially hard!".

But I'm not sure this is true.  After all, once we've settled on using
a particular tuner to record a particular channel, it seems to me that
that choice is -just- as good for the -next- thing on that channel.
So it -seems- to me that it ought to be possible to do this:  (*)
   
   If program P is scheduled on some tuner T for some source S (S is a
   combination of channel & input on the card), then any program P'
   whose start/end times overlap P should be scheduled on T.

This seems like it'll have the effect of glomming such programs
together preferentially (e.g., overlapping same-S's will -always-
share the same tuner) but I fear it might require multiple scheduler
passes (perhaps scaling as the number of overlaps?) instead of the
current two? that run.  Is that the problem with this approach?

(I'm not saying this should be pursued as part of the multiplex patch,
since it is explicitly out of that patch's scope.  But I'm hoping that
having the multiplex patch can be a starting point to overlapped ivtv
recordings -even if it has to not take every possible case into account-
since I fear that doing so has completely blocked every attempt at
thinking about this problem, e.g,. don't let the perfect chase away
the merely adequate.  But I'm sure I don't understand this nearly as
well as I should.)

(*) Okay, here's a potential problem:  Say T1 has an RF input and a
composite input; the composite input is connected to an STB.  T2 just
has RF.  There's a marathon on some RF channel.  The scheduler picks P
for T1's RF1.  Next, it picks every additional episode of the marathon
to (naturally) be on RF1 as well.  Halfway through the marathon is a
recording that needs T1's C1.  We'd -want- the marathon to have been
entirely recorded on RF2 (since T2 has no C2), but we'd have to back
out of a large number of recordings on RF1 and reassign them to RF2 in
order to free C1 for the recording.  Can the scheduler already do this?

[My understanding is that the two? passes currently made by the
scheduler are considered "the limit" and that adding additional
passes is unlikely to be accepted.  I know that this problem is
in general solvable via recursive backtracking or (in the most
general form) via a truth-maintenance system, but I believe that
a fullblown TMS has been ruled too complicated.  What I don't know
is whether my scenario above is too complicated for the current
scheduler, because I don't -understand- all of the current scheduler.]


More information about the mythtv-users mailing list