[mythtv-users] mythconverg.recordmatch doesn't exist

[David Engel]

Please don't top-post.  The preferred response style on this list is
to reply in-line or at the bottom.  I fixed it this time, but probably
won't the next time.

On Mon, May 20, 2013 at 01:59:00PM -0500, Jason Bilbrey wrote:
> On Mon, May 20, 2013 at 1:05 PM, Jason Bilbrey <jason at bilbrey.me> wrote:
> > On Sun, May 19, 2013 at 10:24 AM, David Engel <david at istwok.net> wrote:
> >> On Sat, May 18, 2013 at 10:36:38AM -0500, Jason Bilbrey wrote:
> >> > My scheduler suddenly stopped working.  I've run a optimize_mythdb.pland
> >> > it ran fine.  When I run mythbackend --testsched I get the following
> >> error:
> >> >
> >> > Error preparing query: CREATE TEMPORARY TABLE recordmatch SELECT * FROM
> >> > recordmatch WHERE recordid IS NULL ;
> >> > Driver error was [2/1146]:
> >> > QMYSQL3: Unable to prepare statement
> >> > Database error was:
> >> > Table 'mythconverg.recordmatch' doesn't exist
> >> >
> >> > I looked in the database and the table called recordmatch doesn't exist
> >> > (which I think is good because it's just a temp table that gets created
> >> at
> >> > the time of the query?) but for whatever reason the scheduler is hung.
> >> >
> >> > I also have plenty of free disk space so I'm not sure where to look /
> >> what
> >> > to do next.  Any suggestions?
> >>
> >> You are misteaken about recordmatch.  While --testsched uses a
> >> temporary version, the mastetbackend needs a real, permanent one in
> >> the database.  You have apparently lost yours and who knows what else
> >> in your database.  You will need to restore the database from your
> >> most recent backup.
> >
> > Thanks David.  I restored just the recordmatch table from a backup and
> > then the scheduler started working again and shows began recording based on
> > my recording rules again.
> >
> > Not sure how it got corrupted in the first place but that definitely fixed
> > it.
> >
> Anyone know what the recordmatch table does anyway?  I was looking at it
> and it doesn't seem very obvious.  Mine is exactly 1000 records long and
> seems to have a lot of repetitive data but no clear indication of what it's
> for.  Googling didn't yield any results either.

It's internal, scheduler state.  Unless you intend to work on the
scheduler, you really shouldn't be messing with it.  If you do intend
to work on it, or at least understand it, read the source code first,
then I'll be happy to answer any questions you have.

David
-- 
David Engel
david at istwok.net