[mythtv-users] Tuner Schedules

[Simon Hobson]

Rob Smith wrote:

>It's actually less the scheduler and more the source data. He won't be
>able to use the same source for each tuner as all the guide data is
>stored per source. If he removes it for one tuner, he removes it for
>all tuners.
>
>That said, he can muck around with duplicating guide data and thus
>increasing the time it takes to run a fill database and increase the
>scheduler time by a ton.

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.

Munging the data may take a bit of setting up, but once done should 
not be a big task.

>Also, if the mythfilldatabase runs during the window, all his guide
>data will be added and myth will fight to get the tuner back until he
>re-wipes the data and forces a global reschedule, thus losing
>recordings and messing up the misses live tv viewing.

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

I don't see any window there for messing things up.

Alternatively, there is another method :
1) Fetch guide data
2) Split data into two sets, one per tuner/input
3) Insert new guide data into database
Steps 2 & 3 could be rewritten as "insert data twice, once for each 
tuner/input"
4) Delete data for time out blocks
5) Trigger reschedule on new data

This method does have a very small window during which the scheduler 
could see the data - but you'd have to trigger it to run during that 
very small time window (matter of a few seconds) between inserting 
the new data and clearing the time windows. Even that shouldn't be an 
issue since you'll trigger a reschedule a few seconds later and 
things would be sorted out.

>So yes, removing the data is a solution, but it has a pile of
>tradeoffs not fully explored previously in this thread and is why
>we're not recommending he undertake that solution. It's really not as
>easy and error free as you guys think when dealing with multiple
>tuners.

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

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