Clip length is decreasing each time you re-open the project. This leads to a clip deterioration. Reproducible: Always Steps to Reproduce: 1. Create new HD 1080p 23.98 fps project. 2. Add black-5min.mkv to the project bin - you'll see 00:04:59:21 length. 3. Save the project to frame-count-bug-save1.kdenlive. 4. Open it - you'll see 00:04:59:20 length. 5. Edit a description and save the project (later I'll upload it as frame-count-bug-save2.kdenlive). 6. Open it - you'll see 00:04:59:19 length. Expected Results: 00:04:59:22 length from the start and not changing on re-open.
Created attachment 99758 [details] step #2 resource
Created attachment 99759 [details] step #3 project
Created attachment 99760 [details] step #5 project
Can you please check with Kdenlive 16.04.2 if this problem is still present?
Wegwerf, I checked that the problem is still exists in version 16.04.2. Can someone follow the steps and see if it's reproducible on your end?
Kindly ping. This bug currently blocks any video editing on my side since a timeline becomes corrupted if you simply re-open a project.
Ok, I've found the reason. It's mlt v0.9.8. Upgrading to v6.2.0 fixes the issue. I was stuck with old mlt version due to bug #364891, however JBM suggested a workaround and now I can move forward.
Reopening as it's happening again. mlt-6.4.1. kdenlive-17.08.2. Could be reproduced on the original example.
Created attachment 108674 [details] frame-count-bug-save1.kdenlive saved with current stable kdenlive
I just tested with MLT git and latest Kdenlive (17.08.2) and cannot reproduce the problem. Can you test if your issue is reproducible for you with our stable AppImage: https://kdenlive.org/download/
Created attachment 108725 [details] example for the kdenlive-17.08.2-x86_64.AppImage Reproducible but with a slightly different example: Steps that I made: 1. Open AppImage (HD 1080p 29.97 fps project) 2. Add clip3.mkv to the project bin - you'll see 00:00:27;00 length. 3. Save the project to frame-count-bug-example3.kdenlive and close AppImage. 4. Open AppImage and open frame-count-bug-example3.kdenlive - you'll see 00:00:26;29 length. 5. Save As... frame-count-bug-example3_save1.kdenlive and close AppImage. 6. Open AppImage and open frame-count-bug-example3_save1.kdenlive - you'll see 00:00:26;28 length. 7. Save As... frame-count-bug-example3_save2.kdenlive and close AppImage. Expected Results: 00:00:27;00 length from the start and not changing on re-open.
Hi Jean-Baptiste, Could you please try my latest example and let me know if you're able to repro? Only steps 1-4 are needed to see whether it reveals the problem. Thanks, Nikita.
No longer happens with the kdenlive-17.08.3 and mlt-git-955f19c. I guess it's been fixed by the following commits, however I haven't verified this theory: https://github.com/mltframework/mlt/commit/21c21620268725e63e699df77cf886f518c5b0f9 https://github.com/mltframework/mlt/commit/9e9a86a1214585259868448ba8477655e93d993c Old project producers will lose one frame from converting to v6.5.0 format (<property name="length">00:00:26;29</property> is now containing a number of frames instead of a string length), however they will not lose any frames going forward.