What is your Shotcut version (see Help > About Shotcut)? Is it 32-bit?
22.10.25, also on beta and some older versions, this is not really new
Can you repeat the problem? If so, what are the steps?
After reaching a point in the project where there’s quite a bit of cuts, the undo function starts to take unbearably long to the point that it’s basically faster to close and reopen the file (I save very often).
I am aware that my project is arguably a bit more complex than average but my thinking is this: if I cut a clip (Ctrl+X) and then paste it in place (Ctrl+V), it should basically take the same processing as Ripple delete (X) then Undo (Ctrl+Z) barring some hidden housekeeping (in my case the nearby marker got deleted, undo would have fixed this) - but the first action is basically sub second yet undo takes about 33s so something doesn’t look right here.
If I undo something at the begining of the timeline it takes longer than something at the end.
If I undo a Lift (so no need to ripple all the timeline) it is very fast.
This is my 36 min timeline with 493 clips over 4 video tracks (actually 2 video and 2 photo only) and 1 audio
I’ve searched the forum and it doesn’t seem to be a lot of discussion around this, maybe it is just me but it’s been happening to all my project files proportionally to their length/complexity.
Edit: just realised a way better report would have been the reverse: undo-ing an insert with ripple enabled, basically the “ripple delete” action of a clip when done by undo takes 30s in this situation.
I also find the undo feature provides me with an endless supply of frustration. it doesn’t take long before the undo feature takes a very long time (>5 seconds) and will occasionally cause the program to freeze up and crash.
It is common when I get around 50% of the way of doing cuts to a 40+ minute recording that the undo feature takes about 15+ seconds to complete and I’ll crash the program if I’m not patient and click or try to do other things.
this most recent time, it actually caused a memory issue and gobbled up all my ram before crashing 2 minutes later.
It seems the number of files used, the amount of subclips and possibly using up more tracks + ripple increses the time to process the undo. I do not have the memory issue you mention, or at least I don’t notice it as I have plenty of free RAM, the biggest project I had hovered around 8-12gb of used RAM which is fine compared to the amount of stuff loaded up in it.
The sort-of workaround I started using is to split the project into multiple .mlt, each of maximum 15-20mins, this seems to work well enough to not be so frustrating.
I see I mentioned this in my initial post but I eventually noticed reopening the entire project takes about the same time as the undo which makes me think some cases of Undo (like with ripple delete) under the hood do some sort of full file checks or project validation just like when opening from scratch which is probably the root issue here.
Some operations take a snapshot of the tracks (entire track’s contents) that were affected and then restores them on undo since that is the safer code than adding a lot of complex logic that significantly increases the chance for bugs. When you have Ripple All Tracks turned on as shown here, that increases the coverage accordingly.
