On 12/4/06, <b class="gmail_sendername">R. G. Newbury</b> <<a href="mailto:newbury@mandamus.org">newbury@mandamus.org</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Rev Simon Rumble wrote:<br>> The using multiple channels is the easy part, but the problem with<br>> integration is that the scheduler considers each tuner as capable of<br>> only recording a single stream. This solution makes every channel on
<br>> these muxes appear to be a separate "tuner".<br>><br>To accept "multiple channels" is easy: the tuner already does that. It<br>goes further by extracting the particular multiplex from the stream.
<br>To make multi-channels work, we would have to have the software and<br>quite possibly the hardware too, ignore the 'extraction' process so as<br>to deliver the entire un-de-muxed stream to the frontend<br>software/hardware combo.
</blockquote><div><br>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).
<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I still think the easiest route will (on a structural bassis)be to<br>record the entire stream and extract the desired multiplex on playback,
<br>but as noted, that may require changes at the hardware level... or some<br>register bashing. I would be surprised if it is not already possible to<br>tell the hardware to pass 'all' streams' as distinct to telling it to
<br>extract stream #X. (But the software is designed to tell it to extract a<br>stream, and then passes that stream to the decoder).</blockquote><div><br>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.
<br><br>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. <br><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I do not see the scheduler as a problem at all. The system 'knows' which<br>programs are on at any time and 'knows' which multiplexes are related by
<br>reason of similar tuning characteristics except for the serviceid<br>(stream id). So recordings at the same time are not conflicted in that<br>case, as both/all will be recorded as part of the stream.</blockquote></div>
<br>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.<br><br>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.
<br><br>Steve<br><br><br>