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

R. G. Newbury newbury at mandamus.org
Mon Dec 4 20:21:43 UTC 2006


Steve Hodge wrote:
> 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
Your reply points out some of the difficult choices which would have to 
be made to get this to work. For a pile of reasons, the present 
one-file= one-show choice was and is optimal.

But it does point towards one possible area in which a multiplexed 
stream recording could add functionality to Myth: the circumstance where 
2 or more desired shows are 1) on the same multiplex and 2) at the same 
time (or, one is 'inside' the other's timeframe. Under that 
circumstance, recording the entire multiplex would avoid a tuner 
conflict, by being a special case for the scheduler.
But, as noted  it would require special handling for deletion involving 
a database table change and related adjustments. Those particular 
changes might be avoidable, if, instead, a backend process is used to 
extract the desired multiplexes from the compound stream after recording 
is completed..like mythcomflag or transcoding.
And 'live' watching would not be possible...equivalent to 'all tuners in 
use'...

Geoff


More information about the mythtv-users mailing list