[mythtv-users] Tuner Schedules

Rob Smith kormoc at mythtv.org
Fri Mar 18 22:06:20 UTC 2011


On Fri, Mar 18, 2011 at 1:19 PM, Simon Hobson <linux at thehobsons.co.uk> wrote:
> Why should it increase scheduler time "by a ton" ? On my system I
> can't say I even notice the scheduler time, so unless you've got a
> particularly complex setup and/or very slow system then I don't see
> this being an issue. Don't forget that people are running systems now
> with multiple different sources with multiple (often overlapping)
> schedule information.

Yes. If you're under the line (about a minute) you won't notice them.
When it gets beyond that line, you will notice and you do run into
issues (missing the start of your programs, etc).

It's not like I know anything about this code path or anything, right?
I mean, I've only spent a ton of time optimizing the scheduler for
0.24 and optimizing mythfilldatabase so you won't notice the runs, but
I guess that doesn't mean I understand how it works or anything...

> Err, not at all. Consider this sequence :
> 1) Fetch guide data
> 2) Split/munge data into two sets with suitable time windows blocked out
> 3) Insert new guide data into database
> 4) Trigger reschedule on new data

You're no longer using the backend to run mythfilldatabase then.
You're also ignoring the next grab time and date we (Schedules Direct)
asks you to honor. You're also writing your own grabber basically. Is
it doable? Sure. Is it complex and beyond what the parent was
considering? Yes. (He was going to grab and then delete out of the
database for the windows, leading to the complication I described).

> "pile of tradeoffs" seems a bit overstated. I'd suggest the method I
> propose is actually both (relatively) easy and error free - whereas
> you seem to prefer an option that is virtually guaranteed to create
> problems and missed recordings.

Rewriting a grabber is easy for you and me, but not necessarily for
the specific user. I don't assume the user is planning to code nor has
the ability to code such a solution.

I'll bow out of this conversation now. I've said my peace and I'm
going await Simon Hobson's patches to the code I've committed given
his greater understanding of the process then I.

~Rob


More information about the mythtv-users mailing list