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

[Michael T. Dean]

On 04/10/2006 11:07 AM, Marco Nelissen wrote:
>> OK, then we should find out why it didn't record.  In mythfrontend, you 
>> can go to the Previously Recorded page, find the showing (assuming it 
>> was within the last 7 days) and find out why it didn't record.  If you 
>> can't find it in the listing (and it was within the last 7 days), that's 
>> important, too.
>>     
> It's not shown on the "previously recorded" page (which goes back almost
> 2 months, not just 7 days). 

Previously recorded goes back "forever" (records are never removed for 
shows that were recorded).  For shows that were /not/ recorded, records 
are removed after 7 days.

So, I was hoping to get information about whether it was within the last 
7 days before having to type up this explanation.  I guess I'll just 
assume that it was...

If it was within the last 7 days and was not in the list, you probably 
missed the show because of a configuration error in one (or more) of 
your video sources.  If you had a configuration error, mythfilldatabase 
would notice a failure during the video source update and abort after 
finishing download of data for all video sources.  The idea was that 
users would notice the errors in their mfdb logs and fix them...  
Unfortunately, this idea doesn't pan out in the real world.  :)

When mfdb aborted, it failed to do the post-download processing, which 
included a re-run of the scheduler for all recording rules.  I lost a 
recorded because of this and tracked it down to a mis-configured video 
source.  See 
http://www.gossamer-threads.com/lists/mythtv/dev/188597#188597 for 
details of my configuration error.  The other poster in that thread also 
identified the root cause as a (different) video source configuration 
error, but I don't remember the specifics.

Since then, Chris Pinkham has committed a change to SVN head ( 
http://www.gossamer-threads.com/lists/mythtv/commits/188595#188595 ) 
that fixes this by allowing mfdb to continue it's post-download 
processing even if errors were detected during the video source 
updates.  Next time I see him online, I'll ping him about getting this 
fix into the -fixes branch (it's currently a "candidate" for inclusion 
and has probably had enough use in SVN head to make it safe for inclusion).

Mike