[Pkg-kde-extras] Bug#729119: [Bug 327337] Re: Bug#729119: digikam: Upgrade to Digikam 3.5 makes all albums disappear
Rainer Dorsch
ml at bokomoko.de
Sun Nov 10 11:32:23 UTC 2013
Hi Mark,
thanks for taking care of the problem and linking to the upstream report. I
agree with the information you provided it makes sense to downgrade the bug
severity. I expect that the problem was not introduced with the digikam
upgrade, but I still think it is a digikam bug, triggered now since I upgraded
KDE 4.10. to 4.11 and Debian wheezy to jessie.
I think I also understand now better where the problem comes from. It seems to
be related to the mount techniques, which my scratchbox installation uses. The
scratchbox is the Nokia N900 development environment. But I think others are
affected to... if they have similar mount techniques as the scratchbox
installation creates.
On Sunday 10 November 2013 17:33:18 you wrote:
> Control: forward -1 https://bugs.kde.org/show_bug.cgi?id=327377
> Control: severity -1 important
>
> On Sat, 9 Nov 2013 15:53:04 Rainer Dorsch wrote:
> > Upgrade: digikam-private-libs:i386 (3.4.0-1, 3.5.0-2), digikam:i386
> > (3.4.0-1, 3.5.0-2), digikam-data:i386 (3.4.0-1, 3.5.0-2)
>
> Rainer,
>
> I see you have also filed a report with upstream, so have noted the Debian
> bug as forwarded.
>
> There has been very little change between your upgraded versions (3.4 ->
> 3.5), as this was a maintenance release, I believe 5 bugs were fixed:
> https://bugs.kde.org/buglist.cgi?f1=cf_versionfixedin&o1=equals&query_format
> =advanced&bug_status=RESOLVED&bug_status=NEEDSINFO&bug_status=VERIFIED&bug_s
> tatus=CLOSED&v1=3.5.0&product=digikam&product=digikamimageplugins&product=ki
> piplugins&product=showfoto
This is good input. Maybe the problem is more related to my upgrade from
wheezy to jessie and digikam cannot handle some of these changes?
I restored the old db file:
>From the restored file I get
sqlite> select * from AlbumRoots;
2|family|0|1|volumeid:?uuid=3bfc8f7b-628c-425d-
af32-269e98a8f36e|/home/rd/Rohdaten/digiKam
sqlite>
There is no reference on /scratchbox/... whatsover. But on stderr I see then,
when starting digikam:
digikam(16814)/digikam (core) Digikam::AlbumRootLocation::AlbumRootLocation:
Creating new Location "/home/rd/Rohdaten/digiKam" uuid
"volumeid:?uuid=3bfc8f7b-628c-425d-af32-269e98a8f36e"
digikam(16814)/digikam (core) Digikam::CollectionManager::updateLocations:
location for "/scratchbox/users/rd/scratchbox/home/rd/Rohdaten/digiKam" is
available true
/scratchbox/users/rd/scratchbox/home/rd/Rohdaten/digiKam is wrong and this
triggers all the problems. To validate: if I add a symlink which creates
/scratchbox/users/rd/scratchbox/home/rd/Rohdaten/digiKam everything is fine.
Let me try to illustate (unfortunately I cannot fully explain), why digikam
runs into trouble without that artificial symlink:
digikam finds /scratchbox/users/rd/scratchbox/home/rd/Rohdaten/digiKam does not
exist and now digikam identifies a lot of removed stuff:
digikam(16814)/digikam (core) Digikam::KMemoryInfo::update: Platform identified
: "LINUX"
digikam(16814)/digikam (core) Digikam::KMemoryInfo::bytes: TotalRam:
4239216640
digikam(16814)/digikam (core) Digikam::LoadingCache::setCacheSize: Allowing a
cache size of 200 MB
digikam(16814)/digikam (core) Digikam::ThumbnailSchemaUpdater::startUpdates:
Have a thumbnail database structure version "2"
digikam(16814)/digikam (core)
Digikam::ThumbnailLoadThread::initializeThumbnailDatabase: Thumbnail db ready
for use
digikam(16814)/digikam (core) Digikam::CollectionScanner::itemsWereRemoved:
Removed items: () related items: ()
digikam(16814)/digikam (core) Digikam::CollectionScanner::itemsWereRemoved:
Removed items: () related items: ()
digikam(16814)/digikam (core) Digikam::CollectionScanner::itemsWereRemoved:
Removed items: (36481, 36482, 36483, 36484, 36485, 36486, 36487, 36488, 36489,
36490, 36491, 36492, 36493, 36494, 36495, 36496, 36497, 36498, 36499, 36500,
36501, 36502, 36503, 36504, 36505, 36506, 36507, 36508, 36509, 36510, 36511,
36512, 36513, 36514, 36515, 36516, 36517, 36518, 36519, 36520, 36521, 36522,
36523, 36524, 36525, 36526, 36527, 36528, 36529, 36530, 36531, 36532, 36533,
36534, 36535, 36536, 36537, 36538, 36539, 36540, 36541, 36542, 36543, 36544,
36545, 36546, 36547, 36548, 36549, 36550, 36551, 36552, 36553, 36554, 36555,
36556, 36557, 36558, 36559, 36560, 36561, 36562, 36563, 36564, 36565, 36566,
36567, 36568, 36569, 36570, 36571, 36572, 36573, 36574, 36575, 36576, 36577,
36578, 36579, 36580, 36581, 36582, 36583, 36584, 36585, 36586, 36587, 36588,
36589, 36590, 36591, 36592, 36593, 36594, 36595, 36596, 36597, 36598, 36599,
36600, 36601, 36602, 36603, 36604, 36605, 36606, 36607, 36608, 36609, 36610,
36611, 36612, 36613, 36614, 36615, 36616, 36617, 36618, 36619, 36620, 36621,
36622, 36623, 36624, 36625, 36626, 36627, 36628, 36629, 36630, 36631, 36632,
36633, 36634, 36635, 36636, 36637, 36638, 36639) related items: ()
I cannot tell for sure, why digikam gets the wrong directory, but let me check
for the uuid from AlbumRoots:
sqlite> select * from AlbumRoots;
2|family|0|1|volumeid:?uuid=3bfc8f7b-628c-425d-
af32-269e98a8f36e|/home/rd/Rohdaten/digiKam
sqlite>
check for the uuid:
rd at blackbox:~/tmp.nobackup$ mount|grep 3bfc
/dev/disk/by-uuid/3bfc8f7b-628c-425d-af32-269e98a8f36e on / type ext4
(rw,noatime,discard,errors=remount-ro,data=ordered)
/dev/disk/by-uuid/3bfc8f7b-628c-425d-af32-269e98a8f36e on
/scratchbox/users/rd/scratchbox type ext4 (rw,noatime,discard,errors=remount-
ro,data=ordered)
/dev/disk/by-uuid/3bfc8f7b-628c-425d-af32-269e98a8f36e on
/scratchbox/users/rd/dev type ext4 (rw,noatime,discard,errors=remount-
ro,data=ordered)
rd at blackbox:~/tmp.nobackup$
It seems digikam would have been better of to rely on the path and not to try
to reverse-map the uuid (which seems to be good for removable devices?).
Also unmounting the /scratchbox/... dirs fixes the problem.
> There have also been no other reports of albums disappearing, although 3.5
> has been available since 10 October, so I have set the severity of your
> report to important.
>
> I would imagine it has to do with the location of your digikam4.db file, is
> that located in your Pictures directory and have you changed this? I would
No, I did not change the database location. Would it be better to have the
digikam4.db not in the Pictures directory?
> recommend you check the quality of these databases, especially your backup
> before you used digikam/3.5:
> http://userbase.kde.org/Digikam/Check_Database
Database seems to be ok
$ sqlite3 -line ~/Rohdaten/digiKam/digikam4.db 'pragma integrity_check;'
integrity_check = ok
$ sqlite3 -line ~/Rohdaten/digiKam/thumbnails-digikam.db 'pragma
integrity_check;'
integrity_check = ok
$
>
> Your tags can also be located in digikam4.db, unless you choose to store
> them in each picture file.
I did not store them in each picture file.
> I'll let the digikam team provide you some further assistance via 327337.
>
Will this report get forwarded?
Many thanks again,
Rainer
--
Rainer Dorsch
http://bokomoko.de/
More information about the pkg-kde-extras
mailing list