The wait occurs between lines 395 and 396

00000393	16.04066658	[7048] digikam.general: Finish Main Thread	
00000394	16.04195786	[7048] digikam.general: Finish Main Thread	
00000395	16.04323387	[7048] digikam.general: Finish Main Thread	
00000396	101.44808960	[7048] digikam.general: One job is done	
00000397	101.45188141	[7048] digikam.general: Finish Main Thread	
00000398	101.57834625	[7048] digikam.general: Finish Main Thread	
00000399	102.62887573	[7048] digikam.general: scan mode: ScanDeferredFiles	
00000400	103.17636108	[7048] digikam.general: total scan value :  204674	
00000401	103.24131775	[7048] digikam.general: total scan value :  215858	

Around 80 seconds, probably due to scan process

Created attachment 163745 [details]
digiKam 8.2.0 start and 8.3.0 start in one video (only 2 min 14 sec)

Maik,

I can see in you video that the collections are huge.

It's possible that albums/tags search completer need to be populated at startup with GUI blocking.
If yes, the Q is why it's blocking under windows ? Here under Linux my collections are giant and i cannot reproduce the problem...

Another possibility is the Marble blank dialog visible at startup when one geo-location tab is visible in the GUI.

Peter, please hide the geo-location view in digiKam, close and restart to see if the time latency still present...

Gilles Caulier

"hide the geo-location view in digiKam"
Maik, please: where do i find this setting?

Configure digikam -- Views -- Icons -- Show geolocation indicator (I have it is disabled)

I tryed:
I disabled the "Scan for new items at startup" function in the Settings -- Miscellaneous -- Behaviour.
Result: A blank white window for long minutes (maybe "Marble blank dialog").
After 2 minutes it disappeared and digiKam started.

Created attachment 163754 [details]
Marble dialog

