NOT just another slow startup bug, I hope.
I have a Fedora server serving about 20K pics over smb/cifs and hosting a MySQL server for the digikam databse.
I have two clients, one XP and one linux. (I edited the AlbumsRoot table in the database with the "&" trick:
to inlcude both the linux and windows mount path so that both machines can use the same database, and that works!! Yay.)
The xp client was setup with the 2.5 windows digikam installer. With or without scan at startup selected, it starts SLOW. (maybe slower with than without, not sure) It takes many minutes, probably about 8, during "scanning database".
I monitor with atop on the server. Myslqd runs for one atop refresh with some I/O and then calms back down to 0 I/O and 0 CPU.
smbd though runs the whole time at high cpu load , but reading and writing only small amounts of data (like 8K per 5 sec. refresh usually), so maybe scanning file trees? Mysqld is doing relatively little.
The networking is gigabit but limited by hardware to about 20 to 30 MBytes/s, not exactly turtle slow.
Now I have a second linux client accessing the exact same database also using digikam 2.5.
On the linux box digikam starts up in a couple of seconds even with scan images on startup selected. I see the initial burst of database activity on atop, and that's it... then it's started.
This makes digikam on xp unusable, especially considering it crashes from time to time.
Also when adding a new local collection on the XP machine, a scan was started, with similar behavior and a similar delay.
verified in 2.6 on windows 7 on a new PC.
I changed importance to major, because as far as I care, for windows use, this is a show stopper for me. The only way I can make use of the windows version is as a client to a shared database. So it's major for me at least.
Verfied now in Windows 7 running digikam 2.9.
Symptoms still exactly the same. Startup stalls while displaying "reading database". mysql runs briefly on the server and then it's jammed up with smbd access for a very long time. To re-iterate, all files are already scanned into the database and the linux client starts up very quickly as expected. It can even be started up quickly while the windows client is busy starting up. Spending a ton of time for file access makes no sense.
One other funny, probably unrelated issue is that I get a dialog about locale changing from "System" (for windows) to "UTF-8" for linux. I hit ok.. and it doesn't seem to cause trouble.
And using 3.0.0-RC for windows ?
I'll try but just hoping it happens to work some day seems, well, not hopeful. Is there a reason to think it might be fixed?
Anyway, I will try. I missed that there is a 3.0.0 windows version. I'll report back in a day or so, out of time at the moment.
Bug is present in 3.0.0-RC for windows.
Any type of filtering (tags or date) also takes a long time, not quite as long, but a minute or two. I don't recall if this was true on the earlier versions. I never used them much given the the problems reported. When I get a chance I might try to increase logging levels on MySQL and smbd on the server to see if I can interpret anything interesting from them.
(In reply to comment #7)
> Any type of filtering (tags or date) also takes a long time, not quite as
> long, but a minute or two. I don't recall if this was true on the earlier
> versions. I never used them much given the the problems reported. When I
> get a chance I might try to increase logging levels on MySQL and smbd on the
> server to see if I can interpret anything interesting from them.
Could you try the just release 3.1.0 and let me know if this still happens? Nothing was changed on the DB side of things (well, nothing in digiKam, the build has a new version of mysql client), but we now have a new hardware interface which is much faster. It might speed up your setup. Also, some changes were made to how folders are observed which may also speed up your time:
Using 3.4.0 now on both linux and windows client. The database server hardware is updated as is the OS and mysqd version. For whatever reason it seems working pretty well now. WIth sufficiently modern version of everything involved this seems resolved.