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@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@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/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org