[Digikam-devel] [digikam] [Bug 327377] Upgrade to 3.5.0 caused loss of collection, re-adding caused loss of tags

[Rainer Dorsch]

https://bugs.kde.org/show_bug.cgi?id=327377

--- Comment #1 from Rainer Dorsch <ml at bokomoko.de> ---
I could narrow down the problem, which may allow to find the root cause:

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: ()

For a full stderr see http://bokomoko.de/~rd/kde-327377-stderr.log

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 that digikam gets confused by several mounts with the same device
uuid.... Since I do not know what algorithm digikam implements here to derive
the uuid, it is hard for me to provide further data. Let me know if you can
identify which additional data would be helpful to find the root cause of the
problem.

Unmounting the /scratchbox/... dirs is a workaround for the problem.

I think the problem was not introduced by the upgrade from digikam 3.4 to 3.5,
I consider it more likely that it is related to the upgrade of my Debian
distribution to jessie (but still it is likely a bug in digikam).

Thanks,
Rainer

-- 
You are receiving this mail because:
You are the assignee for the bug.