On Fri, Feb 26, 2010 at 12:01 AM, Chris Adams <span dir="ltr">&lt;<a href="mailto:rocket@extremelan.net">rocket@extremelan.net</a>&gt;</span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">&gt;&gt; I think a lot of the conceptual difficulty that some of us have is this:<br>
&gt;&gt; all preselected recordings represent *scheduled* events, whereas by it&#39;s<br>
&gt;&gt; nature, LiveTV is an *unscheduled* event. I would even go so far as to say<br>
&gt;&gt; unschedule-able.<br>
&gt;&gt;<br>
&gt;&gt; However, your point above, may be solved in a straightforward (note: does<br>
&gt;&gt; not say simple) way, that is, whenever a channel change is made in LiveTV<br>
&gt;&gt; why not force a reschedule? That would enable the scheduler to take notice<br>
&gt;&gt; of the fact that resource availability has changed, and allocate resources<br>
&gt;&gt; required for forthcoming recordings according to latest availability.<br>
&gt;&gt;<br>
&gt;&gt; I note this would /not/ be optimal for your average channel-surfer,<br>
&gt;&gt; because you&#39;d trigger a reschedule every few seconds. Perhaps a timer which<br>
&gt;&gt; delays a reschedule for perhaps 1 minute would suffice to ensure that the<br>
&gt;&gt; user was actually watching the channel. i.e.<br>
&gt;&gt;<br>
&gt;&gt; LiveTV channel change --&gt; start 1 minute timer<br>
&gt;&gt; Timer completes --&gt; Force reschedule<br>
&gt;&gt;<br>
&gt;&gt; --<br>
&gt;&gt;<br>
&gt;&gt; Mike Perkins<br>
&gt;<br>
&gt; Well my concern with the approach you suggest above is that even with the<br>
&gt; &#39;delay&#39; you might end up with some kind of &#39;race condition&#39; fairly easily.<br>
&gt; But I do agree something needs to be done to keep the LiveTV &amp; scheduler out<br>
&gt; of each others &#39;hair&#39;.<br>
&gt; Andrew<br>
<br>
</div>LiveTV could be set up to take up any &quot;gaps&quot; the scheduler leaves -<br>
but never interfere with its operation.<br>
In this pie-in-the-sky scenario:<br>
<br>
- LiveTV always chooses &quot;the optimal tuner&quot;: this is whichever tuner<br>
will allow the desired channel to remain tuned longest.<br>
- Each time the LiveTV user changes channel a new &quot;optimal tuner&quot; is chosen.<br>
- LiveTV doesn&#39;t use the virtual tuners - they are only for the<br>
scheduler. LiveTV would use something else such as a dynamically<br>
created virtual tuner.<br>
- If you&#39;re watching LiveTV and the scheduler wants your tuner, LiveTV<br>
code searches for another optimal tuner then tries to make a seamless<br>
switch. If done REALLY well the user (and the ringbuffer) wouldn&#39;t<br>
even notice...<br>
- If no switch can be made, bring up the existing dialog and let the<br>
user decide what to do!<br>
<br>
This reduces interaction by setting a hierarchy: scheduler eats first<br>
(since it deals with predictable events) and LiveTV(s) get whatever&#39;s<br>
left.. plus the scheduler code stays as it is today.<br>
<br>
No promises but I&#39;ll look into making a patch out of this.</blockquote><div><br></div><div>That approach sounds like a worthwhile exploration for sure. But our preference would still be for a harmonisation of the tuner management for both LiveTV and the scheduler... and since we&#39;re part way down that road here I&#39;d like to finish our current work and see whether we can get a working patch.</div>

<div><br></div><div>Andrew</div></div><br><br clear="all"><br><br>