[mythtv-users] Mythtv automatically going to a source

[Michael T. Dean]

On 08/26/2008 11:59 PM, Jean-Yves Avenard wrote:
> 2008/8/27 Michael T. Dean:
>   
>> 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.
>   

Hmmm.  I'll look into that.

>> 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
>   

Double ouch.

>> 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
>   

1214 is the DB schema version.

>> 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).
>   

Definitely more complete--kind of the novel form.  :)

> 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)..
>   

Right, your MySQL user (mythtv?) probably has create database 
privileges, but may not have GRANT privileges and almost definitely 
doesn't have the privilege required to run "FLUSH PRIVILEGES;" so 
running mc.sql would fail, leaving a DB without any tables.

> 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.
>   

I'll add something about that.

> 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 ...

Yeah.  I'll see if I can put some more "ground up" info in the wiki 
examples.

Thanks, again,
Mike