SUMMARY If multiple instances of kdenlive are running, then when you start a render job, there is a possibility that a different instance will "attach" to the job. In the instance where you started the job, the job appears in the Job Queue tab with the text "Waiting...", and the job also appears in the Job Queue tab of the other instance, and that is where the progress is actually displayed. If an instance of kdenlive is already running and rendering a job, and then a new instance of kdenlive is started, its Job Queue will not show the job from the first instance. The code appears to attach to jobs in a manner that excludes other instances. STEPS TO REPRODUCE 1. Start a render job in a kdenlive instance. 2. Start a second instance. The job from the first instance does not appear in the second instance's Job Queue. 3. Start a render job in the second instance. The job appears in the first instance's Job Queue with progress updates, and the second instance shows the job but fails to attach to it, simply displaying "Waiting..." OBSERVED RESULT Only one instance can attach to a job, and sometimes it is the wrong one. EXPECTED RESULT All instances should show all jobs and be able to receive progress information in tandem. SOFTWARE/OS VERSIONS Windows: Windows 10 1809 MacOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION I do not have ready access to platforms other than Windows to say if the behaviour is the same or different there.
Thank you for reporting. I’m not sure if multiple instances of Kdenlive can be run.
Huh, okay -- I simply did it without thinking and everything I used worked except for the bug I reported here. ¯\_("/)_/¯
Same problem with Ubuntu Studio 20.04 LTS and kdenlive-21.08.0a-x86_64.appimage Kdenlive multiple instances are very useful: - running different versions to test and report bugs :-) - working concurrently on multiple video sequences: one to compute stabilized video for example, one other import and use them (necessary to change video speed for example).
Agreed :-) Any case where communication with an external process is not precise enough to guarantee that the instance that launches it is the one that connects to it should be considered a bug, and if there are any other cases where an action assumes that a system resource (such as a file path) can simply be used in way that causes two concurrent instances to collide with each other should be considered a bug. An approach used by many other programs is to put the process ID into the path somewhere (e.g. a separate directory per process) so that it is completely impossible for two instances to interfere with each other. Imagine if Microsoft was like, "Well, you can run multiple instances of Microsoft Word if you _want_, but if you tell the first one to print, you might actually get the second one sent to the printer" or something. :-P
Hi and thank you for your patience. Your bug report was for a version of Kdenlive that is at least four years old. Can you please check whether this issue still exists in the latest version 24.12.0? If yes, please update this report to reflect the new version and set the status to CONFIRMED. If it works now like you expect it would, you may change the status of this report to RESOLVED - FIXED. At any rate, this report will be closed if there is no activity for the next 30 days.
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.
Sorry for the delay. I just downloaded 24.12.1 and tried two concurrent renders and they did not interfere with one another. So it looks like the closed state for this bug is correct.
Thank you for your feedback