[Digikam-devel] [digikam] [Bug 323062] digikam (core): Schema update to V 7 failed!
TSa
thomas at sandlass.de
Sun Aug 18 15:08:51 BST 2013
https://bugs.kde.org/show_bug.cgi?id=323062
TSa <thomas at sandlass.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |thomas at sandlass.de
--- Comment #13 from TSa <thomas at sandlass.de> ---
HaloO,
I am not sure if I should hijack this bug or open a new one. Sorry for any
inconvenience.
Recently i tried to upgrade from digikam 0.93 on kubuntu 8.04 to digikam 3.1 on
kubuntu 13.04.
At startup digikam tried to convert the database version. While this happened I
saw a progressbar
and the message "throwing away V3 tables" then the error that the upgrade from
V6 to V7 failed
has occurred. I confirm this with OK and the message box disappears. Thereafter
all my albums, photos and tags are visible. However when I restart digikam I
get just the V6 to V7 error and no photos and tags are loaded.
I can reproduce the initial behaviour by deleting the digikam4.db file and
restarting with the original digikam3.db file.
I have upgraded digikam to version 3.2 following a tutorial. This gave me a
core dump on the update dialog. For investigating this I have tried to build
the newest version from GIT but the configure failed on my kubuntu 13.04
environment for not being new enough. So I have built
version 3.2 for debugging and found the reason for the core dump:
void CollectionScanner::scanFileNormal(const QFileInfo& fi, const ItemScanInfo&
scanInfo)
{
bool hasAnyHint = d->hints && d->hints->hasAnyNormalHint(scanInfo.id);
// if the date is null, this signals a full rescan
if (scanInfo.modificationDate.isNull() ||
(hasAnyHint && d->hints->hasRescanHint(scanInfo.id)) )
{
if (d->hints) // TSa added: could be null
{
QWriteLocker locker(&d->hints->lock);
d->hints->rescanItemHints.remove(scanInfo.id);
}
rescanFile(fi, scanInfo);
return;
}
I have fixed it by checking d->hints for null. Then 3.2 behaves exactly as 3.1:
I see all my tags
when starting from the digikam3.db file but not from the digikam4.db file.
Unfortunately I am not a database developer but I am willing to debug this as
needed. What I could find out easily is the offending DBAction. For printing it
in gdb I´ve copied the QString into a temporary const char *sm that can be
printed. Here is the debug result in
DatabaseCoreBackend::QueryState DatabaseCoreBackend::execDBAction(
const DatabaseAction& action, const QMap<QString,
QVariant>& bindingMap, QList<QVariant>* const values,
QVariant* const lastInsertId)
(gdb) p sm
$1 = 0x7fffcc00c188 " CREATE TABLE VideoMetadata\n", ' ' <repeats 28 times>,
"(imageid INTEGER PRIMARY KEY,\n", ' ' <repeats 28 times>, "aspectRatio
TEXT,\n", ' ' <repeats 28 times>, "audioBitRate TEXT,\n", ' ' <repeats 21
times>...
(gdb) n
660 result = execDirectSql(actionElement.statement);
(gdb)
663 if (result != DatabaseCoreBackend::NoErrors)
(gdb) p result
$2 = {value = Digikam::DatabaseCoreBackend::SQLError}
OK, this is where I´m standing right now. What should I do next to investigate
the problem?
Regards TSa.
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the Digikam-devel
mailing list