Created attachment 130298 [details] Crash report w/ Stack Trace saved to file b/c reporter crashes while submitting >:d SUMMARY Some image clips show up as "INVALID" after being imported into Kdenlive, even though the source images themselves are perfectly fine outside of it. While trying to figure out why two image clips had "INVALID" written instead of being displayed correctly, I tried to "reload" the clip, and it causes a crash. It's not clear why kdenlive thinks the image clips are "INVALID" in the first place. I had to delete the clips (losing all the related work in the timeline) and then re-add them and re-do the work. This workaround at least worked in this fresh install, but not in my previous non-fresh install setup. (All same versions, so I assumed it was a side-effect from prior upgrades.) This was observed in a fresh OS install (Kubuntu 20.04 LTS) with a fresh kdenlive install today. STEPS TO REPRODUCE 1. Get kdenlive to show an image clip as "INVALID" (no idea how to reproduce this) 2. Right click on the image clip in the Project Bin 3. Click on "Reload clip" OBSERVED RESULT Crash. EXPECTED RESULT Not crash. Actually reload/"reset" itself to fix whatever the problem was here. (The source image for the clip is actually on the correct path, file is good (i.e. not corrupt, etc), and so on.) SOFTWARE/OS VERSIONS Operating System: Kubuntu 20.04 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 5.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-42-generic OS Type: 64-bit ADDITIONAL INFORMATION Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 31.3 GiB of RAM GPU: NVIDIA RTX 2070 Super w/ 8GB on driver 440.100
Adding a new detail: After submitting this bug, I had to restart kdenlive, and the image clips that I had fixed with the above workaround are again showing up as "INVALID". Trying to reload them causes a crash again.
Please try with the current Kdenlive AppImage version 20.08.0 to see if there are any packaging issues https://files.kde.org/kdenlive/release/ If the problem/issue doesn't occur when using the AppImage, then it's your configuration or packaging. WARNING: Version 20.08.0 has a new project type that is not backwards compatible... so you won't be able to use older versions to open new files.
Created attachment 131336 [details] Proof of "invalid" clip in version 20.08 from AppImage (In reply to emohr from comment #2) > Please try with the current Kdenlive AppImage version 20.08.0 to see if > there are any packaging issues https://files.kde.org/kdenlive/release/ > > If the problem/issue doesn't occur when using the AppImage, then it's your > configuration or packaging. > > WARNING: Version 20.08.0 has a new project type that is not backwards > compatible... so you won't be able to use older versions to open new files. It still happens in 20.08.0. As I had mentioned, this had been observed and reproduced in a clean OS and Kdenlive install, i.e. the clean install applies to both of them. It was in a 2nd PC I have, so I've already reproduced the issue in two separate computers. Also, I should add that there's a crash whenever you try to change the speed of a clip that is reproducible in both version 19 listed in original report and also in version 20.08 you asked me to use. I'll see if I find something that looks like a duplicate. Otherwise, I'll file a new one.
I misworded my last post and must clarify: What "still happens" is the clip keeps being shown as "invalid" even though it's actually valid. Forcing the "reload clip" from the project bin did not cause a crash when I tested it earlier, but it still keeps complaining about clips being "invalid", as per the attachment. The note on clip speed changes is still accurate and does cause a crash, but I'm following up on that elsewhere, as I can.
For info on the clip speed change crash, see https://bugs.kde.org/show_bug.cgi?id=426048
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!
Changing status to REPORTED.
You are using an .xcf file which is a GIMP file and not an image format, that is not supported. We should remove it from the accepted project.
Renamed issue
(In reply to farid from comment #9) > Renamed issue I think this is a problem. Kdenlive had always worked with these files without issues and it did so for years across several projects. I'm sure that doesn't just magically happen. Renaming the issue and ignoring the prior functionality that's now not working correctly is the problem... please don't redefine the problem to say there's no problem.
(In reply to h.k.ghost from comment #10) > (In reply to farid from comment #9) > > Renamed issue > > I think this is a problem. Kdenlive had always worked with these files > without issues and it did so for years across several projects. I'm sure > that doesn't just magically happen. Renaming the issue and ignoring the > prior functionality that's now not working correctly is the problem... > please don't redefine the problem to say there's no problem. I was never aware that kdenlive imported xcf files. I tested myself prior to changing the task and in a project with various layers it will open only the first. What would be the ideal solution for you?
A solution I see would be to handle .ora files but the spec seems to have stalled. This would allow also importing krita projects as well. I don't think MLT can read xcf files properly, I will inquire some more.
(In reply to farid from comment #11) > (In reply to h.k.ghost from comment #10) > > (In reply to farid from comment #9) > > > Renamed issue > > > > I think this is a problem. Kdenlive had always worked with these files > > without issues and it did so for years across several projects. I'm sure > > that doesn't just magically happen. Renaming the issue and ignoring the > > prior functionality that's now not working correctly is the problem... > > please don't redefine the problem to say there's no problem. > > I was never aware that kdenlive imported xcf files. I tested myself prior to > changing the task and in a project with various layers it will open only the > first. What would be the ideal solution for you? As far as an "ideal solution" goes, I think Kdenlive properly handling the .xcf files from GIMP would be preferred. This would make working with the Kdenlive projects easier, especially when you have multiple .xcf files already imported but are also working on the .xcf files themselves. Updating the .xcf files in GIMP would get them updated directly in the Kdenlive project with less steps (e.g, file exports, moves, re-adding to timeline, etc). If this functionality had not been in Kdenlive before, I think I would've submitted a feature request a several years sooner (closer to 2013). This is when I started working on a separate project (on and off due to performance issues with Kdenlive) that led up to this bug report.
Changed to WISHLIST