[mythtv-users] Tuner Schedules

[Simon Hobson]

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
Call scheduler


* 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.

-- 
Simon Hobson

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.