Version: 0.9.99 (rev. v0.9.10-250-g004a668) When I try to import the attached slideshow with the attached settings kdenlive crashes. The pngs were created by openshot's blender interface. Although I press the save button this clip is never saved. Sometimes I get as far as to drag it onto the timeline but then it says that the clip is not ready and crashes shortly afterwards. Reproducible: Always Steps to Reproduce: 1. Import Slideshow with the attached images and settings 2. Kdenlive crashes either immediately or shortly afterwards. Actual Results: Crash on import Expected Results: No crash on import I tried to get better information for this report but sad as it is arch does not seem to offer debug packages and so everything has to be built with the symbols enabled. I'm a law student so I#m using this AUR package to build kdenlive-frameworks from source as the manual process is a little bit out of my league. https://aur.archlinux.org/packages/kdenlive-frameworks-git/ After google-ing I found the the debug symbols outght to be enabled by changing "-DCMAKE_BUILD_TYPE=Release" to "-DCMAKE_BUILD_TYPE=Debug" https://wiki.archlinux.org/index.php/Debug_-_Getting_Traces#KDE_applications After I re-compiled I yanked it through gdb as described in the above link but it still found no debug symbols. [paul@pollux6 ~]$ LANG=C gdb /usr/bin/kdenlive GNU gdb (GDB) 7.8.2 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-unknown-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/bin/kdenlive...(no debugging symbols found)...done. (gdb) This worked so much nicer on Kubuntu with it's Crash handler... Any suggestions on how I could get you the debug trace?
Created attachment 90667 [details] Settings used to import
At the first (gdb) prompt, type "run", then reproduce the crash. When (gdb) prompt appears again, type "bt" to get the backtrace.
Created attachment 90703 [details] Image files used to create the slideshow
@ Jean-Baptiste Mardelle I just upgraded to Version 0.9.99 (rev. v0.9.10-251-ga544850) as I have seen that you improved the slideshow. Good news is, kdenlive does not crash anymore. Bad news is that although I can add the clip to the timeline now it remains black, as does the clip monitor and a rendered video. (see screenshot) @ Christoph Feck Thanks! But I don't think that would have got us any usable results as gdb didn't find and debug symbols.
Created attachment 90705 [details] Black screen after commit a544850
It works for me. Can you save the kdenlive project file containing the slideshow and attach it here?
Created attachment 90719 [details] Project File with black screen issue
My guess is that your MLT install is missing several modules. Can you go in: Kdenlive > Settings > Run Config Wizard Click Next on first screen and you will see a list of MLT components with their status. To correctly run Kdenlive you should at least have the avformat module and one image module (QImage or Pixbuf module) enabled. If you don't have an image module, you should recompile MLT to have the QImage module working - some config infos about that can be found here: https://community.kde.org/Kdenlive/Development/KF5#Compiling_MLT_with_Qt5_support
Jackpot: QImage, libdv and title module missing. As I mentioned before compiling stuff manually is a little over my head but I guess editing the packagebuild from the AUR might do the trick. I'm using this package: https://aur.archlinux.org/packages/mlt-qt5/ As far as I understand this adds the modules and compiles it afterwards. build() { cd "mlt-${pkgver}" ./configure --prefix=/usr \ --enable-glp \ --enable-glp3 \ --enable-opengl \ --disable-gtk2 \ --avformat-vdpau \ --qt-libdir=/usr/lib \ --qt-includedir=/usr/include/qt make } I also found this: https://kdenlive.org/forum/solved-mlt-080-fails-see-qt4-qimage-build-libs-when-present --qimage-libdir=/usr/lib/qt4/ --qimage-includedir=/usr/include/qt4/ Should do the trick but this is still for Qt4. What would I need for Qt5? I also noticed that he is using "glp" and "glp3" shouldn't that be gpl? I looked into the respective directories as instructed by the article you mentioned and I guess the paths on arch are /usr/include/qt/ and /usr/lib/qt5/ But in /usr/lib/qt5/ there is only one folder called plugins containing "phonon4qt5_backend" I'll try my best to get it working with those modifications. Is there maybe a better / easier platform to test on? I've seen that there are the sunab ppas for Kubuntu but they only cover the release and svn-master branches. Is there something similar for the frameworks branch? Thanks! Original issue presumably fixed by commit a544850
I got QImage to work now and the clip monitor no longer stays black but if I add the clip to timeline and hit space to play kdenlive hangs. (See screenshot) I'll also attached the konsole output.
Created attachment 90775 [details] Hang issue 1
Created attachment 90776 [details] Hang issue 2 with QImage
Created attachment 90777 [details] Hang issue 3
Created attachment 90778 [details] Konsole output of hang issue
I finally got debugging working. Attaching Konsole output and trace. Steps to reproduce hang: 1. Create new project 2. Add images to slideshow 3. Drag slideshowclip to timeline 4. Hit space to play 5. Hang
Created attachment 90780 [details] GDB Konsole output
Meh. Program terminated with signal SIGKILL, Killed. The program no longer exists. (gdb) bt No stack. (gdb) Where should the trace be?
Upgraded to Version 0.9.99 (rev. v0.9.10-254-g5102835) issue still persists and I still got no backtrace i guess as "thread apply all bt full" doesn't appear to have done anything. See attached kdenlive-trace.log What I did: 1. gdb kdenlive 2. set logging file kdenlive-trace.log 3. set logging on 4. run 5. Reproduce hang and kill 6. thread apply all bt full 7. set logging off 8. quit Thos two messages appeared before I killed kdenlive [Thread 0x7fffaa7fb700 (LWP 17343) exited] [Thread 0x7fffb586e700 (LWP 17365) exited]
Created attachment 90785 [details] Kdenlive Trace log
I was able to reproduce the issue with your images, thanks. For me, when trying to play the sequence in Kdenlive, it pauses after 2 frames, so the sequence is unplayable (but no crash). I posted a possible patch on MLT's mailing list, waiting for feedback. Can you test what happens on your side when trying to play the sequence with MLT? In a terminal, go to the folder where your images are, and type: melt ./.all.png ttl=1 That should normaly play the sequence, but probably hangs due to the MLT bug.
Same here: [paul@pollux6 f8193ea8-a549-11e4-b78e-002401ea064a]$ LANG=C melt ./.all.png ttl=1 QSettings::value: Empty key passed QSettings::value: Empty key passed +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ |1=-10| |2= -5| |3= -2| |4= -1| |5= 0| |6= 1| |7= 2| |8= 5| |9= 10| +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +---------------------------------------------------------------------+ | H = back 1 minute, L = forward 1 minute | | h = previous frame, l = next frame | | g = start of clip, j = next clip, k = previous clip | | 0 = restart, q = quit, space = play | +---------------------------------------------------------------------+ Current Position: 2 Speicherzugriffsfehler (Speicherabzug geschrieben) (= Memory access error (Memory dumped) ) After I pressed Ctrl-C Thanks so much for your help! If there's any way to send a beer or a bottle of Bordeaux your and your team's way, please let me know!
Dan Dennedy, the MLT maintainer pushed a proper fix for the issue in MLT. So if you can update to MLT's latest git, it should now work correctly (works for me). Thanks for your collaboration. And for the beer, we will try to organise a Kdenlive coding sprint this year, so when it is announced, you will be welcome to come see us or send something!
I'll glady support you guys with your sprint! ;) I can confirm that mlt plays the sequence but now kdenlive crashes again. This time though I got useful traces (at least I hope I do) --> kdenlive-trace-Version 0.9.99 (rev. v0.9.10-254-g5102835).log --> kdenlive-trace-Version 0.9.99 (rev. v0.9.10-259-gaa07c9d).log I'll also attach the project file --> slideshow5.kdenlive Steps to reproduce: 1. Start kdenlive 2. open slideshow5 3. Try to right click on it --> crash 4. Try to drag it to timeline without right clicking --> Hang
Created attachment 90840 [details] kdenlive-trace-Version 0.9.99 (rev. v0.9.10-254-g5102835).log
Created attachment 90841 [details] kdenlive-trace-Version 0.9.99 (rev. v0.9.10-259-gaa07c9d).log
Created attachment 90842 [details] slideshow5.kdenlive
I just fixed the right click crash but cannot reproduce the problem when inserting clip in timeline... Can you play the slideshow in clip monitor?
I'll try that right away, but it still crashes on the right click --> kdenlive-trace-Version 0.9.99 (rev. v0.9.10-261-g67e34eb).log
Created attachment 90844 [details] kdenlive-trace-Version 0.9.99 (rev. v0.9.10-261-g67e34eb).log
Clip monitor hangs as well.
Ok, right click crash should be really fixed now. I am surprised by the monitor hanging. Can you make sure that in the MLT upgrading process you don't have old versions of libmlt: ls -la /usr/local/lib/libmlt* (replace with correct install prefix if required) Should only list 0.9.3 libraries... Can you play normal video clips?
Jup, right click crash fixed in d724a38 MLT versions: [paul@pollux6 ~]$ ls -la /usr/lib/libmlt* lrwxrwxrwx 1 root root 15 31. Jän 22:28 /usr/lib/libmlt.so -> libmlt.so.0.9.3 lrwxrwxrwx 1 root root 17 31. Jän 22:28 /usr/lib/libmlt++.so -> libmlt++.so.0.9.3 -rwxr-xr-x 1 root root 775688 31. Jän 22:28 /usr/lib/libmlt.so.0.9.3 -rwxr-xr-x 1 root root 193184 31. Jän 22:28 /usr/lib/libmlt++.so.0.9.3 lrwxrwxrwx 1 root root 17 31. Jän 22:28 /usr/lib/libmlt++.so.3 -> libmlt++.so.0.9.3 lrwxrwxrwx 1 root root 15 31. Jän 22:28 /usr/lib/libmlt.so.6 -> libmlt.so.0.9.3 (While trying to create a new project I selected the wrong fps and wanted to change that before importing files in project preferences. At that moment kdenlive segfaulted. Should I file a new report for that? Because this one is already becoming the mother of all bug reports I guess XD ) Video files play but are very choppy (wasn't the case in 0.9.10) but kdenlive does not crash. There are many messages like this though: QXcbConnection: XCB error: 8 (BadMatch), sequence: 59052, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59094, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59095, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59131, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59170, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59226, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59257, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59317, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59357, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59366, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59418, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59480, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59543, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59605, resource id: 46137757, major code: 130 (Unknown), minor code: 3 QXcbConnection: XCB error: 8 (BadMatch), sequence: 59673, resource id: 46137757, major code: 130 (Unknown), minor code: 3 or this [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fffb800a0e0] overread end of atom 'colr' by 1 bytes [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fffb80139a0] overread end of atom 'colr' by 1 bytes [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7fffb80cde80] overread end of atom 'colr' by 1 bytes
I begin to suspect that the culprit is either mlt or arch. I did a clean install today with kdenlive version 0.9.10 stable and the same hang I described above happened here as well. Importing openshot/blender png always worked flawlessly under 14.04 LTS and OpenSuSE 13.2 Those distros are using mlt 0.9.0 and Arch at the moment is using 0.9.2 and I got 0.9.3-git on my other computer. Could this be another mlt issue like the one you found earlier?
Okay, I'm now certain that this is a mlt issue. I tried the exact same files on 14.04 and 15.04 and 15.04 hangs while 14.04 runs fine. Oddly enough when you drag the clip to timeline without playing it you can render the video just fine. Only playing the clip in the clip monitor triggers the hang.
Hmm, too bad. I thought the problem had been solved, but I can now reproduce the freeze when seeking the slideshow clip in latest MLT (0.9.4). I will investigate this week-end.
Good, then at least I'm not crazy ;) I just tested commit 5daeec6 from the 15.04 branch with the fixes. It's a lot better now. I can seek with the mouse and hit the play button on the clip monitor. Even spacebar works once, but when I try to use spacebar more than one time it still hangs. When it states 17% in ksysguard it means one of my six cores is at 100%. See --> slideshow-5daeec6.webm
Created attachment 91127 [details] slideshow-5daeec6.webm Shows the bettered hang issue after commit 5daeec6
Hey Jean-Baptiste, thank you so much for staying with me on this issue. I really appreciate it! Commit aae5fe4 further bettered the issue. The CPU hogging is now gone but kdenlive still goes irresponsive when I place the time slider at the beginning of the timeline and press spacebar. Strangely this does not happen everytime anymore. Sometimes it will play a few frames and then stop while staying responsive. Then it plays the whole clip again (although choppy) and then it goes irresponsive again. See --> slideshow-aae5fe4.webm
Created attachment 91147 [details] slideshow-aae5fe4.webm slideshow-aae5fe4.webm CPU hogging gone - Kdelive still irresponsive sometimes
Created attachment 91159 [details] MLT freeze patch Hi, Dan Dennedy, MLT's maintainer is currently testing the patch attached here. Seems to fix the problem for me, maybe you can try it ? That's a patch for MLT.
Hi, I just learned how to patch something ^^ This patch seems to do the trick for me too. No more hangs but playback is still a litte choppy and occasionally stops to continue one ore two seconds later, but this could be my laptop I'm testing on right now. Thank you so much JB! I don't know if I can make it to your sprint this year but give me a heads-up and I see if I can make it. In any case I'll send a few bucks your way. Even if I can't make it personally I'll make sure you and the others won't be thirsty!
Hi, I just found your messages in the mlt mailinglist and I thought I'd try the command you used there on the png files just to be sure melt ./.all.png ttl=1 out=50 -consumer sdl_preview Got me stuck in the middle at frame 50 everytime I tried --> mlt-hang.png This is of course with the above patch applied and could be related to the erratic playback I experience in kdenlive.
Created attachment 91163 [details] MLT getting stuck at frame 50
Your latest testing with melt is not clear that it is stuck. First, out=50 limits playback to frame # 50. It is supposed to pause/stop at 50! Secondly, melt does not close itself at the end by default; it pauses, exits, or keeps playing the last frame depending on the consumer. Also, if I am not mistaken at the moment, the sdl_preview does not always accept keyboard input from the video window, and you have to give the terminal window focus. Regarding the choppy playback, well, that's just the way it is with PNG, which is slow. If you want fast image sequences (optionally with alpha channel) then use TGA. Of course, that is going to be bigger.
Problem seems solved for me with Dan's recent commit. Paul, can you try Kdenlive with that patched MLT and see if you still have problems ? As Dan said, choppy playback is a consequence of the image producer and not related to the crashes/freezes you experienced.
Hey Dan, thanks for the clarification. As I mentioned earlier I don't have a technical background so this wasn't a critique or anything, just me not knowing the internals (in this case CLI and png handling) of mlt better. melt ./.all.png ttl=1 this command runs fine. Thanks for fixing this issue! Jean-Baptiste, with Dan's comment in mind I believe this issue is fixed. Thanks so much for your patience with me ;)