[mythtv-users] scheduling not using all three tuners?

[Steven Adeff]

On 4/11/06, Max Barry <mythtv at maxbarry.com> wrote:
> Michael T. Dean wrote:
> > Marco Nelissen wrote:
> >> I got
> >> an off-list email from someone who submitted a patch for it, which is
> >> scheduled to go into the .20 release.
> >
> > He sent the mail to the list, too, but it was the -dev list.
>
> Sorry, I am that idiot. Stupid auto-completion of email addresses!
>
> I haven't followed this topic for a while, but I'm thrilled to see the
> dev discussion here:
>
> http://www.gossamer-threads.com/lists/mythtv/dev/195124
>
> And they even mention me. :)
>
> For the uninitiated, here's the history.
>
> Disclaimer: I've submitted a couple of patches and am an enthusiastic
> user, but that's the extent of my involvement with MythTV. I apologize
> if my impression of the situation is incorrect in any way.
>
> Okay. A long time ago, and mostly in a country far, far below the
> Equator, some people got annoyed at the behavior of the pre-roll and
> post-roll buffers. (Which I shall call "soft buffers," and which are
> also known as "Overtime Recording buffers.") These people--which
> included myself--were using the soft buffers to try to catch parts of TV
> shows that weren't broadcast within schedule. The buffers worked very
> well at this, with one exception: MythTV dumped the buffers when you
> scheduled consecutive shows, even if it had a tuner card sitting idle.
>
> This seemed like an easily fixed bug, so I took a look at the code. It
> seemed that hard-coded into MythTV was the idea that it is always
> preferable to use the "best" tuner, even if that means dropping soft
> buffers. And for some people, this is exactly right: for example, a user
> with one HD tuner, one SD tuner, and reliable guide data probably
> prefers to capture his shows in HD, rather than in SD, even if that
> means losing the global soft buffer.
>
> But for other people--in particular, people who have multiple tuners of
> the same quality, who don't tend to watch Live TV, and who have
> unreliable TV guide data--this was sub-optimal. They would frequently
> find that MythTV had dropped the soft buffer on a show that ran late,
> even though it could have kept it by employing an idle tuner.
>
> My first patch submission changed this preference, making MythTV use
> idle tuners in order to honor the soft buffers. But David, a dev,
> rightly pointed out that this would not suit everyone, so I rewrote it.
> The second version allowed users to choose whether MythTV should drop
> soft buffers in order to use a higher priority tuner card:
>
> http://cvs.mythtv.org/trac/ticket/255
>
> At this point a feisty discussion began on the -dev mailing list. The
> central objection--again, I hope I have this right, and apologize if I
> don't--was that scheduling should be done by the scheduler--not outside
> it, which is where the soft buffers currently operate.
>
> This was not an objection to my patch in particular, but rather the way
> that the soft buffers were currently being used by some users to
> compensate for unreliable guide data. That is, rather than accept my
> patch and encourage even more people to ab/use the soft buffers in this
> way, it was argued that the whole design of soft buffers in MythTV
> should be rewritten, bringing it within the scheduler.
>
> (It was also argued that there was no need to use the soft buffers for
> this purpose at all, and that hard buffers should suffice. I disagree
> with this, as summarized here:
> http://www.gossamer-threads.com/lists/mythtv/dev/152816#152816)
>
> David wrote quite a bit of code to provide a framework for a different
> kind of soft buffer to operate within, which was wonderful of him
> because he personally didn't even want the features. But I lacked the
> competence to fill in his framework, and nobody else stepped in. So at
> this point, things seemed to stall.
>
> Later, my patch was scheduled for milestone 0.20. I had thought this
> signaled it was going to be accepted--even as a temporary measure, until
> soft buffers could be completely rewritten--but now I think a fresh
> attempt to rewrite soft buffers has commenced.
>
> Which is very exciting. :)
>
> Max.

So Max, your patch gives a global hard buffer that the scheduler is
aware of? Is it an "if I can" or an "always no matter what" buffer?

thanks

--
Steve