[mythtv-users] Tuner Schedules
linux at thehobsons.co.uk
Sat Mar 19 08:57:19 UTC 2011
Rob Smith wrote:
>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...
If you think I was implying that then you have not understood what I wrote.
> > 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.
Now you are reading into it things I did not say. My assumption was
that this would be done by putting a slice of code between the
backend and the normal grabber - so grabs would still be scheduled by
the backend, could still honour any any constraints requested by the
schedule source etc.
Since "all your doing"* is stripping out some data between it being
fetched and being loaded into the database, then any problems with
programs appearing, disappearing, late scheduling causing the start
of programs to be missed ... would be exactly the same ones that I
don't recall seeing with the regular unmodified code**. The same
non-problem would occur if the data strip was after loading the
database, but before running the scheduler.
How hard is that do do ? I honestly don't know - I've never had
reason to look at the code. But given how modular the system is, and
the fact that the grabbers themselves are effectively modules, I find
it really hard to believe there isn't somewhere in there with a
structure along the lines of :
Call program/module to fetch data
Load data into DB
* yes, I know, it's easy for a non-programmer to say that.
** Apart from where programs do disappear from the schedules in an
update of course.
>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.
Err, I don't recall suggesting re-writing a grabber either. There's a
**HUGE** difference between inserting a line of code between "fetch
and prepare data" and "insert into DB" (or "fetch and prepare data
and insert into DB" and "return") - and rewriting a grabber.
No I don't claim to have the programming skills to do it - I was
merely suggested what I would consider the best method from the POV
of scheduling recordings. Now do I know what the OPs skill level is -
but I did get the impression that he has some ability.
Suppose there are two programs I like to watch. I really want to
watch A, and I also really like to watch B - but given the choice of
one or the other I'd rather record A.
Suppose both are on at the same time, then A is repeated later.
The main suggestion is to just "turn off" the tuner for the window
specified. If that means the second showing of A is not recordable
then I'll get B recorded earlier, but A will get missed.
The solution to this is that a setting is made so that no matter
what, A will be recorded in the first slot - so B will never get
recorded, and A won't be scheduled for the second showing.
My argument is that by doing this, there are other situations where
both A and B could have been recorded (such as when the second
showing of A was not in a blocked out period). So this is a
sub-optimal solution - it permanently and deliberately degrades your
excellent scheduler in a manner that isn't necessary.
For the OP's situation, he's not bothered that there won't be
listings for the blocked out period - the WAF induced restriction
means he won't be using that tuner anyway. I know my suggestion is
far from perfect, the original requirement is far from perfect, but I
do believe it offers less drawbacks than the other suggestion.
The solution I suggest means that in the first case, the scheduler
will work on the basis that the second showing of A is not available
- and so will not be able to record B. In the case where the second
showing *IS* available, then A and B will both get recorded.
If I've missed some magic whereby turning off a tuner without prior
notice will somehow allow the scheduler to handle both these cases
then I'll be happy to be corrected.
Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
More information about the mythtv-users