Bug 281767 - digikam 2.1 will not start
Summary: digikam 2.1 will not start
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Scan (show other bugs)
Version: 2.1.0
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-10 19:35 UTC by Anders Lund
Modified: 2017-07-25 13:20 UTC (History)
11 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.2.0


Attachments
Diff Digikam 2.1 tarball and current git (7.68 KB, patch)
2011-09-11 14:40 UTC, Philip Johnsson
Details
Diff between git tag v2.1.0 and digikam-2.1.0 tarball, core subdirectory (196.62 KB, patch)
2011-09-11 16:36 UTC, Andreas K. Huettel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anders Lund 2011-09-10 19:35:10 UTC
Version:           2.1.0
OS:                Linux

When trying to start digikam 2.1 first time, it told me that the database were broken, but it would try to reconnect, then went into eternal doing nothing. I killed the process and downgraded to 2.0 which runs fine.

Is there a secret migration tool like in kmail? Or something I can do to make it work? My database contains years of tagged files, so I really do not want to risk it!

Reproducible: Didn't try

Steps to Reproduce:
bko is broken

Actual Results:  
bko is broken

Expected Results:  
bko is broken

OS: Linux (i686) release 3.0-ARCH
Compiler: gcc
Comment 1 Marcel Wiesweg 2011-09-10 20:58:46 UTC
> When trying to start digikam 2.1 first time, it told me that the database were
> broken, but it would try to reconnect, then went into eternal doing nothing. I
> killed the process and downgraded to 2.0 which runs fine.

Sounds like MySQL, but you may want to tell us explicitly which database system you are using

> Steps to Reproduce:
> bko is broken
> 
> Actual Results:  
> bko is broken
> 
> Expected Results:  
> bko is broken

??
Comment 2 Andreas K. Huettel 2011-09-11 00:32:36 UTC
Same seen in Gentoo after the upgrade, at some point I gave up and "fixed" it by wiping my database and entire digikam settings. I know this is not particularly informative... :|
Comment 3 Rinus Bakker 2011-09-11 07:34:50 UTC
same happened to me but after reinstalling dk and reboot ubuntu and after clicking cancel in the automatic reconnection proces it started, with rereading the whole database.

This tread maybe related
http://mail.kde.org/pipermail/digikam-users/2011-September/014211.html

Rinus
Comment 4 Anders Lund 2011-09-11 07:47:08 UTC
@Marcel:  I do not know what database system I am using. I thought digikam used sqlite?

@Rinus: Sounds good, but the message I got after pressing cancel was that it would start with not database at all, leading me to back out immediately.

I wonder if there is an organized way to do a backup in digikam?
Comment 5 Anders Lund 2011-09-11 08:01:28 UTC
The relevant section of digikamrc looks like this:

