Symptom: ''''''''' The digikam 4.x settings window and the collection setup window at installation will freeze after apr. 3 seconds once a mariadb/mysql connection was setup successfully with latest mariadb and mysql libs (at least in OpenSuse 12.3 and 13.1. - dont know about other distros) Installed 64Bit Libraries: '''''''''''''''''''''''''' digikam 4.1.0-11.8 kipi-plugins 4.1.0-11.8 kipi-plugins-lang 4.1.0-11.8 libgkgeomap-lang 4.1.0-11.8 libkipi11 4.11.5-298.1 mariadb 5.5.33-2.2 mariadb-client 5.5.33-2.2 libmysql18 5.5.33-2.2 libmysqlclient18 5.5.33-2.2 libqt4-sql-mysql libmysqlcppconn 1.1.2-4.1.3 ibvsqlitepp 0.3.12-7.7 and more ... from Standard OpenSuse 13.1 Repositorys and from: http://download.opensuse.org/repositories/KDE:/Current/openSUSE_13.1/ http://download.opensuse.org/repositories/KDE:/Extra/KDE_Current_openSUSE_13.1/ http://download.opensuse.org/repositories/server:/database/openSUSE_13.1/ (only for ibvsqlitepp 0.3.12-7.7) Rating of the Bug: This bug is severe, because it blocks installation of digikam on top of a MySQl database. MySQL is a must for large asset collections - so digikam 4.* cannot be used for semiprofessional workflows (at least using OpenSuse). The installation is blocked, because the wizard opens the collections setup window once a mysql database was set up successfully. The collections setup window will freeze after apr. 3 seconds. If you are quick enough you can finish the setup - see 'workarounds" later on. Analysis: The freeze is not restricted to db settings and collections settings, any tab of the settings windows will freeze after 3 seconds, once mysql was set up successfully. There are workarounds to change settings without that windows - see below. ------------------------------------------------- Reproducable - see attachments: ------------------------------------------------- 1. Install OpenSuse 13.1 from online repository. ------------------------------------------------- The latest digikam 4.1.0 build right now ist 11.8 for KDE 4.13, but the bug blocks any 4.* release of digikam for OpenSuse. 2. Create user "benutzer1" in OpenSuse and login ------------------------------------------------- Copy some images to folder /home/benutzer1/. 3. Test setup files in attachment, create MysqlDB : ------------------------------------------------- a. settings-file "digikamrc_settingswork" ********************************************** These are default settings, with the sqlite db in /home/benutzer1/. Rename the file to "digikamrc" and copy it to /home/benutzer1/.kde4/share/ Start digikam and everything works fine. Check the "settings"-window: it does not freeze. b. settings-file "digikamrc_settingsdonotwork" ********************************************** This is exactly the same settings file - but the section [Database Settings] was replaced with a connection to a valid mysql database "digikamdb" for user "digikamuser" with password "**". A short description of mariadb/mysql setup is given below. Create the mysql db and user as described in the next section. Rename the file to "digikamrc" and copy it to /home/benutzer1/.kde4/share/ Start digikam and the freeze of the "settings"-windows will block your further installation when you are asked to define the filepath to the main collection. Note: If you receive database errors, the db was not set up in the right way - in this case the window might or might not freeze. The settings-window will also freeze when you setup the database settings and collections with the workarounds I will describe later on. You have to chance all settings in the "digikamrc"file using a text editor (not that bad ...) 4. Set up mariadb/mysql for the test: ------------------------------------------------- a. set mariadb/mysql root password - it is empty #Check if service is running: >systemctl status mysql.service # open mysql client on the console: >mysql --host=127.0.0.1 --user=root --port=3306 and type: use mysql;set password for root@localhost = password('rootpw'); flush privileges; b. change mariadb configuration for digikam before creating databases Adapt /etc/my.cnf BEFORE you create the databases for digikam: [mysqld] ... innodb_file_per_table=ON Find a line that reads "log_bin" and remove or comment it as follows: #log_bin = ... # binlog_format=mixed c. restart mysql db, check server status and open mysql console: >systemctl restart mysql.service >systemctl status mysql.service >mysql --host=127.0.0.1 --user=root --password=rootpw --port=3306 On the mysql prompt type: CREATE DATABASE digikamdb;GRANT ALL PRIVILEGES ON digikamdb.* TO 'digikamuser'@'localhost' IDENTIFIED BY '**'; FLUSH PRIVILEGES; GRANT SUPER ON *.* TO 'digikamuser'@'localhost'; FLUSH PRIVILEGES; ------------------------------------------------- 5. Workaround for this bug till there is a fix: ------------------------------------------------- This bug should not stop you working with digikam and mysql to manage a large collection of media assets (that would kill Adobe Lightroom.) After opening the window with digikam settings the digikam GUI will freeze under KDE 4.* within 3 seconds after a mysql connection was setup successfully. Without a valid mysql conncetion digikam settings window will NOT freeze. Workaround to set default collection: There is no freeze of the settings windows at the first start. Choose any folder with no images, because it will be changed again. Then open Settings Windows and Select "MySQL" in the database section. Workaround to set first mysql database settings and collection: Dialog will not freeze during database setup, it will freeze later on when the collection path is chosen: Set default path before you start digikam in ~/.kde4/share/config/digikamrc: change section "[KFileDialog Settings]" Recent URLs, Recent Files Then be quick, just press return to select this path. Workaround to add one ore more collections to the database: Use mysql console or workbench to add new rows in table 'AlbumRoots': USE digikamdb; INSERT INTO `AlbumRoots` (`id`,`label`,`status`,`type`,`identifier`,`specificPath`) VALUES (1,'multimedia_fotosdb1',0,1,'volumeid:?uuid=d3b29d62-d3d8-48ca-8499-b9631abeee11','/home/your_filepath1'); INSERT INTO `AlbumRoots` (`id`,`label`,`status`,`type`,`identifier`,`specificPath`) VALUES (2,'multimedia_fotosdb2',0,1,'volumeid:?uuid=5656c923-dab2-4ccd-b6bf-8590a23d9338','/home/your_filepath2'); Workaround: to change mysql database settings, edit section in ~/.kde4/share/config/digikamrc [Database Settings] Database Connectoptions= Database Hostname=localhost Database Name=digikamdb Database Name Thumbnails=digikamdb Database Password=** Database Port=3306 Database Type=QMYSQL Database Username=digikamuser Internal Database Server=false Workaround: to change other settings, edit the relate section in ~/.kde4/share/config/digikamrc Example for Color Profiles: ... [Color Management] BPCAlgorithm=true DefaultMismatchBehavior=1048576 DefaultMissingProfileBehavior=1048576 DefaultPath=/knowhow/consulting_framework/02_projects_local/08_ci_layout_design/0000_buitk_designvorgaben/farbmanagement_linux DefaultUncalibratedBehavior=1048576 DoGamutCheck=0 EnableCM=true GamutCheckMaskColor=126,255,255 InProfileFile[$e]=/usr/share/color/icc/Argyll/lab2lab.icm LastMismatchBehavior=2049 LastMissingProfileBehavior=2050 LastSpecifiedAssignProfile= LastSpecifiedInputProfile= LastUncalibratedBehavior=2080 ManagedPreviews=true ManagedView=true ProofingRenderingIntent=3 RenderingIntent=0 WorkProfileFile[$e]=/usr/share/color/icc/Adobe ICC Profiles/RGB Profiles/AdobeRGB1998.icc
Created attachment 87908 [details] after first setup open settings for "Database" - works
Created attachment 87909 [details] once mysql connection is available the setting windows freezes: eg. collection
Created attachment 87910 [details] bt for suse 13.1 with dk 4.1.0 build 11.1 - at the time the windows freezes
Created attachment 87911 [details] reproduce bug: working kde settings for digikam (no mysql db) rename this to digikamrc in your kde4 settings folder
Created attachment 87912 [details] reproduce bug: kde settings for digikam with mysql db: settings freeze rename this to digikamrc in your kde4 settings folder
I experience the exact same problems under debian testing. Since the upgrade to 4.1.0 came in, entering settings window causes freeze when using mysql. Using sqlite Database there is no such problem.
Same here, Debian Testing, digikam 4.1
Additional note: I used the setup digikam + mySQL for about a year now, on an older machine, also Debian Testing, and up to digikam 4.0 without this problem. Have there be changes to the mySQL support of digikam? (I just found out that there is a GSoC project planned for next summer.)
No. Nothing has changed about MySQL support. There is no code change since a while about this feature. Perhaps the distro switch from MySQL to MariaDB has introduced some side effects... Gilles Caulier
(In reply to Gilles Caulier from comment #9) .. > Perhaps the distro switch from MySQL to MariaDB has introduced some side > effects... > > Gilles Caulier Yes, I have similar experience with openSuse 11.x + digikam 3.2: there was no freeze. With openSuse 12.x + digikam 3.5 the freeze started (I did not recognize the bug that time. thought its just a crash). With openSuse 12.x mysql was replaced by mariadb. The maria db core is almost identical with mysql server. There were no issues in my java and php projects. Possible reasons: - It might be related to some specific queries that were optimized for old mysql tables or system tables. - Latest maria and mysql packages have different default settings compared to the ones a couple of years ago, e.g. inno-db tables (no isam), different tablespaces, worker and memory settings and improved security model. - mix of old qt4 libs and new mysql libs to access the db - hopefully it is not something like this I will invest a little time next week to log what is going on in the db before the freeze occurs. Christian
I also experience a freezing of the setting windows after some seconds on ubuntu, using the mysql database Application: digikam (4.2.0) KDE Platform Version: 4.13.3 Qt Version: 4.8.6 Operating System: Linux 3.13.0-34-generic x86_64 Distribution: Ubuntu 14.04.1 LTS
I also tried to reproduce the error on ubuntu with a fresh installation of digikam 4.2.0. After the installation the settings menu works. Then I create a mysql-database, and change the database settings to mysql. Then I open the settings menu, and get the freeze. Since I have mysql, no mariadb, the freeze seems not to be related to mariadb. Here my packages: digikam:amd64/trusty 4:4.2.0-trusty~ppa1 uptodate digikam-data:all/trusty 4:4.2.0-trusty~ppa1 uptodate libkface-data:all/trusty 1.0~digikam4.2.0-trusty~ppa1 uptodate libkface2:amd64/trusty 1.0~digikam4.2.0-trusty~ppa1 uptodate libkgeomap-data:all/trusty 1.0~digikam4.2.0-trusty~ppa1 uptodate libkgeomap1:amd64/trusty 1.0~digikam4.2.0-trusty~ppa1 uptodate libkvkontakte1:amd64/trusty 1.0~digikam4.2.0-trusty~ppa1 uptodate libmediawiki1:amd64/trusty 1.0~digikam4.2.0-trusty~ppa1 uptodate akonadi-backend-mysql:all/trusty-updates 1.12.1-0ubuntu1.1 uptodate libdbd-mysql-perl:amd64/trusty 4.025-1 uptodate libmysqlclient18:amd64/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate libqt4-sql-mysql:amd64/trusty 4:4.8.5+git192-g085f851+dfsg-2ubuntu4 uptodate mysql-client:all/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate mysql-client-5.5:amd64/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate mysql-client-core-5.5:amd64/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate mysql-common:all/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate mysql-server:all/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate mysql-server-5.5:amd64/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate mysql-server-core-5.5:amd64/trusty-security 5.5.38-0ubuntu0.14.04.1 uptodate php5-mysql:amd64/trusty-security 5.5.9+dfsg-1ubuntu4.3 uptodate
I hit this bug on Gentoo with MySQL 5.6.20 and digiKam 4.2.0. If there is a way I can help with debugging please ask.
Same here on Fedora 20. I haven't changed any settings lately so I cannot tell exactly with which version the issue came up. digikam-4.2.0-5.fc20.x86_64 digikam-doc-4.2.0-5.fc20.noarch digikam-libs-4.2.0-5.fc20.x86_64 mariadb-5.5.39-1.fc20.x86_64 mariadb-libs-5.5.39-1.fc20.x86_64 mariadb-server-5.5.39-1.fc20.x86_64
Seems the dbms doesn't even need to be available to freeze digikam. I stopped the mysql/mariadb daemon, started digikam, enterted the configuration dialog and it froze...
I don't have experience in the field but I tried to debug. Unfortunately almost no tool shows any information when the bug occurs. I build digikam with debug information and tried gdb, strace, ltrace, xsession-errors and to enable console debug output from kdedebugdialog. The only thing I could get was a ltrace. I started ltrace after digikam started using 100% CPU. I captured for 30 seconds. As you can see it kept one core busy for all these seconds. I don't know much about debugging, if there is something more I can do please ask. $ ltrace -c -p 1543 % time seconds usecs/call calls function ------ ----------- ----------- --------- -------------------- 25.07 14.428802 2932 4921 _ZN9KLineEdit7setTextERK7QString 13.49 7.765201 3156 2460 _ZN13KUrlRequester6setUrlERK4KUrl 13.35 7.686855 3123 2461 _ZN13KUrlRequester7setTextERK7QString 11.47 6.600541 191 34454 _ZNK9KLineEdit10metaObjectEv 5.19 2.988895 607 4922 _ZN6QTimer10singleShotEiP7QObjectPKc 5.07 2.917442 395 7383 _ZN7QObject5eventEP6QEvent 2.56 1.471184 199 7383 _ZNK11QMetaObject4castEP7QObject 2.46 1.414286 191 7383 _ZN4KUrlD1Ev 2.42 1.393034 188 7383 _ZN7QObject10childEventEP11QChildEvent 1.74 0.999831 203 4922 _ZNK13KUrlRequester3urlEv 1.64 0.942333 191 4922 memcpy 1.63 0.940316 191 4922 _ZN4QDirC1ERK7QString 1.63 0.939874 190 4922 _ZN4QDirD1Ev 1.63 0.939664 190 4922 _ZN7QWidget10setVisibleEb 1.63 0.937098 190 4922 _Z13qFlagLocationPKc 1.63 0.937079 190 4922 _ZN7QString4freeEPNS_4DataE 0.83 0.476242 193 2461 _ZN4QDir8homePathEv 0.83 0.475179 193 2461 _ZN4KUrlC1ERK7QString 0.82 0.474374 192 2461 _ZNK4KUrl11toLocalFileENS_16AdjustPathOptionE 0.82 0.473673 192 2461 _ZN4QDir20fromNativeSeparatorsERK7QString 0.82 0.473577 192 2461 _ZN4QDir14isRelativePathERK7QString 0.82 0.473350 192 2461 _ZNK13KUrlRequester4textEv 0.82 0.473245 192 2461 _ZN4QDir18toNativeSeparatorsERK7QString 0.82 0.471372 191 2461 _ZN7QStringC1EiN2Qt14InitializationE 0.82 0.470804 191 2461 _ZNK4KUrl4pathENS_16AdjustPathOptionE ------ ----------- ----------- --------- -------------------- 100.00 57.564251 135353 total strace during freeze just gave many lines likes this: brk(0xeedc000) = 0xeedc000 brk(0xeefd000) = 0xeefd000 brk(0xef1e000) = 0xef1e000 brk(0xef3f000) = 0xef3f000 brk(0xef60000) = 0xef60000 brk(0xef81000) = 0xef81000 brk(0xefa2000) = 0xefa2000 brk(0xefc3000) = 0xefc3000 brk(0xefe4000) = 0xefe4000
Confirming this with Digikam 4.3.0 under Xubuntu. After opening settings the Digikam process takes 100% cpu, as if stuck in infinite loop?
*** This bug has been confirmed by popular vote. ***
Yes, I can confirm this too in Debian sid, Digikam 4.3.0. I also tried to stop the MySQL daemon, but the configuration page still freezes even if the database is not reachable. I must say I am reliefed from finding this bug report, I thought my settings were messed in some way....
I can also confirm this bug: Fedora 20 digikam-libs-4.3.0-2.fc20.x86_64 digikam-4.3.0-2.fc20.x86_64 mariadb-devel-5.5.39-1.fc20.x86_64 mariadb-embedded-5.5.39-1.fc20.x86_64 mariadb-5.5.39-1.fc20.x86_64 mariadb-server-5.5.39-1.fc20.x86_64 mariadb-libs-5.5.39-1.fc20.x86_64
Following config also suffers from this bug: Linux Mint 17 / KDE digikam 4:4.3.0-trusty~ppa1 digikam-data 4:4.3.0-trusty~ppa1 kipi-plugins-common 4:4.3.0-trusty~ppa1 libkdcraw23 4:4.13.0-0ubuntu1 libkipi11 4:4.13.0-0ubuntu1 libkipi-data 4:4.13.0-0ubuntu1 kipi-plugins 4:4.3.0-trusty~ppa1 with the wokring MySQL database running on a QNAP NAS. When going to settings menu --> database migration, I experience exact the same behaviour, eg digikam eating 100% cpu after a few seconds, even when the DB connection is not available (and digikam correctly presents a error message during startup).
Created attachment 89156 [details] quick'n'dirty hack to prevent freeze when using mysql db backend
The reported freezing seems to be related to the delayed checking of the database file path which is unused for external DB server connections. Somehow that code runs amok and causes 100% load on one cpu core - I didn't have the time to investigate the real reason behind that behavior. In the attached patch I've just moved both connect() calls of that file path input field to a "later" code position and made it conditional based on type of DB backend.
Sorry but how to you add such patch ? Really missing MYSQL with Digikam.
(In reply to fsalvert@gmail.com from comment #24) > Sorry but how to you add such patch ? Really missing MYSQL with Digikam. ...uuuhm - I just hope we talk about the same thing here: that patch is only "useful" if you have the digikam source code at hand and know how to (re-)build it from scratch. My assumption is, that if you know how to compile the source tree, you should also know how to apply patch files to your working copy - sorry, but it's not a "end-user-friendly" solution to the problem ;)
Tom, you guessed me right. I'm not building Digikam from source and was hoping this would be easier to apply. Hope they incorporate your patch to rpms or I might just learn how to build from source :-)
Git commit f0400ec7e518e753e0c4ccab4eb2b8b022f91767 by Gilles Caulier. Committed on 28/10/2014 at 14:58. Pushed by cgilles into branch 'master'. apply patch #89156 FIXED-IN: 4.5.0 M +2 -1 NEWS M +19 -16 libs/widgets/common/databasewidget.cpp http://commits.kde.org/digikam/f0400ec7e518e753e0c4ccab4eb2b8b022f91767
Thank you for fixing this bug. I will try the patch as soon as possible :) @fsalvert: if you are using some pacakge-based distribution, you may try to look at guides for creating patched packages. Something exists for debian, for example. It may be easier than rebuilding all from source, but still some advanced knowledge and skills are required.
Thank you Gillles for you patch. I'am using fedora 20, 64 bits version. I have downloaded 4.4.0 digikam version from fedora updates repository. I have only replaced databasewidget.cpp by new version and recreated a new rpm with 'rpmbuild -ba' I can now use Digikam 4.4.0 configuration to add a new collection. Before , after each "yum update" , I was replacing current digikam version with 3.5.0 version from fedora releases repository.
Jean-Pierre, can you post your final rpm ? Will try it out on openSuse. Thanks
Created attachment 89378 [details] digikam-libs It's named 4.4.2-9 to be sure that next version from fedora without that patch will not remove my version but, in fact it is the 4.4.0 with Gilles caulier patch.
Thanks...openSuse does not seem to use this package digikam-libs normally. Will try it anyways and see if it works :-)
I do'nt have checked where the patch goes. but you need 2 packages in fedora: digikam and digikam-libs , but the package digikam is too big to be posted directly here. I can provide access to my ftp server, if you want to have acces to anything generated.
Hi, Just to post out there that SQL is fixed in openSuse with Digikam version 4.4.0-28.1. Great ! Thanks
I can confirm that the patch works on digikam 4.4. I tried it on the current Debian sid version, which is 4.4.0-1. I created patched debian packages for me, but maybe they can be useful to someone else (only amd64 architecture): https://www.dropbox.com/sh/xo6vshks7ehtvzi/AAANiZxu2TtK8fz3_UyZyp_wa?dl=0