[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