Spacer Tool (M) unworkable

Has anyone experienced the Spacer Tool crashing the application? Every single time I try to use it now, kdenlive exits immediately. I have tried moving clips from various locations in the app to see if it changes. As soon as I click to start the move, the app exits immediately. As an alternative workaround, I can Shift-select clips and move them that way. It works fine, but the Spacer Tool does not.

This problem has only started in the last day or so. The project I am working on has been worked on using various kdenlive versions over the past few months. I started using the latest version recently, and it was working fine, but only now has developed this problem. l am not sure if the amount of clips loaded (over 1,150) has any effect, but that’s all I can think about. Only a tiny fraction of them are used. I am using the latest appimage (24.05.0)

16GB ram.

System: Kernel: 6.6.11-amd64 [6.6.11-1~mx23ahs] arch: x86_64 bits: 64 compiler: gcc v: 12.2.0 parameters: BOOT_IMAGE=/boot/vmlinuz-6.6.11-amd64 root=UUID=<filter> ro Desktop: Xfce v: 4.18.1 tk: Gtk v: 3.24.36 info: xfce4-panel wm: xfwm v: 4.18.0 vt: 7 dm: LightDM v: 1.26.0 Distro: MX-23.2_ahs_x64 Libretto October 15 2023 base: Debian GNU/Linux 12 (bookworm)

CPU: Info: model: Intel Core i5-7300U

Graphics: Device-1: Intel HD Graphics 620 vendor: Dell driver: i915 v: kernel arch: Gen-9.5 process: Intel 14nm built: 2016-20 ports: active: eDP-1 empty: DP-1,HDMI-A-1,HDMI-A-2 bus-ID: 00:02.0 chip-ID: 8086:5916 class-ID: 0300 Display: x11 server: X.Org v: compositor: xfwm v: 4.18.0 driver: X: loaded: modesetting unloaded: fbdev,vesa dri: iris gpu: i915 display-ID: :0.0 screens: 1 Screen-1: 0 s-res: 1920x1080 s-dpi: 96 s-size: 508x285mm (20.00x11.22") s-diag: 582mm (22.93") Monitor-1: eDP-1 model: LG Display 0x0544 built: 2016 res: 1920x1080 hz: 60 dpi: 177 gamma: 1.2 size: 276x156mm (10.87x6.14") diag: 317mm (12.5") ratio: 16:9 modes: 1920x1080 API: OpenGL v: 4.6 Mesa 23.1.2-1~mx23ahs renderer: Mesa Intel HD Graphics 620 (KBL GT2) direct-render: Yes

Drives: Local Storage: total: 931.51 GiB used: 484.41 GiB (52.0%) SMART Message: Unable to run smartctl. Root privileges required. ID-1: /dev/nvme0n1 maj-min: 259:0 vendor: Kingston model: SNV2S1000G size: 931.51 GiB block-size: physical: 512 B logical: 512 B speed: 63.2 Gb/s lanes: 4 type: SSD serial: <filter> rev: SBM02103 temp: 33.9 C scheme: MBR

In 24.05 a new, faster spacer tool was introduced.

How many clips do you move with the spacer tool?
Does the memory get 100% filled while you move the clips with the spacer tool?

Does the spacer tool work with 24.02?

Does the crash happen when you open the project in an older Kdenlive version?

Thanks for responding, Eugen_Mohr

The memory isn’t close to being filled when it happens (plenty spare). The last crash had over 10GB free memory. I have just determined that I can move a small amount of clips (10-20) successfully, but even that is unreliable. Earlier I tried to move 4 clips (or something very low like that) and it would exit immediately too.

I am now running 23.08.5 appimage from the archives KDE - Experience Freedom! . The Spacer Tool works without fail (albeit slower).

In version 24.05.0. When moving clips backwards with the spacer tool: do they overlap existing clips? If yes, that could lead to a crash.

No, I would just move them to free space.

FWIW, I’ve been using it with a project with ~600 clips, most of them being used, spread over 3 sequences - even often sliding things around in middle tracks that are overlapped by content on the (locked) V7 and A3/A4 tracks…

And so far I haven’t been bitten by this, so it seems there’s something in your timeline or config that’s triggering this. Can you reproduce it with a more minimal project to narrow down what that might be?

That said, I’m also almost always using it to move things earlier in the timeline and remove space, not to add it, in case that also makes a difference.

Hi Ron. I might get the latest appimage again to see what it might be, but right now I am staying away from the latest version. I have to keep working on the project and am just happy that my Spacer Tool works. (though this version has some bugs in other areas)

Additional info: the unusable Spacer Tool problem occurs on earlier builds too!

I have no idea what’s going on, but I had 2 successful days editing with an earlier version of the app (23.08.4 because there was a showstopping bug on 23.08.5 with gradients). Anyway, the Spacer Tool works fine for those days and then - again - the app starts to exhibit “exit on first click” when using the Spacer Tool for no apparent reason. After that, it always happens and never stops being unusable. This is the exact thing that happened to me with the latest release earlier.

I have finally gone back to the latest build again, since I know this problem is not isolated to the latest build. I am now painfully selecting all the clips I need moved with Shift-click and Shift drag-with-mouse.

When the problem starts, does it happen if you use the spacer tool anywhere or only when trying to move some specific set of clips?

I’m not sure offhand what Eugen_Mohr saw in the code, but this seems to confirm my suspicion that it’s something Special about some group of your clips that is triggering this (and so far you do seem to be the only one reporting hitting it).

If you get some time to try and pinpoint this, make a copy of the project at a point where you know the problem happens, then start trying to simplify it (just keep deleting parts of it until the problem ‘goes away’) to try and put a ring around a minimal set of clips where removing anything else stop the problem from happening.

You should be able to eventually narrow it down to one clip group or effect which if present the problem occurs and if not it doesn’t. Knowing that should make the next step of trying to pin down the actual bug much easier.

If you have any clips using time remapping, I’d probably be especially suspicious of those.

It happens anywhere. I have the Spacer Tool active & as soon as I click to move, the app exits.

That’s a good idea. I am under the gun to get this done, but I will make a copy and investigate later.

Yes, some clips are time remapped (2.6x speed). Thanks for the suggestions. Oops, I meant “change speed”.

Fun thing about the autosave feature is that if you’ve got your project into some precarious state where it’s possible to trigger a bug that will crash the app and you waited just long enough before actually pulling that trigger - then when you recover the project, there’s a pretty good chance you’ll be right back in that state again - so performing the same action again will trigger the bug again, lather, rinse, repeat …

I got into a loop like that with a bug in the time remapping (cf. Time remapping crash with 24.02.2), and it took a few goes to figure out what was really happening and how to break that cycle.

So another interesting test if it happens again might be to move a few things around with a different tool, or do something different, then try the spacer tool again. Which I suspect is probably what happened one way or another when you changed the appimage version you were using, and it just took a while to get whatever the real cause is to align badly again and set up the conditions needed to manifest the bug.

Which might help you work around it a bit, but it would still be really nice to narrow it down enough to find and fix it properly. It might be a rare corner case, but you do appear to be proving it’s something repeatable about your project and not just random corruption causing this.

Ok, I have found a way I can reproduce this - though I don’t know if it is the same as what barry is seeing.

Using the 24.05.0 appimage:

If I try to move a video clip left with the spacer which would also move a subtitle in the track above it, then kdenlive repeatably crashes. If I move a clip with it that is to the right of all subtitles then it’s fine, likewise if I lock the subtitle track I can move the otherwise offending clip without problem.