[Database Settings]
Database Connectoptions=
Database Hostname=
Database Name=/home/anders/Pictures/
Database Name Thumbnails=/home/anders/Pictures/
Database Password=
Database Port=-1
Database Type=QSQLITE
Database Username=
Internal Database Server=false
Comment 6 Marcel Wiesweg 2011-09-11 13:50:27 UTC
Anders: Yes you are using SQLite (if someone doesn't know what he's using, it's SQlite ;-) )

Database (SQLite) was broken starting from 37f5f5 (Sep 6th), sharply after the 2.1 tag, until 0ef128 (Sep 10th). Current git works again, I am using SQLite myself.
I hope the 2.1 tag is precise and the broken commit is not included in the tarball.
Comment 7 caulier.gilles 2011-09-11 13:56:07 UTC
Nicolas,

Can you confirm that commit #37f5f5 has not been included in your 2.1.0 tarball ?

Gilles Caulier
Comment 8 Philip Johnsson 2011-09-11 14:24:25 UTC
If it's any help. I attached a diff between current git and the 2.1
tar-ball source code of core/libs/database/. Not sure what the #37f5f5
commit is.

/Philip


On Sun, Sep 11, 2011 at 3:56 PM, Gilles Caulier
<caulier.gilles@gmail.com> wrote:
> https://bugs.kde.org/show_bug.cgi?id=281767
>
>
> Gilles Caulier <caulier.gilles@gmail.com> changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                 CC|                            |neoclust.kde@free.fr
>          Component|general                     |Database
>
>
>
>
> --- Comment #7 from Gilles Caulier <caulier gilles gmail com>  2011-09-11 13:56:07 ---
> Nicolas,
>
> Can you confirm that commit #37f5f5 has not been included in your 2.1.0 tarball
> ?
>
> Gilles Caulier
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are the assignee for the bug.
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel@kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel
>
Comment 9 Philip Johnsson 2011-09-11 14:40:50 UTC
Created attachment 63560 [details]
Diff Digikam 2.1 tarball and current git
Comment 10 Andreas K. Huettel 2011-09-11 16:22:49 UTC
(In reply to comment #7)
> Nicolas,
> 
> Can you confirm that commit #37f5f5 has not been included in your 2.1.0 tarball
> ?
> 
> Gilles Caulier

37f5f5d5 is definitely included in the tarball that I downloaded from sourceforge and that went into the Gentoo mirror system. :(
Comment 11 Andreas K. Huettel 2011-09-11 16:24:28 UTC
(In reply to comment #10)
> (In reply to comment #7)
> > Nicolas,
> > 
> > Can you confirm that commit #37f5f5 has not been included in your 2.1.0 tarball
> > ?
> > 
> > Gilles Caulier
> 
> 37f5f5d5 is definitely included in the tarball that I downloaded from
> sourceforge and that went into the Gentoo mirror system. :(

PS. Just as a personal remark, it might be useful if you guys would be hanging out at #digikam for a while after making a release tarball... the packager chatter there is quite constructive...
Comment 12 Andreas K. Huettel 2011-09-11 16:36:01 UTC
Created attachment 63562 [details]
Diff between git tag v2.1.0 and digikam-2.1.0 tarball, core subdirectory
Comment 13 Andreas K. Huettel 2011-09-11 18:06:44 UTC
(In reply to comment #12)
> Created an attachment (id=63562) [details]
> Diff between git tag v2.1.0 and digikam-2.1.0 tarball, core subdirectory

It's getting worse. I patched the code back to the exact state of the 2.1.0 tag, and re-installed digikam on my local box. With the database that was touched by the 2.1.0-tarball version, the 2.1.0-tag version immediately crashes with a segfault. So whoever managed to update to 2.1.0-tarball cannot go back to 2.1.0-tag.

Thread 1 (Thread 0x7f97466af800 (LWP 28924)):
[KCrash Handler]
#6  Digikam::DatabaseCoreBackend::setDatabaseErrorHandler (this=0x0, handler=0x2184820) at /var/tmp/portage/media-gfx/digikam-2.1.0-r2/work/digikam-2.1.0/core/libs/database/databasecorebackend.cpp:1624
#7  0x0000000000589bc9 in Digikam::AlbumManager::setDatabase (this=0x208c930, params=..., priority=<value optimized out>, suggestedAlbumRoot=...) at /var/tmp/portage/media-gfx/digikam-2.1.0-r2/work/digikam-2.1.0/core/digikam/album/albummanager.cpp:726
#8  0x000000000067f423 in main (argc=33553984, argv=0x7fff0000001d) at /var/tmp/portage/media-gfx/digikam-2.1.0-r2/work/digikam-2.1.0/core/digikam/main/main.cpp:185
Comment 14 Francesco Riosa 2011-09-11 20:44:57 UTC
that's because only a little part of 37f5f5d5 is part of 2.1.0 tarball, the patch was already sligtly broken, but having only a little part of it make stuff definitly broken.

What happened here? should have waited one day more to commit? too near to the tagging? Or the tarball has not been created from the tag?

Damn, I've waited two week to commit only to have one full month for testing :(

Anyway, seem solved downstream in gentoo with media-gfx/digikam-2.1.0-r2
Comment 15 caulier.gilles 2011-09-11 20:56:24 UTC
This is the story :

When 2.1.0 have been tagged by Nicolas, the release have been delayed from few days, due to some problems to compile libkvkontakte  with kipi-plugins.

We have talk about by mail for a long time to find the right solution.

We all have been fixed, I don't know if tarball have been rebuild from git master.

Gilles Caulier
Comment 16 Andreas K. Huettel 2011-09-11 20:59:19 UTC
> Anyway, seem solved downstream in gentoo with media-gfx/digikam-2.1.0-r2

Yeah... In Gentoo -r2 is now exactly the tag, not the tarball, so who goes from
2.0.0 to 2.1.0-r2 should be fine.

I just hope not too many people installed -r1 and used the database with it,
luckily it was only one day. Right now -r1 does not upgrade to -r2
automatically (I set this because of above crashes), but we have to figure out
what to do there...

Then, of course, I see in the cc list someone from fedora and in the comments
arch and ubuntu... :| Please please make a 2.1.1 ...
Comment 17 Francesco Riosa 2011-09-11 21:08:19 UTC
Gilles, then we should remove/deprecate the tarball on sourceforge ASAP, it's still downloadable and it's clearly broken, inside there is part of my patch plus other (random?) changes. I've checked this downloading it right 5 min. ago
Gentoo work because it revert by patch.

At a minimum we need the andreas patch:
http://vserver.13thfloor.at/Experimental/patch-3.0.4-vs2.3.1-pre10.1.diff
but some more check would not be too bad.
Comment 18 caulier.gilles 2011-09-11 21:14:12 UTC
Nicolas, is in copy here.

I waiting comments from him release 2.1.1 soon.

Gilles Caulier
Comment 19 Francesco Riosa 2011-09-11 21:44:38 UTC
One more note:
Since old database settings are not deleted, just copyed and splitted;
users which didn't changed database settings in the meantime should be safe.

Looking at the users messages and screenshots in digikam-users there are
various degrees of tainting, seem that different distro used different commits
for the 2.1.0 snapshot (at least one must have my full patch) those that cannot
start the first time after upgrade but that can work after the second launch
for example have the full patch.

Anyway I'll definitely wait more time to commit after a tag the next releases.

Nicolas, just to be sure, please none of my commits should slip into 2.1.1.
If some of the files is positive to the 'tmb[A-Z]' pattern, then it's tainted.
Comment 20 caulier.gilles 2011-09-12 07:38:46 UTC
Just to be clear :

If 2.1.1 release must be done, it safe to use current git master to do it ?

Gilles Caulier
Comment 21 Francesco Riosa 2011-09-12 09:27:04 UTC
(In reply to comment #20)
> Just to be clear :
> 
> If 2.1.1 release must be done, it safe to use current git master to do it ?
> 
> Gilles Caulier

No, we should revert, see also bug 281838, there are only two commit for splitted DB, one is mine, the other is from Marcel.
Comment 22 caulier.gilles 2011-09-12 09:31:07 UTC
Francesco,

So, what's the last commit ID to include in 2.1.1 tarball ?

Gilles
Comment 23 Francesco Riosa 2011-09-12 10:09:21 UTC
git clone -l ../digikam-sc/core/
git checkout v2.1.0

which give the exact tagged 2.1.0 version is fine for me, there are other changes in released tarballs, I cannot speak for those.

P.S. the link at c#17 is obviously a cut&paste error, it should be
http://dev.gentoo.org/~dilfridge/distfiles/digikam-2.1.0-tag.patch.bz2
Comment 24 caulier.gilles 2011-09-12 10:11:33 UTC
Thanks Francesco,

I sent a private mail in French to Nicolas (at Mandriva) about this entry. I hope that he will take a look soon...

Gilles
Comment 25 Andreas K. Huettel 2011-09-12 12:38:37 UTC
(In reply to comment #23)
> git checkout v2.1.0
(...)
> http://dev.gentoo.org/~dilfridge/distfiles/digikam-2.1.0-tag.patch.bz2

^ that's more or less just what I did to make the patch, yes. (I checked out the tag v2.1.0 of digikam.git, replaced the core directory in the tarball with the checkout, and then diffed against the original tarball.)
Comment 26 caulier.gilles 2011-09-12 14:42:00 UTC
I just recieve a response from Nicolas. He will rebuild tarball using 2.1.0 tag.

Gilles Caulier
Comment 27 kripton 2011-09-12 15:50:56 UTC
Hi, I'm a Gentoo-user that has digikam-2.1.0-r1 installed right now. I use a MySQL-database and I remember that I ran the version once and did not have any problems. Nevertheless I do not want to try again just for the sake of knowing it exactly.
What shall I do now? Unmerge and emerge the new version? Will my database work with 2.1.0-r2? Is there a Gentoo bug# for this problem?
Comment 28 Francesco Riosa 2011-09-12 16:32:55 UTC
(In reply to comment #27)
> Hi, I'm a Gentoo-user that has digikam-2.1.0-r1 installed right now. I use a
> MySQL-database and I remember that I ran the version once and did not have any
> problems. Nevertheless I do not want to try again just for the sake of knowing
> it exactly.
> What shall I do now? Unmerge and emerge the new version? Will my database work
> with 2.1.0-r2? Is there a Gentoo bug# for this problem?

Hi,
1st) to be on the safe side, please dump your databases with mysqldump
2nd) edit ~/.kde4/share/config/digikamrc, the section [Database Settings] should contain only the following:
[Database Settings]
Database Connectoptions=
Database Hostname=
Database Name=digikam
Database Name Thumbnails=digikam
Database Password=digikam
Database Port=0
Database Type=QMYSQL
Database Username=digikam

no Image* or Thumbnails*, if these are present remove them
also check that values in there are correct.

3rd) additionally if using different databases for "Database Name" and "Database Name Thumbnails" please consider merging the two in only one. There are know bugs that will be fixed in 2.2.0 when using mysql and differrent databases.

4th) emerge -C =digikam-2.1.0-r1 && emerge -a =digikam-2.1.0-r2

I'm installing digikam-2.1.0-r1 right now for an in depth look, will report here if other steps are required
Comment 29 kripton 2011-09-12 17:14:23 UTC
Thanks for the information. Database has been dumped while writing #27 here. Since I have the thumbnails and the other infos all in one database I'm confident there won't be much trouble.
However, I won't do anything until tomorrow when the situation has been cleared up further. Thanks for all you work :D
Comment 30 Francesco Riosa 2011-09-12 18:14:29 UTC
Steps in Comment #28 are confirmed and sufficient and - no data loss is involved -

small addition to 2rd): "Internal Database Server=false" should be kept (it's re-created but to be safe keep it)

and explanation: those settings will be used in future versions of digikam, if they are unset then DK will read the old settings and migrate to new config.

If instead the settings are present it will simply plain using it, then if the "old" settings have been changed by an "old" version of DK the changes will be lost, not inside the database, but DK will start a different database than the most recent one.
"old" digikam mean version < 2.2.0 with exclusion of 2.1.0-r1 (or whatever 2.1.0 your distro provided)

explanation for 3rd) is @ bug #277242

P.S.
Possibly there is a thumbnails db tainting your image db but should do no harm if not on the database size.
Comment 31 Nicolas L. 2011-09-14 07:59:42 UTC
Hello,

Please test this tarball (  http://kenobi.mandriva.com/~neoclust/digikam-2.1.1.tar.bz2  )  and tell me if it works OK.

If OK i will upload it on sourceforge.
Comment 32 Rinus Bakker 2011-09-14 08:28:26 UTC
Message read, I report back within 48 hours at max.
Op 14-09-11 09:59, Nicolas L. schreef:
> https://bugs.kde.org/show_bug.cgi?id=281767
>
>
>
>
>
> --- Comment #31 from Nicolas L.<neoclust kde free fr>   2011-09-14 07:59:42 ---
> Hello,
>
> Please test this tarball (
> http://kenobi.mandriva.com/~neoclust/digikam-2.1.1.tar.bz2  )  and tell me if
> it works OK.
>
> If OK i will upload it on sourceforge.
>
Comment 33 Will Stephenson 2011-09-14 09:00:17 UTC
Is the tarball mentioned in comment 31 still current?
Comment 34 Francesco Riosa 2011-09-14 09:21:10 UTC
work for me on gentoo

diff  digikam-2.1.0-r1.ebuild  digikam-2.1.1.ebuild
26c26
< KEYWORDS=""
---
> KEYWORDS="~amd64 ~x86"
41,42c41,42
<       >=media-libs/libkface-${PV}
<       >=media-libs/libkgeomap-${PV}
---
>       >=media-libs/libkface-2.1.0
>       >=media-libs/libkgeomap-2.1.0

cosmetical, for the next time, we should ignore the following files:

find . -name "*~"
./.gitslave~
./core/CMakeLists.txt~
./extra/kipi-plugins/CMakeLists.txt~
Comment 35 caulier.gilles 2011-09-14 09:24:55 UTC
@ Will #33 : it will become the new one, to fix older 2.1.0

Please compile, test, and report...

Gilles Caulier
Comment 36 caulier.gilles 2011-09-14 09:59:30 UTC
@Nicolas, #31 : tarball compile fine here...

Gilles Caulier
Comment 37 Andrea Scarpino 2011-09-14 10:17:36 UTC
Works here on Arch Linux.
+1 for release.
Comment 38 Rinus Bakker 2011-09-14 12:03:05 UTC
Op 14-09-11 09:59, Nicolas L. schreef:
> https://bugs.kde.org/show_bug.cgi?id=281767
>
>
>
>
>
> --- Comment #31 from Nicolas L.<neoclust kde free fr>   2011-09-14 07:59:42 ---
> Hello,
>
> Please test this tarball (
> http://kenobi.mandriva.com/~neoclust/digikam-2.1.1.tar.bz2  )  and tell me if
> it works OK.
>
> If OK i will upload it on sourceforge.
>
Can anyone tell me hoe to get the thing to download.


  Access forbidden!

You don't have permission to access the requested object. It is either 
read-protected or not readable by the server.

If you think this is a server error, please contact the webmaster 
<mailto:root@localhost>.


    Error 403

kenobi.mandriva.com <http://kenobi.mandriva.com/>


Apache/2.2.15 (Mandriva Linux/PREFORK-3.3mdv2010.2)

Rinus
Comment 39 Nicolas L. 2011-09-14 12:11:05 UTC
damn mandriva infrastructure, i put somewhere else now.
Comment 40 Nicolas L. 2011-09-14 12:23:39 UTC
you can take the tarball here now : ryu.zarb.org/~neoclust/digikam-2.1.1.tar.bz2

( this is the same tarball )
Comment 41 Nicolas L. 2011-09-14 16:14:42 UTC
seems good feedbacks, i will upload within one hour except if i have a bad feedback until this .
Comment 42 Rinus Bakker 2011-09-14 16:46:04 UTC
I would have prefered a little more extinsive testing, but as I see 
there is a little pressure.

My findings sofar.

I have ran several test on different setups. Two on fysical 32 and 64 
bit and two on virtual machines, all runnung Ubuntu 11.04 setups some 
with kde 4.6.2 and others Kde 4.7.0.

In all variaties nothing unusual or any suspicious behaviour detected.

All existing databases opened as expected. Done several database 
activities, followed by successful integrety check.

Several main activities tested, such as opening several formats in image 
editor, doing some Image manipulations, opening in batch cue manager, 
slideshow, lighttable etc etc.

from compilation to using all went well.

Rinus

Op 14-09-11 18:14, Nicolas L. schreef:
> https://bugs.kde.org/show_bug.cgi?id=281767
>
>
>
>
>
> --- Comment #41 from Nicolas L.<neoclust kde free fr>   2011-09-14 16:14:42 ---
> seems good feedbacks, i will upload within one hour except if i have a bad
> feedback until this .
>
Comment 43 Nicolas L. 2011-09-14 18:35:40 UTC
version 2.1.1 is now available on sourceforge.

thanks all for your tests.
Comment 44 Andreas K. Huettel 2011-09-18 19:59:51 UTC
(In reply to comment #28)

Hi Francesco, 

on the Gentoo [*] bug some users have been asking about the procedure as in comment #28 but for the sqlite backend- any clues?

Best, Andreas

[*] https://bugs.gentoo.org/show_bug.cgi?id=382617
Comment 45 Francesco Riosa 2011-09-19 09:19:18 UTC
> (In reply to comment #28)
> 
> Hi Francesco, 
> 
> on the Gentoo [*] bug some users have been asking about the procedure as in
> comment #28 but for the sqlite backend- any clues?
> 
> Best, Andreas
> 
> [*] https://bugs.gentoo.org/show_bug.cgi?id=382617

(In reply to comment #8)
> The instructions in the link that is provided unfortunately only apply to mysql
> databases.
> Could you please also explain the procedure for SQlite databases?
> Or is there no problem in this case?

For sqlite the procedure could be this:

1st) to be on the safe side, copy the digikam4.db thumbnails-digikam.db files (thumbnails-digikam.db can easily be recreated but on a large collection it take some time)

2nd) edit ~/.kde4/share/config/digikamrc, the section [Database Settings]
should contain only the following:
[Database Settings]
Database Connectoptions=
Database Hostname=
Database Name=/a/path/to/dir
Database Name Thumbnails=/a/path/to/dir
Database Password=
Database Port=0
Database Type=QSQLITE
Database Username=
Internal Database Server=false

no Image* or Thumbnails*, if these are present remove them
also check that values in there are correct.

3rd) N/A

4th) emerge -C =digikam-2.1.0-r1 && emerge -a '>=digikam-2.1.1'

Step 2) is not immediately needed but leaving the cruft there can create problems if and when we switch to this schema of config options.
(In reply to comment #44)