[mythtv-users] Listed in the guide, did not record

Michael T. Dean mtdean at thirdcontact.com
Tue Aug 4 21:31:06 UTC 2009


On 08/04/2009 03:32 PM, Mathog David wrote:
> On Tue, 8/4/09, Michael T. Dean wrote:
>   
>>> Anybody know what this is and how to fix it?
>>>       
>> http://www.gossamer-threads.com/lists/mythtv/users/264034#264034
>>     
> OK, sure, "Nuke it from orbit" will probably work.
>
> Can anybody suggest something a little less drastic?  For instance, how to tell in MySQL exactly what is broken?  I did run one database checking script
> (I do not recall the source) and it didn't find any errors in the tables.  But I think that was a structural check, and would not have picked up a bogus 
> numerical or text value in a field.

You*** obviously didn't read the links in that post, did you?  
Specifically, I recommend reading the, "Why the 'Delete All' approach?" 
post, which explains that it's a /lot/ easier to start from a 
clean/known state and configure it correctly than to find the one thing 
that's broken in the winding maze of configuration data that's related 
to tuning and fix it.

It's /especially/ a lot easier for those of us whose systems are 
properly configured for you to take 2 minutes of your time to fix it 
yourself than it is for us to walk you through all the data, all their 
relationships, and all the implications of each value in your specific 
configuration.

There is only one tool that can verify the data in your database is 
proper:  MythTV.  All data integrity checks are done within Myth's 
codebase.  If you like, you can start reading that code and figure out 
how all the data works.  Then, using your expert knowledge, you can look 
at all the individual values and find the one that's wrong.  Or, you can 
just delete the bad configuration (along with the good) and then 
reconfigure things properly.

As it is, you've already spent more time in complaining about the 
recommended approach than it would have taken to just do it and fix your 
system.  If you're worried about xmltvid, see 
http://www.mythtv.org/wiki/Database_Backup_and_Restore#Restore_xmltvids_after_a_channel_scan 
or, if you're a Comcast user in an area with SCTE, see the scte65scan tool.

I happened to need to rescan today, anyway, so I decided to just go 
ahead and do it now, and I timed it.  I started with:

mythconverg_backup.pl --backup_xmltvids --directory="$HOME" --verbose

(At this point, you may also want to do:
mythconverg_backup.pl --directory="$HOME" --verbose
to get a full backup, but as my shutdown script calls 
mythconverg_backup.pl, I got a full backup when I shut down mythbackend, 
so I didn't do so manually.)

Then I did a "Delete all video sources" (as I just had channels that 
changed and haven't changed any (of my 4) capture cards or drivers, so 
didn't need to do that part), then re-created the video source and then 
re-connected (all 4) inputs and scanned for channels, then restored the 
xmltvids with:

mythconverg_restore.pl --restore_xmltvids --directory="$HOME" --verbose

Including backing up and fixing the xmltvid's, it took all of 7 
minutes--and I wasn't even hurrying.  The Full Scan of the US ATSC 
channels took 5 of those minutes.  That means 2 minutes of my time plus 
5 minutes of start it and walk away computer time.

Afterwards, I ran mythfilldatabase, which took a several minutes (since 
it had to populate all 14 days), but that job was even less of a 
problem--you can start it and walk away and be done (you don't have to 
return to finish afterwards, as with the channel scan).

Anyway, it's /really/ not a bad way of doing things.  It cleans up all 
the garbage in your capture card/video source/card 
input/channel/listings/... configuration, and--after doing it--Myth 
works great, no matter how messed up that part of your configuration was 
before doing it.

Mike

***Where "you" does not mean only you, but about 10 people to whom I've 
recommended that specific approach in the last month.


More information about the mythtv-users mailing list