Try again with the actual master: Index of /ci-builds/multimedia/kdenlive/master/windows . You can choose the 7z file to test as a standalone version.
Most important tip is: never upgrade any program in the middle of a project in production.
Second important tip is: Debian packaging is not the greatest for Kdenlive. Lotās of old packages which might cause issues.
I would suggest to try running the AppImage or Flatpak or change to Arch (which has been the most stable for running Kdenlive)
The OP is using the debian multimedia package archive, which is its own different can of worms. It tries to provide very up to date multimedia libraries and tools built for stable versions of debian - though historically not always completely successfully and not without some, letās go with friction, from the maintainers of some of those packages in debian proper.
I havenāt ever used his kdenlive packages, or his archive for a long time now, so I canāt vouch for the current quality of either - but it looks like heās maintaining his own packaging of kdenlive, so thereās at least opportunity of hope that they are of better quality than we often see from the ones shipping with the distro proper.
The OP is also using Debian Sid, which is the bleeding edge of new everything in the lead up to the next freeze for finalising a stable release, so right now itās actually probably full of newer stuff than Craft or the KDE build farm is using 
- though using both that and dmo together is an interesting choice.
The main problems we see with the stock Debian packages arenāt really that āDebian is Oldā - Iām doing all my kdenlive dev work on the current Debian stable release and have locally built packages that reliably work Just Fine - itās actually exactly the same problem we have with old mate from Suse and several other distros too. Those maintainers arenāt using and testing and engaging with us in the way youād naively expect someone calling themselves a āmaintainerā would be. Theyāre just grabbing source from us and if it builds with their old recipe, they ship it. Which might be semi-ok if their users were then reporting problems to them, keeping that a closed circle of slowly catching up to what theyād know if they were engaged with us - but they donāt. They come here, thinking that weāve broken something - or maybe just because we actually respond to them, even though we didnāt create their problem, and canāt solve it, because we didnāt break it.
If you want to run Sid and bleeding edge kdenlive and have the ability to seamlessly roll back to earlier kdenlive versions at any time - I would strongly recommend what Eugen suggested, that you use the official AppImages we release, and keep as many of the old ones around as you think you might need (and I would recommend you keep at least the ones youāve completed and released some project with if you think you ever might need to make some small change to that project again - because as Farid suggested, updating a project to a new kdenlive version can have unintended consequences you may need to do some extra work to deal with).
I maintain my own personal packaging of kdenlive for Debian, but I mostly only use it to build debs of unreleased versions for wider testing with changes that I havenāt upstreamed yet. For actual āproduction useā of my own video projects, I pretty much always use the AppImages on Debian (currently Trixie).
My collection of āevery AppImage I have ever usedā is still only about half the size of the raw footage I shot in the space of just over 2 hours yesterday, so thatās in the noise on the list of Things Burning Up My Storage Space faster than technology can double it in size again.
Edit: Oh, and X11 is generally still more functional than Wayland, there are a few things that Wayland does not fundamentally support yet - screen grab seemed to be the one getting most reported - but there have been a few other issues. Much of that is out of our control too - but the remaining issues will only get fixed if people test it and report them to the relevant developers too. So itās good youāre testing it if youāre the kind of person happy to run Sid on your daily use machine, but worth being aware of and ready to investigate.
So, first things first: Moving aside $HOME/.config/kdenliverc and letting it get rebuilt from scratch solved my problem. The main window opened, and the project loaded as expected.
Thanks for everyoneās suggestions. I will keep the AppImage option in mind. (Generally Iām not favorably disposed toward them, as itās little better than re-skinned DLL Hell.)
Iāve never been clear on what the āfrictionā is between DMO and Debian, because for me the DMO packages Just Work, and have done for well over a decade. I think I can count the number of times a DMO package caused problems on my fingers. One advantage of DMO is that, as all their mirrors are hosted outside the US, they donāt concern themselves with bullsh*t patent claims, and DMOās build of ffmpeg pretty much contains All The Codecs.
DMO repos also exist for Debian testing and unstable as well.
Iāve been learning a bit about the screen grab issue. In X11, any client can grab the whole screen. This has obvious security implications, and by default Wayland does not allow this. One primary component of negotiating client-grab permissions is a ādesktop portalā which needs to be installed, and which are often compositor-specific. Further, the compositor can be configured to grant or refuse grab permissions on specific clients ā for example, your password manager ā and that mechanism is also compositor-specific.
For myself, I havenāt tried screen-grabbing from Kdenlive yet (though OBS works fine).
Ok, thatās actually really interesting. Could you please open a bug report with both your old and new kdenliverc attached.
Thereās been a couple of reports now about it being slow, and another just came in about it being stalled after the welcome screen. But itās not universal, so thereās something in your old config that holds the next clue there.
Iāve never been clear on what the āfrictionā is between DMO and Debian
Iām not sure anyone is truly āclearā on that : ) Thereās an element of politics - and it might have come to one of several heads around the time of the acrimonious libav split too - but there is also some practical side to it. Some things like libav are linked to by many things, which in turn link with each other in various apps, and if you change the version of libav you have installed and donāt rebuild all of them to use it, then weird subtle and inevitably bad things eventually happen, sometimes not until long after youāve forgotten you have more than one libav version installed, and the cause is often initially not at all obvious. And IIRC some of the people involved were ostensibly (and not unfairly) annoyed at the number of bug reports they were having to deal with that after quite some work ended up being not bugs in their work at all, but the result of people āinnocentlyā (the internet told me to do it) mixing binaries from different sources incompatibly.
Iāve definitely seen that myself. Not for the first time but most recently when I initially started actually hacking on kdenlive I built it in a VM with all same deps that the official releases were using, which included a newer ffmpeg - and then it wasnāt until many many months later something unrelated started failing āimpossiblyā there, and it took much longer than Iād care to admit to finally trace that to things pulling in both the local libav build that I too had long ago forgotten about and the system one, and that going badly. And that was with both knowing what āimpossibleā looks like and knowing the risks of what Iād earlier done and watching and testing for them at the time Iād done it.
Thatās the main practical risk, particularly when ānon-developersā naively mix them together without any real understanding of what they need to be cautious about.
Mixing it with Sid was a little surprising at first, because the main value of DMO was as backports of newer things to stable releases - but Iād indeed be less surprised if he was in fact providing a better kdenlive package. I havenāt really looked at his beyond confirming he is repackaging it, but Iāve done my fair share of eyerolling at some of whatās shipped in the distro one from time to time, so itās probably a safe bet that he has too.
I will keep the AppImage option in mind. (Generally Iām not favorably disposed toward them, as itās little better than re-skinned DLL Hell.)
In the general case, Iām right with you on that one - and I maintain a fairly extensive private package repo of things and versions Iāve packaged for my own networkās needs, in addition to what I publish - but kdenlive is the sort of genuinely special snowflake where the appimage concept really does add value.
We use a lot of 3rd party libs to do the actual gruntwork that we present a nice UI for - so we canāt control when one of them might drop, or incompatibly modify, some effect or other things which you used in a project you created in 2021. The best we can do if you open that project in a newer version is to try and update it so that it is at least editable in the new version. but we cannot guarantee that simply rendering it, without any other changes, will look anything like what your originally rendered version did.
The only way to do that is to reopen it with exactly the same version of kdenlive (and all of the same core deps it used at that time). If you open it with a newer version, you have to accept that some things may be different, and it may take you some work to try to reproduce as best you can the look of what you originally did.
And trying to do that with natively packaged libs and apps is Hard. You either need to keep a VM in stasis at each of those versions, or implement something like snapshot.d.o and hope that upgrading (which is officially only supported between adjacent distro release versions) and downgrading (which isnāt offically supported at all) between the versions you need actually works - beside enduring the amount of time and other possibly unwanted side effects that comes with that each time you need to use another version, and you can still only use one version at a time.
With the AppImages though, you can just run whatever base of Debian stable/testing/unstable you choose to have the other things you need. And you can update that on whatever schedule otherwise suits you for those needs. But you can still choose the kdenlive version you want to work on any particular project. And you can do that instantly and painlessly, and even have multiple different versions open simultaneously if you need multiple projects open at the same time.
I definitely donāt think every app should be shipping as an appimage - for most of them their problem with downstream distros is just the same as with DMO, lack of communication, and politics. And maybe the lack of suitable people for the job. But for something like kdenlive, where strict version combinations really can matter for the end user, they might actually be the best and lightest weight tool that actually does the whole needed job.
In X11, any client can grab the whole screen. This has obvious security implications,
Yeah, but if youāve run a client which you wouldnāt trust to grab the whole screen, in an environment where what is on that screen has genuine security implications, then it being able to grab your screen is probably the least of the things about it that you should be worrying about.
Being security conscious is good - but being good at security is all about having the best understanding of your actual threat model.
I also tried the nightly build versions of Kdenlive. Compared to previous versions, the 25.12 versions take a very long time to open. Most of the time, after waiting a long time during startup, it freezes.
Problems with 25.12.0 on Manjaro Linux.
- Kdenlive no longer startsāyou must first delete kdenliverc.
- Many audio effects (Compressor/Expander (avfilter.compand), Crossfeed, Crystalizer, Deesser, Haas Stereo Enhancer, Limiter, Pan, Simple Compressor/Expander (avfilter.acontrast), Stereo tools, Stereo widener, etc.) distort the sound extremely.
- Not only on my main computer, but also on my older test computer: as soon as the major update to Manjaro and Kdenlive 25.12.0 is made, the sound is defective when one of these filters is inserted.
Do you have the latest MLT package in Manjaro?
I am using kdenlive on nixos, and a rebuild/upgrade I ran yesterday updated kdenlive from 25.08 (I think) to 25.12.0, and I was having your problem trying to open any existing project file (*.kdenlive). Here is how I was able to get past it.
I first started kdenlive without opening a project, and chose āNew projectā on the startup window - then kdenlive opened without hanging. It looked like most of my customizations and buttons were still there, but one thing missing was a custom layout I had created - there was no button for it in the upper right corner, with the other layout buttons.
So I rearranged the panels and re-created my custom layout, but there was still no layout button in the upper right corner to load it. If I had to enable some setting to see that layout button, I donāt remember what it was and canāt find it now. But I was able to add a toolbar button to load the custom layout, so that is ok.
Anyway, now all of my old .kdenlive projects open without hanging. I donāt know if just opening kdenlive first with a new project would have fixed this, or it was messing around with the custom layout that was the fix but it is not hanging for me anymore.
Yes, MLT 7.34.1. Downgrading Kdelinve or MLT does not improve the situation either. And: The Kdenlive-AppImages are all perfectly fine.
I have updated the Kdenlive Archlinux package with patches fixing many regressions. Hopefully Manjaro gets the updates soon as welllā¦
1 Like
Thanks, Farid, Iām looking forward to trying it out as soon as it arrives.
Which version is it? I just tried 25.12.0-5, (Repo auf Manjaro) but unfortunately I got the same audio error.
Am using the latest Linux Mint and the 25.12.0 Kdenlive. Cannot get the app to save
a new Layout. I save it, and when I re-open it, the layout is scrambled an unusable