Dear Digikam Team 1) I convert .jpeg images to .heif using batch processing. With a large number of images >1500 - 5000, Digikam crashes without any message after some time. With fewer than 1000 images, it almost always works. 2) In addition, it heavily freezes the user interface during processing. 3) When the option 'skip if file exists' is enabled, it seems that it only checks whether the converted file already exists after the conversion. 4) The option to delete the original file after conversion is missing. Thank you for your work :o) STEPS TO REPRODUCE 1. convert per batch processing more than 2000 pics. Enable option "skip if file exists" Windows: 11pro
Did you use multi core option to process in parallel in BQM ?
See the online doc here : https://docs.digikam.org/en/batch_queue/queue_settings.html#behavior
Thank you very much for the quick response. You all are always very diligent. PC1=Fileserver (Windows 11 Pro 24H2) PCs Ryzen 7 Pro 4750G Ram: 32GB PC2=Client (Windows 11 Pro 25H2) Ryzen 7 Pro 4750G Ram: 32GB I have 200,000 images on PC1 with a shared drive. The SQL database is stored on this PC1. Connection is via 1Gb network using MariaDB & MySQL Server. The preview database is stored locally on PC1 and locally on PC2. Metadata is written directly into the image when changed. Whether it's Exif or not doesn't matter. The MultiCore option is off, otherwise the entire PC freezes. I have saved the workflow (Convert jpeg to heif). I put 1 image in the queue. Then I load the workflow for it. After that, I select 2000 images and add them to the queue. If you add the workflow only afterwards, Digikam freezes for 3-5 minutes (bug) When the work is finished, I delete the still-marked images in Digikam (main program). This clears the queue. Then I add more images to the queue. I do this 2-3 times. However, Digikam also crashes if you try to convert, for example, 4000-6000 images at once. At some point, Digikam crashes during batch processing. I have tried many things. I closed and reopened the batch window between steps. But the old history is still there. I have used multiple queues. In each queue, I added 2000 images. None of this helped. It seems to me that there is a buffer overflow and variables are not being properly reset or were dimensioned too small. In any case, thank you very much. Can I also write to you in German?
Git commit 86a4ecd9d36f7338142ed5d609dda882e97231c9 by Maik Qualmann. Committed on 03/12/2025 at 11:38. Pushed by mqualmann into branch 'master'. fix missing heif_deinit() in case of error M +6 -0 core/dplugins/dimg/heif/dimgheifloader_save.cpp https://invent.kde.org/graphics/digikam/-/commit/86a4ecd9d36f7338142ed5d609dda882e97231c9
There are still a few points that should be looked at. 1) Why is the queue not being processed in order? 2) Why does the status bar at the very bottom of the window not change? Entries/Total tasks/Tasks always the same. You should be able to see the queue getting shorter there. 3) When converting, a function would be great, or a basic tool that deletes the original image after conversion. I am really surprised at how quickly you deal with problems. Many heartfelt thanks for your effort and dedication. Digikam has a lot of potential.
We're experiencing a memory leak when saving HEIC images, both under Linux and Windows. Memory usage steadily increases until eventually no more memory can be allocated. The problem does not occur when saving, e.g. with PNG images. @Thomas, Wir schreiben hier eigentlich in Englisch, damit alle Entwickler es verstehen können. Du kannst aber notfalls es auch in Deutsch schreiben, ich verstehe es. Maik
Git commit 0a89d574dabc03be9940f716d48642e0453998ea by Maik Qualmann. Committed on 03/12/2025 at 19:45. Pushed by mqualmann into branch 'master'. fix memory leak with saving HEIC images The heif_image handler was not released. FIXED-IN: 8.9.0 M +1 -1 NEWS M +30 -20 core/dplugins/dimg/heif/dimgheifloader_save.cpp https://invent.kde.org/graphics/digikam/-/commit/0a89d574dabc03be9940f716d48642e0453998ea
1) Wir verwenden eine QThreadPool, die Reihenfolge wird von verschiedenen Faktoren bestimmt und kann nicht festgelegt werden, Verfügbarkeit von Threads, der Scheduler vom Betriebssystem oder die Zeit die ein einzelner Task benötigt. 2) Wir haben einen Fortschrittsbalken sowohl im BQM als auch im digiKam Hauptfenster in der Statusleiste. 3) Das Löschen von Originalbildern ist immer riskant, ohne zu schauen, ob das BQM Ergebnis korrekt ist. Wir haben einen Überschreibmodus, wir können natürlich auch einen Löschmodus hinzufügen. Maik