SUMMARY If the duration of an image is increased from 4:29 to any bigger value this value seems to get reset during save. After loading the project from file the image has a duration of 4:29 causing the video track of all subsequent clips to be displayed with a offset to the left. The incorrect postions of video clips is also used during render. STEPS TO REPRODUCE 1. Create a new project 2. Choose "Add clip" to add an image 3. Choose "Add clip" to add an video 4. Add image to track V1 5. Increase duration of the image from 5s to 8s 6. Add video to track V1 right after the image 7. Save project file 8. Restart kdenlive 9. Load project from file OBSERVED RESULT The image on track V1 has a duration of 5s, causing the video part of the video to start already at position 5:00 rather than 8:00. The audio part of the video is located at 8:00 (which is correct). EXPECTED RESULT The image on track V1 has a duration of 8s, causing the video part of the video (video part and audio part) to start at position 8:00. SOFTWARE/OS VERSIONS KDE Frameworks Version: 5.87.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION This problem does not exist in kdenlive 21.08.1!! After I downgraded to this version: sudo apt install kdenlive=4:21.08.1-0xneon+20.04+focal+release+build36 kdenlive-data=4:21.08.1-0xneon+20.04+focal+release+build36 ... I had to to set "kdenlive:docproperties.version" to a "1.02" in order to be able to load the project file created with kdenlive 21.08.3 with kdenlive 21.08.1. Using 21.08.1 I was able to fix corrupted clip positions, save/load project and render.
Created attachment 144066 [details] Before save
Created attachment 144067 [details] After reload
Similar problem since upgrading to Version 21.08.3 MLT version 7.1.0 Using title clips to create subtitles for my video (not a fan of the built in subtitle feature). Even if I lock the channels, when I reopen the project they have all moved position. If I "group clips", they are ungrouped when I reopen to file.
Thank you for reporting. Please try with the current Kdenlive AppImage version 21.08.3a to see if there are any packaging issues: https://download.kde.org/stable/kdenlive/21.08/linux/ or with Kdenlive_Nightly_Appimage https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/
The bug seems to be fixed with Kdenlive AppImage version 21.08.3a. Using the steps to reproduce I was not able to reproduce the bug anymore.
I had exactly the same bug, and I can also confirm it's fixed with kdenlive 21.08.3a Thanks for the fix, it saves me!
Thank you for the feedback and contribution. Glad to hear it works. I close this bug. If it still appears in the latest version, please feel free to re-open it and update the affected version number.