[mythtv-users] Multiple channels single tuner: a kludgey solution?

Steve Hodge stevehodge at gmail.com
Sun Dec 3 23:12:49 UTC 2006


On 12/4/06, R. G. Newbury <newbury at mandamus.org> wrote:
>
> Rev Simon Rumble wrote:
> > The using multiple channels is the easy part, but the problem with
> > integration is that the scheduler considers each tuner as capable of
> > only recording a single stream.  This solution makes every channel on
> > these muxes appear to be a separate "tuner".
> >
> To accept "multiple channels" is easy: the tuner already does that. It
> goes further by extracting the particular multiplex from the stream.
> To make multi-channels work, we would have to have the software and
> quite possibly the hardware too, ignore the 'extraction' process so as
> to deliver the entire un-de-muxed stream to the frontend
> software/hardware combo.


This is pretty common functionality, even for those cards that have a
hardware pid filter. Getting all the streams is not a problem and is
implemented in (e.g.) dvbstream (using the "magic" pid 8192).


> I still think the easiest route will (on a structural bassis)be to
> record the entire stream and extract the desired multiplex on playback,
> but as noted, that may require changes at the hardware level... or some
> register bashing. I would be surprised if it is not already possible to
> tell the hardware to pass 'all' streams' as distinct to telling it to
> extract stream #X. (But the software is designed to tell it to extract a
> stream, and then passes that stream to the decoder).


You are essentially talking about spliting the concept of a "recording" into
two separate entities - a "file" which is really a block of time scheduled
on a particular recording device, and a "show" which is a block of time
within a "file". That's quite a major change. There are wider issues than
just not deleting the file until all recordings in it have been deleted, e.g.
the auto-expiration code would need to be changed because deleting some
recordings would no longer reclaim space. Also, if you have multiple
recordings in a file with different start times or lengths you have the
non-optimal situation where deleting a recording should reclaim space (the
non-overlapping part of the recording in the file), but won't.

Recordings are (and should continue to be) scheduled on a show by show
basis, so either the scheduler or the recorder would need to be able to
combine multiple shows into one file.

Multiple recordings in one file has been discussed before in relation to
better handling of sequential recordings on the same channel - search the
archives for more info.

I do not see the scheduler as a problem at all. The system 'knows' which
> programs are on at any time and 'knows' which multiplexes are related by
> reason of similar tuning characteristics except for the serviceid
> (stream id). So recordings at the same time are not conflicted in that
> case, as both/all will be recorded as part of the stream.


I see the scheduler as a significant problem. It's not as simple as changing
a test to say "two programs don't conflict if they are on the same
multiplex". I don't know the code, but I wouldn't expect the scheduler to
know what multiplexes stuff is on (that's a detail only the recorders need
to know about at the moment). There are complexities added by the
possibility of channels on multiple recorders, e.g. channel A may be on
multiplex 1, but also available on another recorder. Priorities can also add
tricky corner cases. Again, search the archives, this has been discussed
extensively before.

Anyway, don't get the idea that I'm against getting this implemented because
I'm not. I'd love to see someone tackle it. But it's not as easy as you make
out.

Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20061204/1d6aba07/attachment.htm 


More information about the mythtv-users mailing list