I’m typically working on a self-compiled version of Kdenlive because it is the only way to get the UI integrate smoothly.
Now I have the problem that the rotoscoping is not shown in the preview (project monitor) but the effect is still there and fine if I render the project.
Unfortunately this very same issue does not occur in the app image but only in my self-compiled version. So it’s not a bug in that sense but has something to do with my build process.
My projects are huge and I heavily work with Kdenlive and because of that I can say that my build is absolutely stable and everything seems to work fine – except now the rotoscoping preview.
That’s probably a pretty safe bet. It’s usually the reason so many distro packages are so busted so often and we need to recommend people use the AppImage. Because some “maintainers” think they can just blindly rebuild stuff with whatever their distro currently ships without paying any attention to what we’ve tested it with - and then blindly ship that without any of their own testing.
Spoiler Alert - Well … no need for that, you’ve seen for yourself now what actually testing those builds can shake out : D
But this claim makes me curious:
I’m typically working on a self-compiled version of Kdenlive because it is the only way to get the UI integrate smoothly.
What exactly isn’t integrated about the “AppImage UI” that you need?
They aren’t something I’d recommend for every tool you use, but in the case of Kdenlive it lets us ship each release with exactly the required versions of the dependencies that is most critical for, but otherwise mostly works the same as a bare metal install. But more importantly, it also lets you most trivially keep multiple versions accessible, for if you ever need them to make a quick tweak to an older project.
And if you have any ongoing interest in the archive of your old projects beyond the number of likes on the rendered copy you uploaded, that is an advantage not to be lightly overlooked.
To be honest, I have to admit that the app image meanwhile really got very good and integrates well. Though I personally always preferred native solutions. Since I’m a developer myself I was never scared of building large projects
In the current release (app image 25.12.2) at least one font seems to be broken which makes it hard to read. Although I think that it accesses the system fonts, something is wrong (see screenshot below). I test this always in a clean VM before calling it out.
Are there anywhere instructions on how exactly the app image is built? Maybe I can learn something from it or could track down this issue more closely.
Likewise. And I have my own personal packaging that I use for testing development work - but for production use, when editing videos rather than hacking on the editor, I pretty much always use the AppImages for this one.
There’s a very short list of things I use them for, but this is the poster child for where it’s actually the Best Answer.
In the current release (app image 25.12.2) at least one font seems to be broken
Nobody on any other system is having trouble with this - but Ubuntu in general has always had a talent for being broken in ways that no other distro is.
Are there anywhere instructions on how exactly the app image is built?
I mark this thread as “solved” although I couldn’t figure out the root cause but have a workaround here.
The issue seems to be neither caused directly by Kdenlive nor by MLT. It is related to MLT but it seems to be some problem within libraries (which one?) delivered with the current Kubuntu 25.10. I didn’t test it on any other flavor.
So the solution is: don’t compile MLT on Kubuntu 25.10, just go with the packaged one. Compiling Kdenlive 25.12 is fine (requires compiling KDDockWidgets beforehand).
And of course, the Kdenlive app image works fine but you need to either delete or chmod 000 the file /etc/fonts/conf.avail/56-kubuntu-noto.conf to get the fonts right.
Side note why I started to fiddle with compiling MLT:
My basic approach always is to use native distro packages as much as possible. Since the kdenlive package in the (K)Ubuntu repo usually lags behind, I started to compile it for myself (long time ago).
When Kubuntu switched from 25.04 to 25.10 (which was a few weeks ago) it seemed that the MLT package was broken because it suddenly behaved strange and even segfaulted at times.
And this caused me to start to compile MLT as well. And last week I discovered this rotoscoping issue. Meanwhile the MLT issue of Kubuntu seems to be fixed which allows me to use the prepacked one again.
And yes, I know, there is Flatpak und Snap which may provide up-to-date versions of Kdenlive. But I consider both as pure system bloat.
So, actually the app image is definitely a good choice.
