Kdenlive opens a process called kdenlive_render when rendering video. When rendering the video ends, that process is finished, but the job queue is not properly updated and continues to show a small remaining time despite the work has been completed. Reproducible: Always Steps to Reproduce: 1. Proyect --> Render 2. Select MP4 format 3. Render to File... Actual Results: Apparently the task is not completed but the video has been rendered effectively. Expected Results: The job queue must show that the task has been completed. Thank you very much for your great work
Created attachment 101698 [details] Screenshot showing the problem
Cannot reproduce, and I'm doing a lot of projects with Kdenlive, where I render to MPEG-4 containers. What distribution and desktop environment are you using? I remember that we had once an issue where the completion wasn't been correctly detected, but this has been fixed quite some time ago. Could the Neon packages be stale??
Created attachment 101894 [details] video file to be used in reproducing the bug I am running into this occasionally (perhaps 50% of the time I render). Here is how to reproduce: 1. Import the attached video into the project bin, then put it on a video track (I put mine on "Video 1"). 2. Click "Render" and for the format, select Generic -> WebM and keep the default options. 3. Click "Render to File". Result: If it tells you that rendering is completed, clear the job and render again, opting to replace the file when prompted. On my system, it only takes 2-3 renders before the render eventually stalls at 99% completed. If you check the end of the rendered video's accompanying text file, it will say that rendering was finished, and the video file seems to be complete. However, the "unfinished" job will be hung up in Kdenlive's queue, unresponsive to any requests to end or abort the render. When running Kdenlive from the command line, there is no difference in terminal output between a successful and a stalled render. I was able to repro this bug in the following configurations that I tested: #1, via KDE Neon repository: . Kdenlive 16.08.2 . KDE Frameworks 5.27.0 . Qt 5.7.0 . MLT 6.0.0 #2, via devel AppImage: . Kdenlive 16.11.70 (devel) . KDE Frameworks 5.27.0 . Qt 5.7.0 . MLT 6.3.0 Both of these versions were tested on the following system: . OS: KDE Neon 5.8.2 64-bit (Plasma Desktop 5.8.2) . PC: HP Pavilion m6-1035dx . CPU/GPU: AMD A10-4600M APU with Radeon HD 7660G Graphics (using xorg radeon driver) . RAM: 6GB DDR3 800 MHz . Linux Kernel: 4.4.0.45-generic
Maybe vaguely related to this: https://bugs.kde.org/show_bug.cgi?id=371263
So I now finally saw this for one of my projects too, so I'm confirming. However, this is not reproducible at 100% and it does not happen to all projects, but only to some. How to reproduce (hopefully): this is a freshly created project where I render the timeline into several parts (using guides). I then add several rendering jobs from the same project to the job queue, and at the same time explicitly start all rendering jobs so they run in parallel. Typically, from 6 or 7 rendering jobs running in parallel, at least 1 or 2 get stuck at the final one or two seconds, despite the rendering having finished properly as I can see from the final video file. In addition, the .txt MLT render XML input files never get correctly cleaned up; this happens to both finished and hung jobs. The hanging jobs were running for several minutes, so this happens not only to quick jobs.
I can confirm this exact behavior as described on my system (16.08.2 on OpenSUSE Tumbleweed) as well.
Git commit f3002dd8d31de218d3f8797cfd8b93647760a9cb by Jean-Baptiste Mardelle. Committed on 12/11/2016 at 11:04. Pushed by mardelle into branch 'master'. Fix rendering crash on finish M +2 -1 renderer/renderjob.cpp http://commits.kde.org/kdenlive/f3002dd8d31de218d3f8797cfd8b93647760a9cb
I noticed this bug, too. The output video did play normally, even if kdenlive did not detect the end of rendering properly. Thanks for fixing it!
Is this fix supposed to be included in Kdenlive 16.12.3 ? See https://bugs.kde.org/show_bug.cgi?id=379872