See video link in URL field for details. Sometimes, when a preview-render has finished for zones in the timeline, making changes within those zones and preview-rendering again doesn't always show updated changes; instead, it reverts back to the cached data (I believe). Deleting the cached data will force it to re-render the zones, which it then works fine. Reproducible: Always Steps to Reproduce: 1. Create a new project 2. Add some clips to the timeline, add fx/transitions/titles/whatever 3. Set a preview render zone and start preview render 4. When preview render is done, make changes to clips in that preview render zone and start preview render again. Actual Results: Preview render finishes almost immediately, but uses the already rendered cache data for the timeline and doesn't seem to re-render the areas that have had changes to them since last preview render. Expected Results: Starting preview render will always re-render areas/zones that have had changes to them since last preview-render. Bug discovered while using Kdenlive 16.11.70 git master build via ppa:kdenlive/kdenlive-master. Ubuntu 16.04 x64, Unity 7.4.0 desktop environment. KDE Frameworks 5.18.0. Qt 5.5.1
Jesse, are you seeing green parts turning red properly, or is this already missing? I'm seeing incorrect invalidation when using the spacer tool; I've reported so separately.
Wegerf, lemme do some testing today and I'll reply with whether I experience the error your describing on the latest git master build from the kdenlive-master ppa.
Wegwerf, I can confirm that the green/red preview render bar is not updating properly when I make changes to (a) the properties of FX on a clip in the timeline, or (b) the location of a clip in the timeline. Changing these doesn't always cause the Preview Render to reflect that changes have been made and a new cache needs to be rendered.
Git commit 1df50d2be1311e91611a3ffe829d79b08efff700 by Jean-Baptiste Mardelle. Committed on 24/08/2016 at 05:51. Pushed by mardelle into branch 'Applications/16.08'. Fix timeline preview invalidate when hiding a track M +8 -1 src/timeline/timeline.cpp http://commits.kde.org/kdenlive/1df50d2be1311e91611a3ffe829d79b08efff700
Looks like the preview render feature is working better now in the case when the user mutes the video on a track, but there are still issues with its behavior when making changes to a clip's effects in the timeline or its position in the timeline. See updated video example: https://youtu.be/0koc_NKni54
Git commit 1d98d4f4c2eed6ed1161101e52aea035b45d71de by Jean-Baptiste Mardelle. Committed on 25/08/2016 at 05:40. Pushed by mardelle into branch 'Applications/16.08'. Fix typo causing failed timeline preview on some fps M +1 -1 src/doc/kdenlivedoc.cpp http://commits.kde.org/kdenlive/1d98d4f4c2eed6ed1161101e52aea035b45d71de
Fixed, works PERFECTLY! You're the man. Thanks JB!
I need to re-open this bug. Looks like it's occurring, again, in 17.07.70 master ppa build. Same issue happens on a project in 1080p, 30fps: changing a clip's position in Timeline, even Adding a clip to a new track over clips that have been preview-rendered and starting preview render DOESN'T actually build a new preview render. Anything that was red (un-rendered) immediately switched to green (rendered), but doesn't reflect the changes I've made in the timeline.
Can you please update to the latest version (20.12.3 at the moment, https://kdenlive.org/en/download/) and report here whether this is still happening?
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. 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. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!