https://bugs.kde.org/show_bug.cgi?id=455386
--- Comment #8 from Alvin Wong <al...@alvinhc.com> --- Thanks for trying to fix it. Honestly I think the change may not fix the issue -- it seems QProcess::state is set to NotRunning only after QProcess has detected the process has died, so the condition may still be true if the process has just died. But I'll need to do a new ASAN build and test it out to tell. (I could also test with Application Verifier, but I feel it is a bit less reliable than ASAN, and it's also quite slow...) (In reply to Eoin O'Neill from comment #7) > Diving into the FFMPEGWrapper code, there are issues with how we are > treading the subprocess. By having a "blocking" ffmpeg process, we are > preventing the UI from updating. This is a bad design and we should be > approaching this with a "Futures" based approach (I.E. schedule a task to > occur after process has concluded.) The biggest issue is the waitForFinished call. I wonder if it can instead start a nested QEventLoop, and rely on the QProcess::finished signal, perhaps also with a timeout QTimer to exit the event loop? This may even remove the need to call processEvents to update UI. Running it on another thread or using QFuture can also work, but that may be a bit overkill. -- You are receiving this mail because: You are watching all bug changes.
