[Digikam-devel] [Bug 283681] After re-activating several collections, a huge number of raw pics cannot be opened

[Axel Krebs]

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





--- Comment #24 from Axel Krebs <axel krebs t-online de>  2011-11-03 20:39:40 ---
(In reply to comment #21)
> Provided info by Axel Krebs:
> ¨My digiKam database was quite large- 140000 pics, 6,9 GB size(!!). As I
> knew I have to work intensively with that database, I created a
> selection of only 8000 pics to gain some loading speed.
> 
> Instead of getting smaller after some loadings, it kept this size and
> loading "speed".
> 
> After some weeks, I included all other pics, I had outsourced before.
> 
> In "digiKam settings ->  collections" I added those pics by selecting a
> (sub-)directory, which are stored in a number of directories.
> ---
> 
> No I got problems: while tags had been set up hierarchical before, they
> look meshed up now. Have a look at tags "auto" and "quasimodo" in
> enclosed pic.
> 
> As the structure was correct before, I am quite sure that the internal
> structure of database might be corrupt.¨
> 
> 
> ##############################################################
> Start trying reproduce according info supplied by Axel Krebs
> ##############################################################
> 
> I start making a copy of my db containing my art collection.
> digikamdb 229 MB
> thumbnails 4,9 GB
> number of picture 136043
> number of albums 5567
> number of tags 1248
> startuptime 145 seconds. second startup 98 sec.
> 
>     This looks from the quantitative perspective more or less comparible setup
> 
> I put the NEF in one of the art folders
> It opens normal
> add some tags
> it still opens normal with image editor and with gimp
> add another tag
> every thing still normal
> 
> Now I go removing albums, but it appears that I can not remove a
> subalbum(directory) without actually deleting it.
> So I have to make a second root album ¨ARTtest¨
> Move several subalbums to ¨ARTtest¨ and remove my main root album ¨ART¨ from
> settings->etc
> I close dk
> reopen digikam
> 
> digikamdb 229 MB
> thumbnails 3,8 GB (This is changed but much larger than expected)
> number of picture 29635
> startuptime 20 sec (this is different from Axel´s experience)
> 
> Now I add under settings->configure dk etc several subalbums that formerly has
> been under the rootalbum ¨ART¨ to the new ¨ARTtmp¨
> 
> I can not detect any changes in tag structure
> Tags in NEF are still as before
> NEF can still be opened normaly.
> 
> 
> Axel, what do you think I should do differently to reproduce the problems?
> 
> I wonder about a few things that maybe could be related.
> Can there be something wrong with harddrive?
> Did you test db integrety as I suggested?
> 
> Will be happy to do further investigations if I only had a clue how to went on.
> 
> Can a corrupted db be due to corrupting NEF? Does someone know the answer?
> 
> ##############################################################
> End trying reproduce
> ##############################################################

Hi Rinus:

thanks!

1.) "What could we do": one idea: is it possible to test database _and_ digiKam
_without_ "semantic desktop" (akonadi-server and similar stuff)?

2.) defect hdrive? a hidden failure could happen everywhere... but
installation, pics _and_ database are on my boot hdrive whch is running nicely 
and beeing checked "ok"

3.) Another Consideration: digiKam offers to apply several settings to be
checked, as exif, xmp iptc. I always activate _all_ crosses. And I cross
install _into_ Nepomuk, _never_ from Nepomuk _into_ digiKam.

Maybe there is a filed size problem or a limited number of crosses allowable?
waht would happen, if the total amount of tags  digiKam handles do not "fit"
into a picture"?
What happens, if Nepomuk fails writing tags correctly into its database?
Or data-exchnge between pics and Nepomuk is questioned?

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.