https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #50 from caulier.gil...@gmail.com ---
Hi,
digiKam 8.6.0 is just released:
https://www.digikam.org/news/2025-03-15-8.6.0_release_announcement/
Problem still exists with this version?
Thanks in advance
Gilles Caulier
--
You are receiving
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #49 from caulier.gil...@gmail.com ---
Hi,
digiKam 8.5.0. is out with many fixes and improvements.
https://www.digikam.org/news/2024-11-16-8.5.0_release_announcement/
This report still valid with this version?
Thanks in advance
Gilles Caul
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #48 from caulier.gil...@gmail.com ---
@Stefan
Please try the new 8.5.0 pre-release PKG installer for MacOS Silicon (arm64)
available here:
https://files.kde.org/digikam/
Thanks in advance
Gilles Caulier
--
You are receiving this mail be
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #47 from caulier.gil...@gmail.com ---
@stefan,
digiKam 8.3.0 stable version is released and available at usual place :
https://www.digikam.org/download/
Can you reproduce the dysfunction on your computer ?
Thanks in advance
Gilles Caulie
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #46 from caulier.gil...@gmail.com ---
@stefan,
digikam 8.2.0 pre-release have been rebuilt using last Qt 5.15.11 + KDE 5.110
frameworks. Installer is available at usual place :
https://files.kde.org/digikam/
Can reproduce the problem with
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #45 from caulier.gil...@gmail.com ---
@Stefan
digiKam 8.0.0 is out. Problem still reproducible ?
Best regards
Gilles Caulier
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #44 from MarcP ---
I can confirm that this is still an issue in the 7.7.0 versions.
I had an issue with my database and I had to reconstruct it. Right now my
pictures are in a remote NAS and while Digikam is importing a few hundreds of
GB o
https://bugs.kde.org/show_bug.cgi?id=420334
caulier.gil...@gmail.com changed:
What|Removed |Added
Version|7.0.0 |7.4.0
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #43 from MarcP ---
Mmm, I don't think nothing changed in that regard. I believe that, in slow
networks, the database must be locked when it's being accessed. When scanning
new pictures, the interface freezes during the import of each single
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #42 from caulier.gil...@gmail.com ---
Marc,
Stable digiKam 7.4.0 is published. Please check if problem is reproducible.
https://www.digikam.org/download/
Thanks in advance
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=420334
Joseph De Veaugh-Geiss changed:
What|Removed |Added
Keywords||efficiency
CC|
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #41 from MarcP ---
Hi,
I can confirm that this problem still persists in Ubuntu 20.04 using the latest
flatpak build (Build date: 22/8/21 10:27 (target: Debug)
Rev.: 699538c1b3ff85650d617ab716493135fe44c999)
Even now that the initial scan
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #40 from caulier.gil...@gmail.com ---
digiKam 7.2.0 official release is published with more than 360 files closed
from bugzilla:
https://www.digikam.org/news/2021-03-22-7.2.0_release_announcement/
Can you reproduce the dysfunction with this
https://bugs.kde.org/show_bug.cgi?id=420334
caulier.gil...@gmail.com changed:
What|Removed |Added
Platform|Other |macOS (DMG)
--
You are receiving thi
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #39 from caulier.gil...@gmail.com ---
https://bugs.kde.org/show_bug.cgi?id=426938
--- Comment #4 from caulier.gil...@gmail.com ---
Hi,
digiKam 7.2.0-beta2 pre-release PKG installer now support BigSur and is
compiled with last stable Qt 5.15
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #38 from MarcP ---
Ok, I did some tests, all of them using the stable 7.0.0 x64 version. I used a
set of ~500 pictures, 4.5GB in size, and using a blank database.
Basically, when storing the pictures locally, the import process is so fast
(
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #37 from Maik Qualmann ---
The cause could be a QEventLoop in the ScanController thread. There are hints
on the web that a QEventLoop blocks the main thread under MacOS.
Maik
--
You are receiving this mail because:
You are watching all bu
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #36 from MarcP ---
I think it also happens with a local collection, but since the latency is much
lower, the time it takes to import each individual picture is also lower and
the effect is less pronounced.
I'll run some tests this afternoon
https://bugs.kde.org/show_bug.cgi?id=420334
Maik Qualmann changed:
What|Removed |Added
Version Fixed In|7.0.0 |
--- Comment #35 from Maik Qualmann ---
I cann
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #34 from MarcP ---
I can confirm this still happens in the stable 7.0.0 release under MacOS
Catalina.
I copy what I wrote in a related bug report (Bug 389652):
"I experienced this again in the 7.0.0 stable version on a macbook with MacOS
https://bugs.kde.org/show_bug.cgi?id=420334
MarcP changed:
What|Removed |Added
CC||iwannaber...@gmail.com
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=420334
caulier.gil...@gmail.com changed:
What|Removed |Added
Severity|normal |crash
--
You are receiving this mail
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #33 from caulier.gil...@gmail.com ---
digiKam 7.0.0 stable release is now published:
https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/
We need a fresh feedback on this file using this version.
Best Regards
Gilles Caulie
https://bugs.kde.org/show_bug.cgi?id=420334
Stefan S changed:
What|Removed |Added
Assignee|stefan.szeke...@gmail.com |digikam-bugs-n...@kde.org
--
You are receiving this
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #32 from Maik Qualmann ---
Git commit 52c79f56432d1ba894760165d4aef5b9a59ae327 by Maik Qualmann.
Committed on 21/04/2020 at 18:10.
Pushed by mqualmann into branch 'master'.
add note to the album monitoring option
M +11 -3core/utilit
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #31 from Stefan S ---
(In reply to caulier.gilles from comment #30)
> Stephan,
>
> we use Qt loggin rules to enable/disable debug traces.
>
> Look here in MacOS section:
>
> https://www.digikam.org/contribute/
>
> Warning : this will gen
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #30 from caulier.gil...@gmail.com ---
Stephan,
we use Qt loggin rules to enable/disable debug traces.
Look here in MacOS section:
https://www.digikam.org/contribute/
Warning : this will generate a very verbose output on the console. Typic
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #28 from Stefan S ---
(In reply to caulier.gilles from comment #27)
> The debug stage under OSX hurt me. It's definitively too much complicated...
>
> As Maik, said, the cardh is located in DMetadata::load() interface which
> call Exiv2 lib
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #29 from Stefan S ---
Another hang on the Timeline tab (beta3-debug):
https://gist.github.com/0wnrepo/6bd62ec27806c08de9bcb38cd3563336
Seems that there is too much work done on the main thread (the one the GUI is
using) and this is why it b
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #27 from caulier.gil...@gmail.com ---
The debug stage under OSX hurt me. It's definitively too much complicated...
As Maik, said, the cardh is located in DMetadata::load() interface which call
Exiv2 libary API to handle file metadata. It's k
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #26 from Stefan S ---
(In reply to caulier.gilles from comment #24)
> Did you use the bug version of OSX PKG installer ? Why there is no debug
> symbols in your backtrace ? Where is located the thread responsible of the
> crash ?
I was usin
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #25 from Maik Qualmann ---
It probably crashes in Exiv2 when loading the metadata. Probably through an
image with wrong metadata. I don't want to disappoint you, we have never tested
digiKam with such a number of imges. Through my photograph
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #24 from caulier.gil...@gmail.com ---
Did you use the bug version of OSX PKG installer ? Why there is no debug
symbols in your backtrace ? Where is located the thread responsible of the
crash ?
The debug bracktrace is less clear than Linux v
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #23 from Stefan S ---
(In reply to Maik Qualmann from comment #21)
> How many images / album folder are you trying to add to digiKam?
>
> Maik
As mentioned above, millions of images.
also, digiKam just crashed:
https://gist.github.com/0wn
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #22 from caulier.gil...@gmail.com ---
If you want performances and not to be limited in space size, use a SSD, it
work perfectly, and not too expensive.
Gilles Caulier
--
You are receiving this mail because:
You are watching all bug change
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #21 from Maik Qualmann ---
How many images / album folder are you trying to add to digiKam?
Maik
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #20 from Stefan S ---
(In reply to Maik Qualmann from comment #3)
> The scanning process is a separate thread. I can continue to work here on
> Linux, albeit a bit slower. Keep in mind that the scanning process is
> massively loading your fi
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #19 from Stefan S ---
(In reply to Maik Qualmann from comment #18)
> Ok, thanks for the feedback. The albums are also monitored in the background
> (if enabled) with the QFileSystemWatcher. The problem is the
> QFilesystemWatcher itself, tha
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #18 from Maik Qualmann ---
Ok, thanks for the feedback. The albums are also monitored in the background
(if enabled) with the QFileSystemWatcher. The problem is the QFilesystemWatcher
itself, that adding a folder path (only if it is a networ
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #17 from Stefan S ---
(In reply to Maik Qualmann from comment #16)
> Hmm, and the GUI no longer hangs when new items are added in the background?
> I would then add an additional warning / explanation for MacOS to the album
> monitoring opti
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #16 from Maik Qualmann ---
Hmm, and the GUI no longer hangs when new items are added in the background? I
would then add an additional warning / explanation for MacOS to the album
monitoring option.
Maik
--
You are receiving this mail bec
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #15 from Stefan S ---
(In reply to Maik Qualmann from comment #14)
> This message makes me wonder: QFileSystemWatcher::addPath(). Did you
> reactivate the monitoring of albums in the settings? This option is
> deactivated by default. Under M
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #14 from Maik Qualmann ---
This message makes me wonder: QFileSystemWatcher::addPath(). Did you reactivate
the monitoring of albums in the settings? This option is deactivated by
default. Under MacOS, it takes hours to load albums from netwo
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #13 from Stefan S ---
The main thread is what the GUI uses, a good heuristic is to avoid doing any
work on the main thread, on macOS (full disclosure, i'm a macOS developer)
--
You are receiving this mail because:
You are watching all bug
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #12 from Stefan S ---
Found your problem: You are doing work, on startup, on the main thread.
(com.apple.main-thread (serial))
1970 Thread_18642693 DispatchQueue_1: com.apple.main-thread (serial)
+ 1970 start (in libdyld.dylib) + 1
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #11 from Stefan S ---
Installed version beta3, can't even open digikam, i hangs on startup. Had to
kill it after 4 minutes. Reinstalling now with video capture, will come back
with video link.
Meanwhile, here is the stack for beta3:
https://
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #10 from Stefan S ---
(In reply to caulier.gilles from comment #9)
> You must to check with 7.0.0-beta3, not beta2, available here :
>
> https://files.kde.org/digikam/
>
> Gilles Caulier
Installing right now. Forced quit beta2, here is th
https://bugs.kde.org/show_bug.cgi?id=420334
caulier.gil...@gmail.com changed:
What|Removed |Added
CC||caulier.gil...@gmail.com
--- Comment
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #8 from Stefan S ---
The video is still processing by Youtube, will be 1080p in a few minutes,
sorry.
--
You are receiving this mail because:
You are watching all bug changes.
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #7 from Stefan S ---
I cannot select or do anything in the GUI. It is completely blocked.
Uploading a video to youtube with screen recording.
The only non-default configuration I'm aware of is that i selected to write all
metadata to all ima
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #6 from Maik Qualmann ---
The image is not very meaningful. You can no longer select or open anything in
the GUI? If I integrate a new network collection here under Linux and the scan
is running, I can work with digiKam without any problems.
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #5 from Stefan S ---
(In reply to Stefan S from comment #4)
> Created attachment 127725 [details]
> digiKam-7.0.0-beta2-MacOS-x86-64.pkg GUI hang bug
>
>
> Hi,
>
> This still reproduces on digiKam-7.0.0-beta2-MacOS-x86-64.pkg
> Same steps
https://bugs.kde.org/show_bug.cgi?id=420334
Stefan S changed:
What|Removed |Added
Version|6.4.0 |7.0.0
--
You are receiving this mail because:
You a
https://bugs.kde.org/show_bug.cgi?id=420334
Stefan S changed:
What|Removed |Added
Assignee|digikam-bugs-n...@kde.org |stefan.szeke...@gmail.com
Ever confirmed|0
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #3 from Maik Qualmann ---
The scanning process is a separate thread. I can continue to work here on
Linux, albeit a bit slower. Keep in mind that the scanning process is massively
loading your file system. Depending on the database (SQLite,
https://bugs.kde.org/show_bug.cgi?id=420334
Maik Qualmann changed:
What|Removed |Added
Status|REPORTED|RESOLVED
Resolution|---
https://bugs.kde.org/show_bug.cgi?id=420334
Maik Qualmann changed:
What|Removed |Added
CC||metzping...@gmail.com
Component|Albums
https://bugs.kde.org/show_bug.cgi?id=420334
Maik Qualmann changed:
What|Removed |Added
Version Fixed In||7.0.0
--
You are receiving this mail because:
https://bugs.kde.org/show_bug.cgi?id=420334
--- Comment #1 from Stefan S ---
Found this piece of software on softwarerecs on stackexchange and also on
alternativeto.net to Google Picasa (discontinued) - the best management photo
app there was. Searching for an alternative as that piece of softwar
https://bugs.kde.org/show_bug.cgi?id=420334
Stefan S changed:
What|Removed |Added
CC||stefan.szeke...@gmail.com
--
You are receiving this
60 matches
Mail list logo
