[mythtv-users] Mythtv automatically going to a source

[Jean-Yves Avenard]

Hi

2008/8/27 Michael T. Dean <mtdean at thirdcontact.com>:
> It uses the newest backup based on the filename, where potential files
> are assumed to start with the database name (this assumption is only
> made when no filename is specified, so it's not as bad an assumption as
> it first seems).  So, mythconverg-20080826* or mythconverg-2008_08_26*
> are good, but mythconverg-Aug_26_2008* or mythconverg-08262008 or
> mythconverg-26082008 are not.

Today I have:
drwxr-xr-x 5 avenardj root         32 Aug 16 01:32 ..
-rw-r--r-- 1 mythtv   mythtv 12341176 Aug 23 02:00
mythconverg-1214-20080823020003.sql.gz
-rw-r--r-- 1 mythtv   mythtv 12105877 Aug 24 02:00
mythconverg-1214-20080824020003.sql.gz
-rw-r--r-- 1 mythtv   mythtv 12209396 Aug 25 02:00
mythconverg-1214-20080825020003.sql.gz
-rw-r--r-- 1 mythtv   mythtv 11587798 Aug 26 02:00
mythconverg-1214-20080826020003.sql.gz
-rw-r--r-- 1 mythtv   mythtv 11246377 Aug 27 02:00
mythconverg-1214-20080827020001.sql.gz

Yesterday obviously 20080827020001 wasn't there, and the earliest
backup was 20080822020003

And this is the one it used when I didn't specify which backup to use
for restore.


>
> Or, put another way, it uses the newest backup if you're using backups
> created by the backup script and don't specify a filename for the backups.

Which is what I'm doing, I have a cron running at 2PM running the backup script

>
> Perhaps I should make that more clear in the --help (the "based on the
> filename" may not be as clear as I thought it was).
>
> So, what were your filenames?  Does what I mentioned above explain why
> it chose the one it did?  If not, there may be localization/character
> encoding issues or something, and I'll need more info to fix it.

Actually, it doesn't :)

It could be to the extra 1214 added to the name ; no idea where that
number in the filename is coming from..
I precisely followed the steps in the wiki you wrote

>
> Oh, and out of curiosity, to which documentation were you referring, the
> --help output or the wiki page (which, in my attempt to be concise, may
> not have even included the "based on the filename" part)?
>

I'm referring to the --help (which I find far more useful than the wiki page).

For example, when I first ran the restore, I got an error that the
database wasn't empty.
I then deleted the mythconverg database. Ran the restore again ; again
it gave me an error that the database didn't exist.

So I create the database with create database mythconverg;

Then ran restore again ... It errored out. So I looked at --help again
to find out I had to run it with create_database argument and the path
to the default mythtv mysql schema.

It gave me an error that the database wasn't empty again.
The last run of restore had created the database even though it
errored out (I didn't provide a valid path to the mysql schema)..

Delete the database again, ran again the restore script with all the arguments.

The wiki doesn't explain at all that bit : how to create the database,
arguments to provide to the script etc.

Then I found out that it didn't restore the proper backup ...

Here is my bash history:
  960  bin/mythconverg_restore.pl
  961  less bin/mythconverg_restore.pl
  962  cat ~/.mythtv/backuprc
  963  ls -l /data/backup/mythtv/
  964  bin/mythconverg_restore.pl
  965  bin/mythconverg_restore.pl --help
  966  bin/mythconverg_restore.pl --help | less
  967  bin/mythconverg_restore.pl --help | less
  968  exit
  969  mysql -u root -p
  970  bin/mythconverg_restore.pl --create_database
  971  locate mc.sql
  972  bin/mythconverg_restore.pl --create_database
/usr/share/doc/mythtv-docs-0.21/database/mc.sql
  973  mysql -u root -p
  974  bin/mythconverg_restore.pl --create_database
/usr/share/doc/mythtv-docs-0.21/database/mc.sql
  975  mysql -u root -p
  976  bin/mythconverg_restore.pl --create_database
/usr/share/doc/mythtv-docs-0.21/database/mc.sql
  977  su
  978  bin/mythconverg_restore.pl --create_database
/usr/share/doc/mythtv-docs-0.21/database/mc.sql --filename
/data/backup/mythtv/mythconverg-1214-20080826020003.sql.gz
  979  mysql -u root -p
  980  bin/mythconverg_restore.pl --create_database
/usr/share/doc/mythtv-docs-0.21/database/mc.sql --filename
/data/backup/mythtv/mythconverg-1214-20080826020003.sql.gz

And the mysql command history:
drop database mythconverg;
create database mythconverg;
drop database mythconverg;
create database mythconverg;
drop database mythconverg;
create database mythconverg;
drop database mythconverg;
create database mythconverg;
drop database mythconverg;
create database mythconverg;
drop database mythconverg;
create database mythconverg;
drop database mythconverg;
create database mythconverg;
drop database mythconverg;
create database mythconverg;
drop database mythconverg;
create database mythconverg;

As you can see, I dropped and re-created the database several times ;
the reason being that when the restore script is run and errors, it
leaves the database in an unusable state ...

Jean-Yves