(In reply to Peter from comment #6)
> I tryed:
> I disabled the "Scan for new items at startup" function in the Settings --
> Miscellaneous -- Behaviour.
> Result: A blank white window for long minutes (maybe "Marble blank dialog").
> After 2 minutes it disappeared and digiKam started.

Settings -- Configure digiKam...
I enabled the "Scan for new items at startup" function in the Settings -- Miscellaneous -- Behaviour.
Result: A blank white window for long minutes (maybe "Marble blank dialog").
After 2 minutes it disappeared and digiKam worked.

OK, now again:

Settings -- Configure digiKam...
Result: A blank white window for long minutes (window titlebar: Configure digiKam).
After 2 minutes  the contents of the settings panel appeared

In fact, this will also do it:
Setting -- Configure digiKam -- OK
...and again
Setting -- Configure digiKam

Result: digiKam waits for minutes, the "Configure digiKam" window is blank and white.

Peter,

The blank dialog problem from Marble is know:

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

I already tried to fix this in Marble code (that i ported to Qt6), but dialog still here.

To hide geolocation view, there is no settings. Just change the active tab from right and left sidebar. On the left you have the map search, and on the right the map view. Just change the current active tabs at left and right side and restart digiKam.

Gilles Caulier

(In reply to caulier.gilles from comment #10)
> Peter,
> 
> The blank dialog problem from Marble is know:
> 
> https://bugs.kde.org/show_bug.cgi?id=452185
> 
> I already tried to fix this in Marble code (that i ported to Qt6), but
> dialog still here.
> 
> To hide geolocation view, there is no settings. Just change the active tab
> from right and left sidebar. On the left you have the map search, and on the
> right the map view. Just change the current active tabs at left and right
> side and restart digiKam.
> 
> Gilles Caulier

-- I did it. I hide geolocation view (I never use these anyway)
-- Close digiKam
-- Restart digiKam
Unfortunately, it didn't solve the problem

"The blank dialog problem from Marble is know:"
Ok. In this case, this error ticket can be closed.
I'm sorry if I wasted your time, but thanks for addressing the issue!

>-- I did it. I hide geolocation view (I never use these anyway)
>-- Close digiKam
>-- Restart digiKam
>Unfortunately, it didn't solve the problem

>"The blank dialog problem from Marble is know:"
>Ok. In this case, this error ticket can be closed.
>I'm sorry if I wasted your time, but thanks for addressing the issue!

Sorry i don't understand which ticket can be closed ? The problem is not solved at all as i can see...

Gilles Caulier

I thought this ticket (477853) was a duplicate, that's why I wrote that it can be closed.

But it's not a duplicate, as the origin of the time latency at startup is not clearly identified.
As you have already write in this file, the Marble blank dialog is not the really problem. 

Gilles Caulier

Git commit c4f76622403f36f0543b2d6ca7996354eb45e98a by Maik Qualmann.
Committed on 03/12/2023 at 10:29.
Pushed by mqualmann into branch 'master'.

more test debug output for ActionThreadBase

M  +4    -4    core/libs/threads/actionthreadbase.cpp

https://invent.kde.org/graphics/digikam/-/commit/c4f76622403f36f0543b2d6ca7996354eb45e98a

Peter, 

The 8.3.0 pre-release installer is updated online with the last changes from Mail to add more debug trace in debugview at startup.

Please install file and report: https://files.kde.org/digikam/

Best
Gilles caulier

Maik, 

For info in the "legacy" sub directory, i upload the cross-compiled version of pre-release of digiKam, if we needs to compare with the native version:

https://files.kde.org/digikam/legacy/

Gilles

(In reply to caulier.gilles from comment #16)
> Peter, 
> 
> The 8.3.0 pre-release installer is updated online with the last changes from
> Mail to add more debug trace in debugview at startup.
> 
> Please install file and report: https://files.kde.org/digikam/
> 
> Best
> Gilles caulier

Hi Gilles,
New log file is uploaded
Regards,
Peter

Created attachment 163811 [details]
2023.12.03. DebugLog

Created attachment 163812 [details]
This log was created while digiKam was running when I clicked on the Configure digiKam menu item.

Git commit 11883c4309073cd7f0236b58453b60dcc3e45dd0 by Maik Qualmann.
Committed on 03/12/2023 at 13:48.
Pushed by mqualmann into branch 'master'.

reset a commit to the refresh timers

M  +8    -2    core/libs/album/manager/albummanager_album.cpp
M  +13   -3    core/libs/album/manager/albummanager_collection.cpp
M  +4    -1    core/libs/album/manager/albummanager_salbum.cpp
M  +8    -2    core/libs/album/manager/albummanager_talbum.cpp

https://invent.kde.org/graphics/digikam/-/commit/11883c4309073cd7f0236b58453b60dcc3e45dd0

It's also far slower than 8.1.0 when assigning geolocations - presumably also a database operation

I don't know how important this information is...
-- The newly released 8.2.0 also contains this bug
-- Versions of 8.2.0 released at the beginning of November (weekly snapshots) did not yet contain this bug

The new digiKam-8.2.0 version is based on Qt6 and is created with the Microsoft compiler. Test the current digiKam-8.2.0 version, which was created as before:

https://download.kde.org/stable/digikam/8.2.0/digiKam-8.2.0-Qt5-Win64.exe

Does this version run normally again for you?

Maik

Created attachment 163896 [details]
attachment-1354632-0.html

Yes, it's fine

On Tue, 5 Dec 2023 at 08:43, Maik Qualmann <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=477853
>
> Maik Qualmann <metzpinguin@gmail.com> changed:
>
>            What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                  CC|                            |metzpinguin@gmail.com
>
> --- Comment #24 from Maik Qualmann <metzpinguin@gmail.com> ---
> The new digiKam-8.2.0 version is based on Qt6 and is created with the
> Microsoft
> compiler. Test the current digiKam-8.2.0 version, which was created as
> before:
>
> https://download.kde.org/stable/digikam/8.2.0/digiKam-8.2.0-Qt5-Win64.exe
>
> Does this version run normally again for you?
>
> Maik
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

Please compare it again with this current version:

https://files.kde.org/digikam/digiKam-8.3.0-20231205T055434-Win64.exe

Maik

> Does this version run normally again for you?

Yes! This works very well!

(In reply to Maik Qualmann from comment #26)
> Please compare it again with this current version:
> 
> https://files.kde.org/digikam/digiKam-8.3.0-20231205T055434-Win64.exe
> 
> Maik

Unfortunately, there is no change in this. It starts very slowly.

Additional information:
Settings -- Configure digikam... -- OK
and again
Settings -- Configure digikam... -- (After a very long wait, the contents of the window appear.)

*** Bug 478075 has been marked as a duplicate of this bug. ***

*** Bug 478131 has been marked as a duplicate of this bug. ***

As a note to everyone for whom our current digiKam version, created with Qt6 and  Microsoft Komplier, is too slow, here is a version that was created as before:

https://download.kde.org/stable/digikam/8.2.0/digiKam-8.2.0-Qt5-Win64.exe

I have now tested both versions here with all database backends on a Windows 10 machine. At the moment "only" with a collection of 50,000 images but with a lot of albums. But I have no difference when starting, performing database operations or opening the configuration settings.

I therefore suspect that it may be related to runtime libraries that users have previously installed. I therefore ask you to install/update the "Visual C++ Redistributable for Visual Studio 2015".

Maik

>I therefore suspect that it may be related to runtime libraries that users have previously installed. I therefore ask you to install/update the "Visual C++ Redistributable for Visual Studio 2015".

Hi Maik,

Why the MSVC 2015 ? digiKam is currently compiled with MSVC 2022. When i bundle the installer i plug the redistributable dll from the MSVC installed from my computer of course:

https://invent.kde.org/graphics/digikam/-/blob/master/project/bundles/vcpkg/04-build-installer.sh?ref_type=heads#L305

I miss something here ?

I also installed the current 8.3.0 on my Windows 10 computer in my office where no MSVC is installed, and it work properly. The MXE installer was installed before also and have been uninstalled when updating the application.

Gilles

Another point about redistributable Dlls from M$ (that i never understand why these files are not included as well in Windows update) is the performance and architecture support:

- arm | intel
- single thread | multithreads (openmp)

In digiKam, i put the intel/multithreads versions only.

Gilles

MSVC redistributable notice :

https://learn.microsoft.com/en-us/cpp/windows/redistributing-visual-cpp-files?view=msvc-170

Gilles

This is the list of redistributable dlls :

https://learn.microsoft.com/en-us/cpp/windows/determining-which-dlls-to-redistribute?view=msvc-170

Included in digiKam bundle are Intel 64 bits files with non debug symbols:

- vcomp140.dll (missing in 8.2.0, included in 8.3.0)
- vcruntime140.dll + vcruntime140_1.dll
- msvcp140.dll + msvcp140_1.dll + msvcp140_2.dll + msvcp140_atomic_wait.dll + msvcp140_codecvt_ids.dll
- concrt140.dll 

Do i need to put more files in the bundle ?

Gilles

Hmm, why 2015 good question, it's the version, if I see it correctly, that also applies to 2022.
I think that our DLLs in the digiKam path will not be used if they are already installed in the system. So we would probably have to change the library search path. I know from other Windows software that they include the Microsoft DLL installer and run it beforehand.

But this may not be the reason why the digiKam version is so slow for some users. And there is another reason...

Maik

By experience, the dlls search path priority under Windows is local application path first and after system path. This allows to mix different versions of dlls without conflict.

Gilles

Afterwards, the application path is only in the 7th position, but before the system directory.

https://learn.microsoft.com/en-us/windows/win32/dlls/dynamic-link-library-search-order

Maik

(In reply to Maik Qualmann from comment #31)
> As a note to everyone for whom our current digiKam version, created with Qt6
> and  Microsoft Komplier, is too slow, here is a version that was created as
> before:
> 
> https://download.kde.org/stable/digikam/8.2.0/digiKam-8.2.0-Qt5-Win64.exe
> 
> I have now tested both versions here with all database backends on a Windows
> 10 machine. At the moment "only" with a collection of 50,000 images but with
> a lot of albums. But I have no difference when starting, performing database
> operations or opening the configuration settings.
> 
> I therefore suspect that it may be related to runtime libraries that users
> have previously installed. I therefore ask you to install/update the "Visual
> C++ Redistributable for Visual Studio 2015".
> 
> Maik

Hi Maik.
I installed Visual C++ Redistributable for Visual Studio a new version (14.38.33130).
Unfortunately, it didn't solve the problem.

Created attachment 163935 [details]
Versions currently available in Windows

Hi,

I'm not sure if it is the same issue but I have a lot of time latency with the" Digikam not responding" message since I installed Digikam 8.3.0, not at startup but when I use Digikam.

(In reply to nonobio from comment #41)
> Hi,
> 
> I'm not sure if it is the same issue but I have a lot of time latency with
> the" Digikam not responding" message since I installed Digikam 8.3.0, not at
> startup but when I use Digikam.

The problem occurs in different ways. I mentioned the Configure window earlier.

The Configure Digikam window seems to open fine for me.

(In reply to Maik Qualmann from comment #26)
> Please compare it again with this current version:
> 
> https://files.kde.org/digikam/digiKam-8.3.0-20231205T055434-Win64.exe
> 
> Maik

Hi Maik,
I downloaded digiKam-8.3.0-Qt5-20231207T072634-Win64.exe version from https://files.kde.org/digikam/legacy/
This works fine for me!

*** Bug 478373 has been marked as a duplicate of this bug. ***

*** Bug 478396 has been marked as a duplicate of this bug. ***

MAik,

With Qt6, under Linux, i can reproduce a time latency at startup. It's happen when QtAV try to init the audio output on the system.

Typically, We don't needs QtAV at all with Qt6, even if videoslideshow is the last part using few QtAV API. This last one must be ported to another solution, as a direct ffmpeg API calls, or the ffmpeg CLI tool, or future QtMultimedia API (not existing in Qt6, but present in Qt5...)

Gilles

When I look at the DebugVew logs, it seems to be something related to the DatesJob. There are these bug reports and slow QDateTime comparisons. 
Note the post from KPhotAlbum:

https://bugreports.qt.io/browse/QTBUG-75585
https://bugreports.qt.io/browse/QTBUG-41714

Maik

Hi Peter,

Today i made an important change in the Windows native version based on Qt6. I dropped the internal legacy video player based on QtAV framework.

I would to know if the current 8.3.0 Windows pre-release installer improve the situation about this report.

Thanks in advance.

Best

Gilles Caulier

(In reply to caulier.gilles from comment #49)
> Hi Peter,
> 
> Today i made an important change in the Windows native version based on Qt6.
> I dropped the internal legacy video player based on QtAV framework.
> 
> I would to know if the current 8.3.0 Windows pre-release installer improve
> the situation about this report.
> 
> Thanks in advance.
> 
> Best
> 
> Gilles Caulier

Hi Gilles,

I tested digiKam-8.3.0-20231213T161333-Win64.exe
Unfortunately, this version also starts slowly. The problem was not solved for me.
If this version doesn't include the fix (dropped QtAV framework), I'll test again later.

I took a screenshot in process explorer while my digiKam is not responding.
digikam seems to closing Qt6Core threads. When you're done, digiKam will start working again.

Maybe this info will help...

Created attachment 164149 [details]
Qt6Core.dll

(In reply to Peter from comment #52)
> Created attachment 164149 [details]
> Qt6Core.dll

Here is a video of the entire start process in process explorer
https://youtu.be/ocgNrsmGUiw

(In reply to Peter from comment #53)
> (In reply to Peter from comment #52)
> > Created attachment 164149 [details]
> > Qt6Core.dll
> 
> Here is a video of the entire start process in process explorer
> https://youtu.be/ocgNrsmGUiw

But the Crash status of Qt6WebEngineCore.dll might be interesting...

Maik,

Currently the Qt version used by digiKam through VCPKG under Windows is the 6.6.0. The last 6.6.1 is out in VCPKG. Perhaps this can fix the problem.

Another improvement can be the massive update of all KDE 6 frameworks.

Both requires to recompile all from scratch on my Win10 VM of course....

Gilles

@Gilles, can you please create a new Windows bundle, I want to exclude the DatesJob or not.

@Peter, as a test you can sort your albums and items by name/path instead of by date. Does it make a difference?

https://invent.kde.org/graphics/digikam/-/commit/d5c951e7791873832f2f2b9d748c94036c152c3c

Maik

Maik, sure this evening I think

Git commit 13b7cb786389e7ac05fc86533f7b498ed335b05e by Maik Qualmann.
Committed on 14/12/2023 at 20:52.
Pushed by mqualmann into branch 'master'.

add a timer to each Action Thread job

M  +9    -5    core/libs/threads/actionthreadbase.cpp
M  +5    -0    core/libs/threads/actionthreadbase.h

https://invent.kde.org/graphics/digikam/-/commit/13b7cb786389e7ac05fc86533f7b498ed335b05e

Maik,

New Windows bundle is online

Gilles

(In reply to Maik Qualmann from comment #56)
> @Gilles, can you please create a new Windows bundle, I want to exclude the
> DatesJob or not.
> 
> @Peter, as a test you can sort your albums and items by name/path instead of
> by date. Does it make a difference?
> 
> https://invent.kde.org/graphics/digikam/-/commit/
> d5c951e7791873832f2f2b9d748c94036c152c3c
> 
> Maik

Hi Maik,
Tested in digiKam-8.3.0-20231214T211706-Win64.exe
Unfortunately it doesn't work for me (tested on two Windows 10 pro 22H2)

Settings:
View -- Sort Albums -- By Folder
View -- Sort Items -- By Name

The commit doesn't fix the problem either. He adds timers to try to identify which process is causing the slowdown. So now I need a new DebugView Log where the problem occurs.

Maik

Maik,

Depending of the next debugview results and the my free time while this week end, i will plan this week end a major update of the Win10 VM to rebuild VCPKG from scratch. This will include a bump of Qt6.6.0 to 6.6.1 and all KF6 components.

Let's me hears if it can be a good time for this.

Gilles

(In reply to caulier.gilles from comment #62)
> Maik,
> 
> Depending of the next debugview results and the my free time while this week
> end, i will plan this week end a major update of the Win10 VM to rebuild
> VCPKG from scratch. This will include a bump of Qt6.6.0 to 6.6.1 and all KF6
> components.
> 
> Let's me hears if it can be a good time for this.
> 
> Gilles

Yes, I will have time to test.

Created attachment 164178 [details]
20231215_debugview_log

Created attachment 164179 [details]
A log the after "configure digiKam..." opening/closing/opening

Created attachment 164180 [details]
A log the after "configure digiKam..." opening/closing/opening

(In reply to Peter from comment #65)
> Created attachment 164179 [details]
> A log the after "configure digiKam..." opening/closing/opening

Oops, the first 'A log the after "configure digiKam..." opening/closing/opening' is the same as 20231215_debugview_log (sorry)

I think this confirms my suspicion.
About 9 seconds to collect the date information and count. This still happens in the JobThread. But 95 seconds to create the date map in the GuiThread is extreme (AlbumManager::slotDatesJobData).
Qt recommends using UTC if a lot of QDateTime comparisons are necessary, the problem arises from converting time zones and daylight saving time etc. Maybe we can also move something to the JobThread.

00000501	19.40586090	[6100] digikam.general: Dates DB Job time: 8830	
00000502	105.08583832	[6100] digikam.general: Dates create time: 94511	
00000503	105.12340546	[6100] digikam.general: One job is done Digikam::DatesJob(0x22a4c3b10f0) time: 94543

Maik

I think we can solve the biggest timing problem if we disable sorting while adding date items to the date list view. So that the list view is not sorted again every time an item is added.

Maik

But one Q is : why this time latency do not appears in Qt5 version ?

Gilles

(In reply to caulier.gilles from comment #62)
> Maik,
> 
> Depending of the next debugview results and the my free time while this week
> end, i will plan this week end a major update of the Win10 VM to rebuild
> VCPKG from scratch. This will include a bump of Qt6.6.0 to 6.6.1 and all KF6
> components.
> 
> Let's me hears if it can be a good time for this.
> 
> Gilles

HI Gilles,
Were you able to solve this over the weekend?

Regards,
Peter

@Peter, do you have a “full” trash with lots of files in your collections?

Maik

(In reply to Maik Qualmann from comment #72)
> @Peter, do you have a “full” trash with lots of files in your collections?
> 
> Maik

Yes!

>> Maik,
>> 
>> Depending of the next debugview results and the my free time while this week
>> end, i will plan this week end a major update of the Win10 VM to rebuild
>> VCPKG from scratch. This will include a bump of Qt6.6.0 to 6.6.1 and all KF6
>> components.
>> 
>> Let's me hears if it can be a good time for this.
>> 
>> Gilles

>HI Gilles,
>Were you able to solve this over the weekend?

Hi Peter,

There is no problem here, just a possibility to update internal framework to last version, in case of... As Maik apply some fixes to digiKam codes, i will delay this task probably while Christmas holiday...

Gilles

(In reply to Peter from comment #73)
> (In reply to Maik Qualmann from comment #72)
> > @Peter, do you have a “full” trash with lots of files in your collections?
> > 
> > Maik
> 
> Yes!

The collection is owned by a small museum. The collection is currently being cleaned, so I rarely empty the bin.
Current bin sizes (two collections): 73GB and 365GB

For the trash problem, check for bug 478722.
Before you delete the trash, wait for the next digiKam test version.
A test here shows a slowdown of 1.3 seconds when calculating the size of the trash with my slow network collection, even with 700 files in the trash. And the calculation is called in the QTreeView model with every refresh.

Maik

Git commit f637ec4c07185389b18872150511f55b3ba7e389 by Maik Qualmann.
Committed on 24/12/2023 at 08:00.
Pushed by mqualmann into branch 'master'.

for a test force raster widgets

M  +6    -0    core/app/main/main.cpp

https://invent.kde.org/graphics/digikam/-/commit/f637ec4c07185389b18872150511f55b3ba7e389

Note : digiKam 8.3.0 pre-release Windows installer updated at usual place with last Maik changes and ready for testing...

Created attachment 164419 [details]
digiKam-8.3.0-20231224T080451-Win64.exe

Tested: digiKam-8.3.0-20231224T080451-Win64.exe
Unfortunately, the situation is not better. :-(
Log attached.

What surprises me about your logs is that you have activated the initial scan:

 16.33045959   [7800] digikam.general: scan mode: ScanDeferredFiles	
 18.13652802   [7800] digikam.general: total scan value :  202908	
102.61582184  [7800] digikam.general: total scan value :  214066

But the debug output never shows how long the initial scan took. Do you close digiKam before the initial scan is finished, or do we have a problem here?

Maik

(In reply to Maik Qualmann from comment #80)
> What surprises me about your logs is that you have activated the initial
> scan:
> 
>  16.33045959   [7800] digikam.general: scan mode: ScanDeferredFiles	
>  18.13652802   [7800] digikam.general: total scan value :  202908	
> 102.61582184  [7800] digikam.general: total scan value :  214066
> 
> But the debug output never shows how long the initial scan took. Do you
> close digiKam before the initial scan is finished, or do we have a problem
> here?
> 
> Maik

I stopped the scan after the digiKam became accessible. I'm making a new test.

Created attachment 164420 [details]
"Find new items" is completed

Created attachment 164421 [details]
I disabled the "Find new items" and restarted digiKam.

Created attachment 164422 [details]
A log on the same computer, in digiKam 8.2.

I'm sure this Qt bug is the cause as it only affects Windows. What time zone do you live in?

https://bugreports.qt.io/browse/QTBUG-120285

Maik

(In reply to Maik Qualmann from comment #85)
> I'm sure this Qt bug is the cause as it only affects Windows. What time zone
> do you live in?
> 
> https://bugreports.qt.io/browse/QTBUG-120285
> 
> Maik

I live in Central European Time (Hungary)

Maik,

Even if the Qt bug is not yet fixed in 6.6.1, perhaps it's the good moment to rebuild the VCPKG installation on my Windows 10 VM ? This will update Qt to 6.6.1 and KDE frameworks. What do you think about ?

Note : Qt 6.6.2 is planed in January :

https://wiki.qt.io/Qt_6.6_Release

Gilles

Gilles,

I think not much will change at the moment when switching to Qt-6.6.1 and the current KF6.
I suspect it will take hours to compile, if you have the time feel free to do so.

But I'm afraid that the bug won't be fixed in Qt-6.6.2 either. We may have to switch completely to UTC internally.

Maik

Hi Maik,

First, have an happy Christmas time with your family.

Here with my i9 32 cores + 64 Gb, it take 4 hours. QtWebEngine is the most consuming part to build. with MSVC, 2 hours to build the no debug, and 2 other ones to build the debug. MSVC build both separately, it's different than Linux G++ which mix debug symbols in same targets.

Note : QtWebEngine requires at least 24Gb for 8 cores. It's exponential: 12 cores 32Gb, 16 cores 48Gb, 20 cores 64Gb. So i let 8 cores to prevent broken compilations due to lack of RAM. Funny...

Ok i will stay with Qt 6.0.0 for the moment, to be able to quickly provides a new version if you switch DB time to UTC.

Gilles.

Git commit 19be2e0a54364bc5bf23a446e1f84bc0d187fa22 by Maik Qualmann.
Committed on 25/12/2023 at 09:35.
Pushed by mqualmann into branch 'master'.

for a test use UTC for the DatesJob

M  +1    -1    core/libs/database/dbjobs/dbjob.cpp

https://invent.kde.org/graphics/digikam/-/commit/19be2e0a54364bc5bf23a446e1f84bc0d187fa22

*** Bug 478988 has been marked as a duplicate of this bug. ***

Peter, 

The new 8.3.0 Windows installer is updated at usual place.

Have an happy Christmas time.

Gilles Caulier

(In reply to caulier.gilles from comment #92)
> Peter, 
> 
> The new 8.3.0 Windows installer is updated at usual place.
> 
> Have an happy Christmas time.
> 
> Gilles Caulier

Thanks Gilles,
I'll test it right away.
Merry Christmas and all the best!

Excellent work! digiKam is now working fast again!

Thank You Maik and Gilles!

@Peter, can you post a debug log to see how the DatesJob time changes?
This is also just a test, the date display may differ in the Dates View depending on whether the UTC date <-> local date falls on a different day.

Maik

Created attachment 164438 [details]
digiKam 8.3 log

Git commit 0c41c8c23198ef7232c03d16e65349002f60f25b by Maik Qualmann.
Committed on 25/12/2023 at 19:48.
Pushed by mqualmann into branch 'master'.

use UTC representation for the creation and modification time of items

M  +1    -1    NEWS
M  +11   -4    core/libs/database/collection/collectionscanner_scan.cpp
M  +22   -7    core/libs/database/coredb/coredb.cpp
M  +2    -1    core/libs/database/dbjobs/dbjob.cpp
M  +2    -0    core/libs/database/item/containers/iteminfo_properties.cpp
M  +2    -0    core/libs/database/item/scanner/itemscanner.cpp
M  +15   -6    core/libs/database/similaritydb/similaritydb.cpp
M  +1    -0    core/libs/database/thumbsdb/thumbsdb.cpp
M  +4    -0    core/libs/metadataengine/engine/metaengine_exif.cpp
M  +20   -0    core/libs/metadataengine/engine/metaengine_item.cpp
M  +1    -0    core/libs/metadataengine/engine/metaengine_xmp.cpp

https://invent.kde.org/graphics/digikam/-/commit/0c41c8c23198ef7232c03d16e65349002f60f25b

This is a relatively big change, I'm sure I may have missed something. It will be further stabilized over the next few weeks.
We don't need to convert the database and can even work with a mix of local time and UTC time.

Maik

Hi Maik,

I will rebuild the Windows installer tomorrow morning.

What's about the duplicates bugs ? Perhaps we can forward the information about these changes to see the side-effects.

Best
Gilles

I always thought that all duplicate bugs also receive the messages?

Maik

I'm not sure that root file messages are forwarded to all peoples in all duplicates... I will post a message in all files tomorrow  when next installer will be ready to test.

(In reply to caulier.gilles from comment #101)
> I'm not sure that root file messages are forwarded to all peoples in all
> duplicates... I will post a message in all files tomorrow  when next
> installer will be ready to test.

Tested: digiKam-8.3.0-20231226T105122-Win64.exe

Works well.

digiKam-8.3.0-20231228T113341-Win64-debug.exe is still fails to start identically as version 8.2.0 for me on Windows 10 with the splash stating "Loading tools..." This happens even with a fresh library without any files. Last lines in the logs:

[10612] digikam.general: Finish Main Thread
[10612] digikam.geoiface: ----
[10612] digikam.general: Using  4  CPU core to run threads
[10612] digikam.general: Action Thread run 1 new jobs
[10612] digikam.general: One job is done  Digikam::TagsJob(0x18dfce29410)  time: 44
[10612] digikam.general: Finish Main Thread

This is not the same problem, your date job only requires 44 ms. Open a new bug report and post a complete debug log from start to finish.

Maik

(In reply to ivar.ekman from comment #103)
> digiKam-8.3.0-20231228T113341-Win64-debug.exe is still fails to start
> identically as version 8.2.0 for me on Windows 10 with the splash stating
> "Loading tools..." This happens even with a fresh library without any files.
> Last lines in the logs:
> 
> [10612] digikam.general: Finish Main Thread
> [10612] digikam.geoiface: ----
> [10612] digikam.general: Using  4  CPU core to run threads
> [10612] digikam.general: Action Thread run 1 new jobs
> [10612] digikam.general: One job is done  Digikam::TagsJob(0x18dfce29410) 
> time: 44
> [10612] digikam.general: Finish Main Thread

Tested the digiKam-8.3.0-20231228T113341-Win64.exe too.
I have no problem here

Ok, so this must be different then. I created bug 479148 with full my log.

Qt has closed the bug (https://bugreports.qt.io/browse/QTBUG-120285) for version 6.6.2. Qt added a cache for the timezone. I'll test the performance, maybe we'll go back to a local datetime internally.

Maik

Qt 6.6.2 is planed for the 17 january:

https://wiki.qt.io/Qt_6.6_Release

As usual Qt team delay a little bit the release date. Also, Qt 6.6.2 must be updated to VCPKG. This will delay again the usage of this version under Windows.

So, the possible update in the Windows 10 VM used to compile digiKam can be expected around the 15 February i think...

Gilles