SUMMARY (a) When running a command-line command like --export or --export-sequence, the process does not run until Krita is closed. This makes it impossible to use the commands (e.g. from external apps) while working in Krita. It doesn't matter which file is open in Krita, it just won't execute the command while GUI is open for some reason. This happens both on 5.1.1-flathub and 5.0.2-apt at least. I don't know when the bug was introduced. (b) A very similar problem also happens (at least in 5.1.1-flathub; don't know if it's because of flatpak) where it freezes on splash screen when either: - Krita GUI is open (with or without files open) and `flatpak run org.kde.krita` is run - A Krita file is open in the GUI and `flatpak run org.kde.krita samefile.kra` is run to open the same file All of these only unfreeze after Krita GUI is closed. STEPS TO REPRODUCE 1. Open Krita GUI (e.g. from app launcher) 2. Open terminal and run the command (e.g. `krita --export file.kra --export-filename file.webp`; also happens with other commands) OBSERVED RESULT Process is stuck (if command was to open GUI, it's stuck on splash screen), and only unfreezes when Krita is closed. EXPECTED RESULT No Krita command-line commands should ever freeze. Export commands should work regardless of whether Krita GUI is open. Ideally, export commands should even be allowed to run in parallel. Same for export-sequence (animation frames). SOFTWARE/OS VERSIONS Krita: 5.0.2 (apt) and 5.1.1 (Flathub) Operating System: Kubuntu 22.04 KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 Kernel Version: 5.15.0-50-generic (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-5300U CPU @ 2.30GHz Memory: 11.1 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 5500 ADDITIONAL INFORMATION This looks similar to #342672 and #400459 but it seems to be a different bug.
I can confirm this on master, It is clear by the backtrace that krita is waiting for sqlite database to be freed to continue. ``` thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP * frame #0: 0x000000018f8fe06c libsystem_kernel.dylib`__semwait_signal + 8 frame #1: 0x000000018f806fc8 libsystem_c.dylib`nanosleep + 220 frame #2: 0x000000018f806ee0 libsystem_c.dylib`usleep + 68 frame #3: 0x0000000134ba63fc libqsqlite.dylib`___lldb_unnamed_symbol442 + 60 frame #4: 0x0000000134bb6cf4 libqsqlite.dylib`___lldb_unnamed_symbol649 + 108 frame #5: 0x0000000134bc6d84 libqsqlite.dylib`___lldb_unnamed_symbol820 + 40 frame #6: 0x0000000134bd6dac libqsqlite.dylib`___lldb_unnamed_symbol909 + 2448 frame #7: 0x0000000134be8c64 libqsqlite.dylib`___lldb_unnamed_symbol941 + 55716 frame #8: 0x0000000134ba6c2c libqsqlite.dylib`___lldb_unnamed_symbol452 + 260 frame #9: 0x0000000134b98dc8 libqsqlite.dylib`___lldb_unnamed_symbol283 + 412 frame #10: 0x0000000134b9a508 libqsqlite.dylib`___lldb_unnamed_symbol294 + 1456 frame #11: 0x0000000100b82fe0 QtSql`QSqlQuery::exec(QString const&) + 844 frame #12: 0x0000000134b9be50 libqsqlite.dylib`___lldb_unnamed_symbol317 + 116 frame #13: 0x0000000101326f5c libkritaresources.19.dylib`KisResourceCacheDb::synchronizeStorage(storage=<unavailable>) at KisResourceCacheDb.cpp:1920:30 [opt] frame #14: 0x0000000101331fd4 libkritaresources.19.dylib`KisResourceLocator::synchronizeDb(this=0x0000600000238060) at KisResourceLocator.cpp:1183:14 [opt] frame #15: 0x00000001013305c0 libkritaresources.19.dylib`KisResourceLocator::initialize(this=0x0000600000238060, installationResourcesLocation=<unavailable>) at KisResourceLocator.cpp:129:10 [opt] frame #16: 0x000000010269a56c libkritaui.19.dylib`KisApplication::registerResources(this=0x000000016fdff228) at KisApplication.cpp:371:74 [opt] frame #17: 0x000000010269bd18 libkritaui.19.dylib`KisApplication::start(this=0x000000016fdff228, args=0x000000016fdff2b8) at KisApplication.cpp:462:10 [opt] ```
Actually, the second krita instance should send the commands to the running process, which executes it. We cannot run two instances of Krita anymore at all.
Have been having issues with this as well; currently getting around it by using the last major version (4.4.8) to do the programmatic exporting; image seems to come out alright for me but not sure if this would work with all cases.
My main issue with this bug is that, since the call from the other app needs to be synchronous, Krita freezing freezes the waiting app as well, with no explanation to the user. :( I'm aware having a second apt installation besides flatpak works (though yes, older version can have different results), but in any case I can't require users to have 2 Krita installations...
Please don't change the version number: it's not the last version that still has the bug, but the version for which the bug was first reported.
(In reply to Halla Rempt from comment #5) > Please don't change the version number: it's not the last version that still > has the bug, but the version for which the bug was first reported. Oh, OK. Sorry for the confusion.
Still happening on 5.1.5. I also noticed that when converting from a webp file, the "opening webp" window is shown even from the command line. As I understand, this command is meant to be used in batch processing and shouldn't show any GUI. In fact this window is weird - I'd expect all files are opened in a lossless manner, and preferences apply only when saving (like with png). I don't know if a similar thing happens on other formats that might have such "opening windows" (are there others?).
If the bug is not marked as resolved, you can safely assume that it has not yet been fixed.
If the problem is that it's waiting to access a Sqlite database, and assuming that the export command is a read-only operation, then would it be feasible to just copy the database file to a temporary location and access that copy for the command? (This might not be possible on Windows because of file locks) Alternatively, open the Sqlite database in immutable/read-only mode for the export command?