[mythtv-users] cannot restore database

UB40D ub40dd at googlemail.com
Sat Feb 21 16:53:37 UTC 2015


On Sat, Feb 21, 2015 at 4:30 PM, Stephen Worthington <
stephen_agent at jsw.gen.nz> wrote:

>
>
> My guess would be that some of the internal MySQL tables that control
> things are corrupt also, so you likely need to run mysqlcheck to see
> what is wrong and then use its repair option if necessary.
>
>
I did a bunch of mysqlcheck with various options such as --check, --repair,
--auto-repair (never getting any output). Not sure what they did, if
anything, but
now if I do my original command

mythconverg_restore.pl --drop_database --create_database --verbose
--filename  mythconverg-1317-20150220033002.sql.gz


it says it can't drop the database


...blablah...

Preparing initial database.

Dropping database.


ERROR: Unable to drop database.

Error dropping database (can't rmdir './mythconverg/', errno: 17)

and if I try the same without --drop_database it says there is one already
so it can't create:

mythconverg_restore.pl --create_database --verbose --filename
mythconverg-1317-20150220033002.sql.gz


..blah..

Preparing initial database.

Creating database.


ERROR: Unable to create database.

Can't create database 'mythconverg'; database exists


I hate when they give you a relative path in the error message. Where the
hell is that ./mythconverg/ it can't rmdir? Is it that it can't rmdir
because it doesn't have permission to it, or because it's not there? If the
latter, what's the bit of database that still exists when the script fails
to create the database?

find / -name mythconverg -print

gives nothing (other than the usual annoying bunch of "permission denied"
on /proc etc)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20150221/6fe5a3f5/attachment.html>


More information about the mythtv-users mailing list