Steps to reproduce: 1. Load a clip in the timeline. 2. Apply Speed effect to the clip. 3. Do some edition, like cutting the clip, change speed, and so on. 4. Save project and exit kdenlive (*). 5. Reopen kdenlive and load the project. The speed effect is now missing from the clip. MLT version 6.5.0 (*) The bug doesn't always happen. It seems that logging out of the system affects the outcome. Perhaps is related to kdenlive processes not being closed properly.
I've been having problems like this with Version 17.04.3 from PPA on Ubuntu 16.04 LTS. PPA is not offering me an upgrade, but apparently it wouldn't resolve the issue, based on this bug report.
I see a similar issue on Gentoo64bit, media-libs/mlt-6.4.1-r6 kde-apps/kdenlive-17.12.1 Here I have a project with about 400 video files, about 500 time clips and >100 Speed settings. SOME operations like shifting clips in the time line , or lane-shifting, or something else kills lots of speed settings previously applied to lots of clips in the time line. I see me adding speed effects the 4th time over and over to the same clips :-(
This might be similiar to bug 385542 . Additional issue 1: When you copy a speed effect from one clip to another, the program forgets it. Additional issue 2: When you copy a color rotation effect from lane1 (with setting) to lane2, the program forgets the setting at lane2.
I found steps to reproduce it: 1. create new project 2. add ONE video clip into bin 3. add a color clip 4. place the video clip into time line 5. put the color clip behind the video clip 6. add speed effect to video clip, set it to 200% 7. replay the clip section, check the double speed. 8. save project 9. do a GROUP MOVE of both clips, to the right (also to left) 10. check the replay, speed is gone ! 11. Save, reopen - the speed effect on the clip is gone !
As I just tested, that version of kdenlive is affected by this bug: kde-apps/kdenlive-17.08.3 == gentoo-stable@2018-02-04
I see on Linux mint, which uses kdenlive-15.12.3, that this bug is already in that old version.
The bug is also in kde-apps/kdenlive-9999 , from the "kde" overlay, used in gentoo. This version of the ebuild downloads the most recent source and installs it. If the developers fix this bug, I could test it using the kde overlay again.
Hello, We are sorry but we now that with the current code, our handling of speed changes is terrible and causes many problems. This is one of the reasons why JB as started the refactoring_timeline branch more than 1 year ago! This branch is now quite useable (still things missing here and there), you are welcome to test it on small projects. Either building from source, or downloading the beta AppImage. Thanks!
I could go ahead and try testing the new version. 1. I found on the website the page for the new beta version: https://files.kde.org/kdenlive/unstable/kdenlive-18.04-beta2.AppImage.mirrorlist Is that the version you mentioned ? 2. I use gentoo, and there is a kde overlay which provides a Version kdenlive-18.04.49.9999 , see http://gpo.zugaina.org/kde-apps/kdenlive Does this version contain the branch ? If not is it another version on any branch I could install with portage ? 3. If not - where can I read what to do with these AppImage files ?
I am using the refactoring branch, but never sure what bugs to post since it's still quite buggy. Are there any anticipated enhancements to the speed changes as well? The one major thing we are missing is keyframable speed changes. I know it has been mentioned before but is there anyone looking into whether this is possible? Is there anyway we could use the backend of slowmovideo to bring some of these features to kdenlive?
I am using kde-apps/kdenlive-18.12.0 on gentoo linux (default/linux/amd64/17.0/desktop) and just tested the current version. The bug still persists and can be recreated by following Comment 4. Here I would note that this bug is not specific to the windows binary.
Thanks for testing. The speed effect in the released version is buggy. Would you like to test the speed effect with the refactoring version? It’s new written but has still some issues. Here the link to the actual Kdenlive Kdenlive_Nightly_Appimage https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/
Created attachment 117458 [details] Screenshot of kdenlive-19.03.70-bd12c4f-x86_64.appimage I tested the kdenlive-19.03.70-bd12c4f-x86_64.appimage In the given version, there is no (more) speed effect available. See the screen shot. The former effect that was set with the older kdenlive version is not being represented in the current program.
Created attachment 117459 [details] Refactoring_Speed In the refactoring version you get the speed effect by right click on the clip in the timeline.
I tested the kdenlive-19.03.70-bd12c4f-x86_64.appimage As i just see, the speed effect remains on group move, but disappears on project close , project reopen. Steps to reproduce it: 1. create new project 2. add ONE video clip into bin 3. add a color clip 4. place the video clip into time line 5. put the color clip behind the video clip 6. add speed effect to video clip, set it to 200% 7. replay the clip section, check the double speed. 8. save project 9. close kdenlive 10. start kdenlive, reload the project 10. check the clip in timeline / context menu / speed : the speed effect on the clip is gone.
Speed effect should be solved. Please try with the actual Kdenlive_Nightly_Appimage #56: https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/
I just tested kdenlive-19.03.70-b33cb35-x86_64.appimage . Applying speed, saving, closing, reloading, checking the speed works now. Actually this is the first version since some years where I see that feature working so far ;-)
Hi Ever since version 19.04 the speed effect has been rewritten. Can you please test if this is happening in the latest version (19.12.2)? Do try the AppImage since it'll guarantee that all dependencies are met. Closing, but please reopen if it is not fixed. Thanks