Created attachment 115605 [details] Backtrace of the Kdenlive crash, includes additional info SUMMARY Kdenlive crashes when attempting to add a clip to a new project. The program just closes abruptly. Reproducible always. STEPS TO REPRODUCE 1. Open KDEnlive and click File -> New 2. In the Project Bin pane, click the "Add Clip" button. The Open File window opens. While browsing through to select some file, Kdenlive crashes unexpectedly. OBSERVED RESULT Kdenlive crashes unexpectedly, the application closes immediately, it's not possible to even get the clip added. EXPECTED RESULT The program should not crash while browsing for a clip to be added to a new project. It should just allow to browse, select a file and add it to the project. SOFTWARE VERSIONS KDE Plasma Version: plasma-desktop 4:5.12.6-0ubuntu0.1 KDE Frameworks 5.44.0 Qt 5.9.5 (built against 5.9.5) The xcb windowing system ADDITIONAL INFORMATION kdenlive version: 4:18.04.1+git201805021218~ubuntu18.04.1 Graphics Processor: GeForce GTX 1050 Ti Nvidia driver version: 390.77 When run via terminal, same problem, and the output to the console includes the following: " ... kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "" kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "" kf5.kio.core: Refilling KProtocolInfoFactory cache in the hope to find "" ERROR: Caught a segmentation fault while loading plugin file: /usr/lib/x86_64-linux-gnu/gstreamer-1.0/libgstlibav.so Please either: - remove it and restart. - run with --gst-disable-segtrap --gst-disable-registry-fork and debug. (kdenlive:3126): GStreamer-WARNING **: 18:31:19.848: Trying to join task 0x7ff510009050 from its thread would deadlock. You cannot change the state of an element from its streaming thread. Use g_idle_add() or post a GstMessage on the bus to schedule the state change from the main thread. (kdenlive:3126): GStreamer-CRITICAL **: 18:31:19.848: Failed to deactivate pad mpegaudioparse0:sink, very bad QObject::startTimer: Timers cannot be started from another thread QObject::killTimer: Timers cannot be stopped from another thread QObject::startTimer: Timers cannot be started from another thread QObject::startTimer: Timers can only be used with threads started with QThread Fatal Error: Accessed global static 'Phonon::FactoryPrivate *globalFactory()' after destruction. Defined at /build/phonon-ZAq3VA/phonon-4.10.0/phonon/factory.cpp:90 KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = kdenlive path = /usr/bin pid = 3126 KCrash: Arguments: /usr/bin/kdenlive KCrash: Attempting to start /usr/lib/x86_64-linux-gnu/libexec/drkonqi from kdeinit sock_file=/run/user/1000/kdeinit5__0 [1]+ Stopped kdenlive " The crash can be reproduced every time. IMPORTANT: The KDE Crash Reporting Assistant failed multiple times (as always "unexpected error 143.. protocol died...") So it is impossible to send the report with that thing. So I am creating this manually, which is a very time costing effort. I am adding the backtrace as an attachment.
I’m not a Linux specialist. Try the following: Restart your system (switch off, switch on). Then update Linux. Maybe there are some parts missing. sudo apt-get update sudo apt-get upgrade sudo apt-get dist-upgrade And then try with Kdenlive AppImage 18.08.2
(In reply to emohr from comment #1) Thank you for your contribution. Unfortunately, this happens regardless of how up-to-date this system is (updated daily, sometimes twice a day). The good thing about Linux is that it doesn't suffer from the kind of issues one see in certain commercial Operating System since 30 years, in which the switching off and then on again ritual seem to somehow "cure" the oddest bugs. The bad thing about Linux is that there are so many ways to package your source code, that developers end up having a huge ecosystem of distros to package for, and then they fail to properly follow up on all of them. On top of that, some projects also fail to have their main webpages updated. The Kdenlive package that I have installed, is the current version in the Ubuntu repositories. Guess what, it's very dated: v18.04.01, compared to what I see is the latest release (18.08.2). To make things muddier than mud, the Kdenlive download page, in the "Ubuntu" section, says (quote as of the time of this post in https://kdenlive.org/en/download/, 2018-10-19T20:14:18.867Z): "It is recommended to download the AppImage version until the release of Ubuntu 18.04.". Well, two possible comments to that: 1) "Just use the Appimage, why complain?" Or...2) "Ubuntu 18.04 has been released 6 months ago, so I am good to use the normal repo." Now: who is right? We could be arguing for long time, but let's agree on this: If the documentation is confusing/outdated/obsolete... how can users know what is right without double checking every page against other pages, news, blogs, forums or whatever? Turns out there is some "News" page (which other projects call different names or simply don't have) mentions the new releases. I don't care for "news" pages except real world ones. But again: I have hundreds of applications that I need to update, besides the system's. Users seem to be expected to read all the "News" of all their applications, in pure Windows 95, 198x style. But then, since one couldn't trust the documentation anyway, one would be forced to double check through hundreds of webpages. Or... spend spend time writing bugs reports about obsolete things nobody should be using or caring. I am truly sympathetic with the F.O.S.S. developers, I do. But _precisely_ because of that, I know that the best projects are very difficult because they do handle the difficult part (the wild ecosystem) well. Not because they have a lot of resources. But because the do communicate the essential efficiently. If a project doesn't do the basic stuff reasonably, then we get a ridiculous situation like this: A fool writing a bug report on an obsolete package, wasting his and others time, plus polluting the kde bugs system. That's a shame, dear devs. Either update your documentation or don't document at all. You can only maintain or increase your users base if you help them do the basic: install, upgrade in time, not too late. Anything else is irrelevant if this is not done properly, you know? There is no point in offering code without helping people to avoid using obsolete one. Is there anyone around still convinced that basic installation/upgrading documentation is a luxury in the F.O.S.S. world? I am not going to start reading the Kdenlive news every morning together with my real world News sources. And I have not even tried the appimage version, nor I am very excited to try it right now, regardless of the bug existing or not.
Thank you for your detailed feedback. As you mentioned there are 2 points: 1. The download page is misleading -> I have informed the Dev team about and they going to update the download page. 2. Linux ecosystem/derivate -> The Dev team going to thinking about to have only 1 or 2 download types (AppImage / Flatpack). I’m working with a Windows system but I see it like you: So many possibilities to pack/compile the source code on Linux leads to a lot of problems. Would you be so kind and check if with the actual Kdenlive AppImage 18.08.2 the problem still exist. Run the Appimage from the terminal (press CTRL + ALT + T). Move to the AppImage folder and run the .AppImage: ./Kdenlive*.AppImage. This to see if there some errors.
(In reply to emohr from comment #3) Thank you indeed for your prompt reply and understanding. I will try the appimage as you suggest. It might take me a little while, though, since I am currently quite busy with studying for a hard exam/interview. However, let me already provide yet another important but frustrating news about Kdenlive. I have just seen that this morning finally there has been released the Kdenlive package Version: 4:18.08.2+git201810211954~ubuntu18.04.1 for ubuntu 18.04 in the Kdenlive PPA repository. It's only 12 hours old. I immediately tried to install it, (although I shouldn't because of priorities). The excitement died immediately. The installation of Version: 4:18.08.2+git201810211954~ubuntu18.04.1 for Ubuntu 18.04 fails because kdenlive: Depends: libmlt++3 (>= 6.10.0+git201810170323~ubuntu18.04.1) but 6.6.0-1build1 is to be installed Depends: libmlt6 (>= 6.10.0+git201810170323~ubuntu18.04.1) but 6.6.0-1build1 is to be installed In Ubuntu 18.04, the libmlt6 package, (required by libmlt++3) is an older version than the one required by libmlt3++. So the required libmlt6 v6.10 or greater, is what exists for Ubuntu 18.10. In other words, a mess with the package. Neither the PPA, nor the regular ubuntu repositories have the libmlt6 v6.10 or greater for ubuntu 18.04, so this is again another failed attempt. I hope that this mistake in the packaging gets fixed before other people with less knowledge or experience will fall into this trap and start ranting yet more about the Kdenlive project. Thanks again for all your support!
One additional comment in separate post. (In reply to emohr from comment #3) > 2. Linux ecosystem/derivate -> The Dev team going to thinking about to have > only 1 or 2 download types (AppImage / Flatpack). The tragic thing is that on one side alternative package system like appimage/flatpak/snaps (or even others) is that the "medicin", the "remedy" becomes an illness. Why? because now devs have to deal not with one universal systems (the dream), but with _many_ "universal" systems. So: what a dev does? But more important than devs are... users. Yes, without users, there are no projects, without projects, programming is only for personal fun (until your wife/mother/partner throws you out of home). Any dev that ignores that is a monumental fool and should change her/his life, perhaps to planting lettuce or something else, I don't know. Art without public is useless and futile. My point is: I don't think it is an intelligent move to abandon the Debian/Ubuntu/Mint/etc. ecosystem package system. It's not about equality/democracy, etc. It is about practicality and pragmatism. What is the most popular, successful, technically superior packaging system of all times in Linux? I am sorry, but FOSS is a meritocracy. It's the... Debian packaging system, by far, far, far, far away. It only takes a couple of hours of deep investigation to become absolutely overwhelmed by the undeniable stability and superiority of the Debian packaging system. Period. How many packaging systems have Suse, Red Hat and others tried in the last 15 years? I can't even start to remember the name of whatever is today the command line to install a package in some of those. It's a matter of consistency. Consistency means stability. Stability is what people trust, at the end of the day. I am not talking about minorities. Not everybody wants really to be experiencing every other year some distro that may die or may decide to revolutionize once again their installation system. As for the "universal" solutions: well, ...they are not without problems. I am struggling since so many months to demonstrate why certain appimage is being built somehow wrongly for one of my favorite and most useful programs and though huge evidence, countless hours of experiments, reports, suggestions, etc., all I got so far is "doing it differently may break things for more people". Meanwhile, their ubuntu PPA repo offers so far a version that runs absolutely fine for all. If they would say that they are planning to switch to only appimage they will kill me and many others like me because their appimages fail catastrophically with professional hardware. Is that a solution to anything? They would push away people with fancy hardware, which would be suicidal. So Kdenlive will decide whatever they want. But I have also tried several flatpak "solutions" and it is not all fancy and dandy. It is a much more complicated and convoluted process and it is also by good measure an inferior method than appimages. Not because I say, but because countless credible, independent people with merit demonstrate. Again, take some time of Google time and critical mindset without emotions, to get to the same conclusion. Don't take my word for it. Use your own impartial criteria. Bottom line for a dev today? Either don't offer compiled packages and wait until "the next thing" is invented, or... bite the bullet and stay with the winning team: bet on the stable, solid and most popular solution. A winning team should not be changed just for fun. Keep Debian family on top of your list, not second. The, second place, I would definitely bet on appimage if you don't want to go for RPM packaging. On top of the rest of the pack, Arch and Gentoo, although those have their own special ways. This is not emotional, cannot be. Be practical: how many users you want to impress and get loyal to you: are there more Fedora users than Debian/Ubuntu family? what about Suse? what about Damn Small Linux? ....
Thank you for the crash report. As it has been a while since this was reported, can you please test and confirm if this issue is still occurring or if this bug report can be marked as resolved. I have set the bug status to "needsinfo" pending your response, please change back to "reported" or "resolved/worksforme" when you respond, thank you.
I just switched to Appimages, and haven't seen this particular error with those. It's been long time and that's now a very old version, I cannot test it any longer. I am changing the status to RESOLVED/WORKSFORME. Thank you so much for this excellent FOSS software.