Created attachment 128904 [details]
Project files, see ATTACHMENTS section in report
Project file seems to be in a state that when speed is applied, reloading the project crashes. To repair the file, replace the clip with itself and it seems to heal.
Still, would expect some graceful handling to avoid losing data (in case someone did not notice the issue) as recovery is not possible without backup or fiddling with the XML.
STEPS TO REPRODUCE
1. Open the attached file "base.kdenlive"
2. In the timeline, change the speed of the THIRD clip to "400%"
3. Save the project
4. Close kdenlive
5. Open the project again
Seeing the progress bar "loading clips" and then it crashes at around 80%.
If you delete the FIRST or the SECOND clip in the timeline before step 2, the crash will not happen after reloading.
If you use "replace clip" and select the same original clip before step 2, it somehow seems to fix the project structure.
- base.kdenlive: original project stripped down to the minimum for bug reproduction
- base-speed-broken.kdenlive: base.kdenlive + speed change that causes the issue, loading this file crashes kdenlive
- base-replaced.kdenlive: base.kdenlive + clip replaced with the same file, it seems the file has repaired itself
- base-replaced-speed-working.kdenlive: base-replaced.kdenlive + speed applied: this one doesn't crash
- backtrace.txt: TODO
Note: I cannot provide the video clip for the project, but also if I replace it with another one for testing, the problem solves itself (see workaround 2).
Appimage: kdenlive-20.04.1b-x86_64.appimage or kdenlive-20.07.70-486ce54-x86_64.appimage
Linux/KDE Plasma: 5.15.4-lp151.1.1.x86_64 (system, likely unrelated)
KDE Plasma Version: plasma-framework-components-5.55.0-lp220.127.116.11.x86_64 (system, likely unrelated)
Qt Version: 5.9.7 (system, likely unrelated)
You can try diffing the attachments to see the differences between working and non-working.
My impression is that maybe the project file got into some kind of corrupted state, possibly in the object hierarchy, and that corrupted state only becomes apparent after enabling speed.
One suspicious thing I saw when diffing base.kdenlive with
base-replaced.kdenlive was a field:
<entry producer="15" in="00:00:00,000" out="00:13:45,000"/>
which becomes this after replacing the clip with itself (workaround 2):
<entry producer="producer0" in="00:00:00,000" out="00:13:45,000"/>
Strange that it did not have the "producer" prefix in the first place.
Maybe this causes a broken reference leading to segfault ? But why would it
happen only after applying speed ?
I don't know how the project got into that state. I haven't switched versions,
started working with the appimage version 20.04.1b.
I guess maybe some hardening needs to be done to at least avoid the crash and make it recoverable.
Sadly I didn't have backups so I had to mess up with the broken project file to delete all the sped up sections to make it loadable again.
Please let me know if this is enough information.
I'll try to provide a backtrace, not sure how from the appimage. Will likely need to compile from git.
Created attachment 128905 [details]
Console output from the crash
This is most likely the comma/point issue https://invent.kde.org/multimedia/kdenlive/-/issues/78 which is under investigation for solving.
Thanks for the link.
On my local setup I have "American English" in the selected locale in Plasma, however as I live in Germany I've set the number formats to "de_DE", which would use a comma instead of a dot.
So the bug could be related to that.
Yes that is most likely. I take your file for further testing.
Comma point issue is fixed with version 20.08.0.