Created attachment 131337 [details] Crash log for 20.08.0 Appimage SUMMARY When changing the speed for a clip, Kdenlive applies the effect, i.e. you see the clip's length change, but as soon as that happens, the application crashes and the change is lost. Reloading the project gets you back to where you were prior to changing the clip speed. STEPS TO REPRODUCE 1. Add a video clip to the timeline. 2. Right-click on the clip and choose "Change Speed". 3. Adjust the speed to a small number. It seems any number below 30% will cause the crash. This crash is also present in version 19.12.3, though I only checked the specific values in the 20.08.0 Appimage. OBSERVED RESULT App crash. EXPECTED RESULT Not an app crash. Only the clip's speed being adjusted to the given value. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 20.14 LTS AMD64 KDE Plasma Version: 5.18.5 KDE Frameworks Version: 15.68.0 Qt Version: 5.12.8 Kernel Version: 5.4.0-45-generic ADDITIONAL INFORMATION On step #3 above, I tested the values and observed these results: 110% = No crash 90% = No crash 50% = No crash 25% = Crash** 15% = Crash** 40% = No crash 30% = No crash 29% = Crash** It seems the crash occurs whenever any speed value smaller than 30% is used.
Created attachment 131338 [details] Crash log for 19.12.3 repo package I'm including this one because it seems to be more informative. It seems to be a double-free issue with a pointer: KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = kdenlive path = /usr/bin pid = 16377 KCrash: Arguments: /usr/bin/kdenlive free(): invalid pointer Unable to start Dr. Konqi Re-raising signal for core dump handling.
While trying to find a workaround the issue, so that I can continue my work, I discovered the following: As noted, the lowest speed value I had tried to set before was 15%, and it had crashed. I tried 10% and crash, as "expected", but I then tried a 5% instead (after reloading project, etc) and there was *no crash*. After that, I tried 10% again and other in-between values and no crash was observed. To recap, when you first start to change speed values, it's 100% by default. It seems like trying to set it to some value 10% >= x < 30% on the first try causes the crash, but if you go *below* under 10% immediately, the crash can be avoided for some reason. After you avoid it this way, it seems you're allowed to set the value to anything else without issues, but this is a lucky "workaround" I seem to have come across. Not sure how far it'll get me, though.
I forgot to mention, in this case, playing the clip causes the preview in the project monitor pane to not actually play the video. It remains as a still frame...
Unfortunately, the still frame is not an issue with the preview alone. If I render the project, it gets incorrectly rendered just as in the preview, with the still frame. It seems that this "workaround" simply avoids the crash, but there's more. Any speed value < 30% causes the "still frame" issue without crashing, but something does remain broken and affected other areas of functionality.
mlt commit 9499802f on 09.05 adresses cases of low speed crashing. can you test with 20.08.2 appimage?
(In reply to Vincent PINON from comment #5) > mlt commit 9499802f on 09.05 adresses cases of low speed crashing. > can you test with 20.08.2 appimage? I see a 20.08.1 appimage (i.e. kdenlive-20.08.1-x86_64.appimage), but not a 20.08.2. I'm looking in https://files.kde.org/kdenlive/release Is there a typo in your message, is the image actually missing, or am I looking in the wrong place?...
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 b/c instructions were unclear for user willing to test.
For the record, after updating to Kubuntu 20.10 earlier today, Kdenlive was upgraded to version 20.08.2. It still exhibits the crash.
Today, I saw a crash when setting the speed to 33%. Later, I set it to 35% and it didn't crash at that very moment, but it did crash as soon as I clicked/dragged the cursor on the timeline over the slow-motion clip. This was reported a 3 months ago and no one seems to be following up on it... I realize focusing on features is cool, but software that does not crash is better :o FWIW, I tried taking a look at the C++ code under src/timeline2/view/dialogs/speeddialog.{h|cpp}, as that place seemed to make sense (to me) and nothing stood out to me as "obvious". That said, chances are I'm looking in the wrong place anyway b/c I'm not familiar with the code-base ... PS: Changing status back to REPORTED b/c it now shows up in my list of status options ...
Created attachment 133796 [details] Crash log for 20.08.02 (apt based install Kubuntu 20.10) The program was launched from the terminal without any special arguments. A project was loaded and a clip's speed was set to 25%, which caused an immediate crash.
I've added yet another log. This appears to be the important part at the end, when setting a clip's speed to 25%. In the snip below, the "warp LENGTH before -379849" stands out because it has a negative number, whereas speeds that do NOT cause a crash show positive numbers: ==== CALCULATED SPEED DIALOG DURATION: 2616 requesting speed 25 timeWarp producer 0.25 changing speed 1015888 1016541 0.25 new producer: "timewarp:0.250000:/media/ray/Data/Streams/ShadowPlay/ArmA 3/ArmA 3 2020.11.28 - 19.23.25.05.mp4" warp LENGTH before -379849 warp LENGTH 1108304 ---------- ----------- // ADJUSTING EFFECT LENGTH, LOGUNDO true , 1015888 / 1015888 , 2616 qml: loaded clip: 49670 , ID: 81 , index: 4 , TYPE: AV qml: loaded clip with Astream: 1 timeWarp producer 0.25 changing speed 1015888 1016541 0.25 new producer: "timewarp:0.250000:/media/ray/Data/Streams/ShadowPlay/ArmA 3/ArmA 3 2020.11.28 - 19.23.25.05.mp4" warp LENGTH before -379849 warp LENGTH 1108304 ---------- ----------- // ADJUSTING EFFECT LENGTH, LOGUNDO true , 1015888 / 1015888 , 2616 qml: loaded clip: 49670 , ID: 127 , index: 3 , TYPE: AV qml: loaded clip with Astream: 1 KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = kdenlive path = /usr/bin pid = 30956 KCrash: Arguments: /usr/bin/kdenlive free(): invalid pointer Unable to start Dr. Konqi Re-raising signal for core dump handling. [1] 30956 abort (core dumped) kdenlive 2>&1 | 30957 done tee 2020-12-02_kdenlive.log This snippet shows a clip's speed being set to 80%, which shows a positive number, i.e. "warp LENGTH before 346344": ==== CALCULATED SPEED DIALOG DURATION: 818 requesting speed 80 timeWarp producer 0.8 changing speed 317465 318118 0.8 new producer: "timewarp:0.800000:/media/ray/Data/Streams/ShadowPlay/ArmA 3/ArmA 3 2020.11.28 - 19.23.25.05.mp4" warp LENGTH before 346344 warp LENGTH 346345 ---------- ----------- // ADJUSTING EFFECT LENGTH, LOGUNDO true , 317465 / 317465 , 818 qml: loaded clip: 49670 , ID: 81 , index: 4 , TYPE: AV qml: loaded clip with Astream: 1 timeWarp producer 0.8 changing speed 317465 318118 0.8 new producer: "timewarp:0.800000:/media/ray/Data/Streams/ShadowPlay/ArmA 3/ArmA 3 2020.11.28 - 19.23.25.05.mp4" warp LENGTH before 346344 warp LENGTH 346345 ---------- ----------- // ADJUSTING EFFECT LENGTH, LOGUNDO true , 317465 / 317465 , 818 qml: loaded clip: 49670 , ID: 127 , index: 3 , TYPE: AV qml: loaded clip with Astream: 1 LC_NUMERIC reset to C Both snippets are from the same clip in the same project. The only difference is the speed being set.
Thanks for your report and investigation. As you noted, the issue seems to come from the negative length reported at debug line: warp LENGTH before. This value is taken from the MLT timewarp producer, but I cannot reproduce the problem. My guess is that it may be related to the video file you are using. Can you test with other video files coming from another source ? If the problem is limited to one file, the best would be if you could share it (maybe the problem is still reproducible if you cut a few seconds of it with ffmpeg)?. Can you also tell us which project profile you are using, especially the fps.
Created attachment 133800 [details] Project Settings Dialog
> This value is taken from the MLT timewarp producer, but I cannot reproduce the problem. My guess is that it may be related to the video file you are using. Can you test with other video files coming from another source ? I have done this and it's reproducible. When I submitted the original report, I was working on a different project. I've worked on at least 5 other different projects with different sources/files and it has always been reproducible for me. > If the problem is limited to one file, the best would be if you could share it (maybe the problem is still reproducible if you cut a few seconds of it with ffmpeg)?. The problem is not limited to one file. > Can you also tell us which project profile you are using, especially the fps. The project settings dialog has "1920x1080@60.00 fps" on the left-most widget. The "Video Settings" to the right shows: Frame size: 1920 x 1080 (1920:1080) Frame rate: 59.9999 fps Pixel Aspect Ratio: 1 Color Space: ITU-R 601 Interlaced: no The "Preview Profile" dropdown menu has "DNxHD 1080p 30 fps". Please see attached.
Could you share the file? If so please upload a 3-5sec piece here which causes the crash so we can test.
(In reply to emohr from comment #16) > Could you share the file? If so please upload a 3-5sec piece here which > causes the crash so we can test. I cannot share the files. After I get done with my projects, I delete them due to space constraints. But I can tell you how to (re)produce the files: I use NVIDIA ShadowPlay to record everything I work with, usually game-related content. It's recorded at 1080p@60FPS. That's where the original project source video files come from.
Could you just record a short sequence with NVIDIA ShadowPlay and upload here so we could test.
Created attachment 134108 [details] NVIDIA ShadowPlay Clip I've attached a short video clip captured today with NVIDIA ShadowPlay, in Windows 10. Note that I had updated my NVIDIA drivers recently (within the last 5-7 days or so) and that other GNU+Linux system updates have also been applied in the meantime... (I have a dual-boot system; all recording is done in Windows 10, but all editing is done in Kubuntu.) I avoided installation of a new driver version released today (2020-12-15) just to record this 3-second clip. That said, I was unable to reproduce the issue with this particular clip before uploading. I also tried with a few videos I had recorded at the end of November and early December with older ShadowPlay/NVIDIA driver versions (in Windows 10), but was again, unable to reproduce today. (Those other videos are several GBs, so even if I had been able to reproduce the issue in them, they're not an option for attachment uploads.) Basically, there're several variables at play here, including kdenlive, kdenlive dependencies, different NVIDIA ShadowPlay versions and the .MP4 video files it produces, and so on... what I can note here is that **I followed the same process** I normally have as a Kdenlive user, from the way I record every video to how it gets added to, and is processed by, Kdenlive itself - i.e. I made no manual changes to the system/kdenlive/shadowplay settings for this video recording. Also note that, in most cases, Kdenlive shows me a prompt with the following message/question: No profile found for your clip. Create and switch to new profile (1920x1080, 60.00fps)? Profile fps adjusted from original 59.9998 Every time I get it, I always choose to change to the new/suggested profile. I don't know if this makes a difference, but I figured I'd mention it. PS: I had to compress the 3-second clip to upload, b/c even at 3-seconds, it was ~4.8MBs.
Update: I was able to reproduce the issue with an even older clip I had recorded. The recording is from Sept. 27, 2019 (yes, over a year old - but not deleted b/c I had not used it for anything yet). The almost 5-and-a-half minute video is 1.8GB, though...
Created attachment 134109 [details] Kdenlive Profile Prompt Regarding my last update, something different I noticed was the prompt I was presented with by Kdenlive. Instead of asking me if I wanted to use a 60.00fps profile, it asked for a 59.98fps profile: No profile found for your clip. Create and switch to new profile (1920x1080, 59.98fps)? Profile fps adjusted from original 59.9783 It seems even the original fps sometimes varies, as shown above with .9783 instead of .9998. I accepted, and after changing the clip's speed down to 20%, Kdenlive crashed.
Please test the following: open a new project with 1920x1080 60fps. Insert a clip in the project bin and answer the pop up question with no. Put it on the timeline and test different speeds.
Created attachment 134224 [details] Kdenlive Profile Prompt #2 (Rejected) I opened Kdenlive, verified I already had the 1920x1080p@60FPS profile, and then added a video that has crashed for me before. When I got the profile change prompt from Kdenlive (see new attachment), I rejected it with Cancel and then moved the clip into the timeline. I tested different speeds including 50%, 20%, 15%, 10%, 25%. I did not observe a crash. Everything appeared to continue working normally.
Created attachment 136391 [details] No profile I downloaded the attached video and upon importing it I got the following prompt. Wether I continue or cancel I am unable to reproduce the crash. Could you please test with the latest daily builds and see if you can reproduce?
(In reply to farid from comment #24) > Created attachment 136391 [details] > No profile > > I downloaded the attached video and upon importing it I got the following > prompt. Wether I continue or cancel I am unable to reproduce the crash. > > Could you please test with the latest daily builds and see if you can > reproduce? Since I'm not sure where, exactly, to find the daily builds (see my prior responses asking for proper locations), I went ahead and tried this version: https://files.kde.org/kdenlive/release/kdenlive-20.12.1c-x86_64.appimage I made a few attempts, but did not observe the problem this time. Note that the reproducibility of this issue has not always been consistent...
(In reply to h.k.ghost from comment #25) > (In reply to farid from comment #24) > > Created attachment 136391 [details] > > No profile > > > > I downloaded the attached video and upon importing it I got the following > > prompt. Wether I continue or cancel I am unable to reproduce the crash. > > > > Could you please test with the latest daily builds and see if you can > > reproduce? > > Since I'm not sure where, exactly, to find the daily builds (see my prior > responses asking for proper locations), I went ahead and tried this version: > https://files.kde.org/kdenlive/release/kdenlive-20.12.1c-x86_64.appimage Great so the issue is not in the latest stable nor in the daily builds: https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/lastSuccessfulBuild/artifact/ > > I made a few attempts, but did not observe the problem this time. Note that > the reproducibility of this issue has not always been consistent... I would suggest to close the issue then if you don't mind and reopen it if you ever encounter the crash again. Cheers.
(In reply to farid from comment #26) > (In reply to h.k.ghost from comment #25) > > (In reply to farid from comment #24) > > > Created attachment 136391 [details] > > > No profile > > > > > > I downloaded the attached video and upon importing it I got the following > > > prompt. Wether I continue or cancel I am unable to reproduce the crash. > > > > > > Could you please test with the latest daily builds and see if you can > > > reproduce? > > > > Since I'm not sure where, exactly, to find the daily builds (see my prior > > responses asking for proper locations), I went ahead and tried this version: > > https://files.kde.org/kdenlive/release/kdenlive-20.12.1c-x86_64.appimage > > Great so the issue is not in the latest stable nor in the daily builds: > https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/ > lastSuccessfulBuild/artifact/ > > > > I made a few attempts, but did not observe the problem this time. Note that > > the reproducibility of this issue has not always been consistent... > > I would suggest to close the issue then if you don't mind and reopen it if > you ever encounter the crash again. Cheers. I'd like to wait until I do some actual work with this or newer versions before I go ahead and close it. When issues get fixed "magically" without no one showing up and saying "I found the root cause of the problem, it was X, the fix was Y, and it's in commit Z", I tend to be a bit more cautious. Cheers.
(In reply to h.k.ghost from comment #27) > (In reply to farid from comment #26) > > (In reply to h.k.ghost from comment #25) > > > (In reply to farid from comment #24) > > > > Created attachment 136391 [details] > > > > No profile > > > > > > > > I downloaded the attached video and upon importing it I got the following > > > > prompt. Wether I continue or cancel I am unable to reproduce the crash. > > > > > > > > Could you please test with the latest daily builds and see if you can > > > > reproduce? > > > > > > Since I'm not sure where, exactly, to find the daily builds (see my prior > > > responses asking for proper locations), I went ahead and tried this version: > > > https://files.kde.org/kdenlive/release/kdenlive-20.12.1c-x86_64.appimage > > > > Great so the issue is not in the latest stable nor in the daily builds: > > https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/ > > lastSuccessfulBuild/artifact/ > > > > > > I made a few attempts, but did not observe the problem this time. Note that > > > the reproducibility of this issue has not always been consistent... > > > > I would suggest to close the issue then if you don't mind and reopen it if > > you ever encounter the crash again. Cheers. > > I'd like to wait until I do some actual work with this or newer versions > before I go ahead and close it. When issues get fixed "magically" without no > one showing up and saying "I found the root cause of the problem, it was X, > the fix was Y, and it's in commit Z", I tend to be a bit more cautious. > > Cheers. Ok, fair enough. Next big release is 21.04 due next month hope you can try it till then. Will mark this as needs info so we can come back to it after a while. We are undergoing an initiative to clean out tracker as it is saturated with old bugs.
(In reply to farid from comment #28) > (In reply to h.k.ghost from comment #27) > > (In reply to farid from comment #26) > > > (In reply to h.k.ghost from comment #25) > > > > (In reply to farid from comment #24) > > > > > Created attachment 136391 [details] > > > > > No profile > > > > > > > > > > I downloaded the attached video and upon importing it I got the following > > > > > prompt. Wether I continue or cancel I am unable to reproduce the crash. > > > > > > > > > > Could you please test with the latest daily builds and see if you can > > > > > reproduce? > > > > > > > > Since I'm not sure where, exactly, to find the daily builds (see my prior > > > > responses asking for proper locations), I went ahead and tried this version: > > > > https://files.kde.org/kdenlive/release/kdenlive-20.12.1c-x86_64.appimage > > > > > > Great so the issue is not in the latest stable nor in the daily builds: > > > https://binary-factory.kde.org/job/Kdenlive_Nightly_Appimage_Build/ > > > lastSuccessfulBuild/artifact/ > > > > > > > > I made a few attempts, but did not observe the problem this time. Note that > > > > the reproducibility of this issue has not always been consistent... > > > > > > I would suggest to close the issue then if you don't mind and reopen it if > > > you ever encounter the crash again. Cheers. > > > > I'd like to wait until I do some actual work with this or newer versions > > before I go ahead and close it. When issues get fixed "magically" without no > > one showing up and saying "I found the root cause of the problem, it was X, > > the fix was Y, and it's in commit Z", I tend to be a bit more cautious. > > > > Cheers. > > Ok, fair enough. Next big release is 21.04 due next month hope you can try > it till then. Will mark this as needs info so we can come back to it after a > while. We are undergoing an initiative to clean out tracker as it is > saturated with old bugs. I worked yesterday on a small project that included changes in clip speeds and did not observe the issue, either. It seems like it can be closed as resolved/fixed. If I encounter it again, I'll reopen.