Registered Member
|
On my debian laptop or gentoo desktop, I get a bunch of this. Random crashing with the nightly build and stable build. Here is what I see when I run kdenlive in a terminal. I'm editing 1080p video, x264 with crf=8 from a rawvideo camcorder stream at ultrafast preset, and using the default mpeg2 proxy preset for editing them. This is two clips side by side, one with audio, normalizing and pan audio effects being used. Editing is done from a raid 0 array of two SSDs on either machine, one is a dual core i7 laptop, the other is a six core i7 desktop.
Any ideas?
|
KDE Developer
|
Hello,
Those krashes don't seem random: the last log line is always "slotGetAudioThumbs". As workaround, try to disable thumbs in you options (empty startup project) then load you file. Then nightly build from 20150312 is KDE4 version right? |
Registered Member
|
Yes. That is strange, I have audio and video thumbnails turned off all the time. I'll try again and see what happens.
|
Registered Member
|
More random crashing, no thumbnails.
|
Registered Member
|
More random crashing fun.
|
Registered Member
|
Searching the Google for 'resource temporarily unavailable on x server' yields hits that imply you have a video-driver issue.
|
Registered Member
|
Hmm. This happens on Intel HD4400 graphics, fglrx graphics, and the generic ATI drivers without fglrx. I'm stumped.
|
KDE Developer
|
can you run "gdb kdenlive" then "run" and once the crash occured "bt full" and send us the result?
details about distro, kdenlive version, MLT version, libavcodec version? thanks |
Registered Member
|
In terms of kdenlive, I am using the latest nightly build from the build-kdenlive.sh script as of today, MLT 0.9.6. I dumped gentoo in favor of ubuntu studio just to see if wiping fresh would fix some issues on the desktop, same thing with stable kdenlive and kdenlive from nightly build script. I am likely running the bt full command wrong. I am an ignorant newbie when it comes to this kind of thing - my apologies. |
Registered Member
|
No need to be sorry. We appreciate your hanging in there while we try to diagnose your problem.
If you are using the build-kdenlive.sh script then you probably have a directory named ~/kdenlive/20150318. Within there will be a script named start-kdenlive. Running that script will bring up a window allowing you to run Kdenlive straight - or under GDB, the debugger. Try using that start script and see what happens. |
Registered Member
|
Still a dumb question! A simple read through of the start script would have revealed that, just shows how braindead I am being here.
I hope this is helpful. http://paste.ubuntu.com/10631001/
|
Registered Member
|
It's crashing in malloc. That's usually a sign of a corrupted heap - the dreaded memory leak This is happening within an MLT thread associated w/ playing out via SDL. The stack also implies that you have a transition going on (#19 & 21 in the thread trace)
Can you describe what you're doing in your video project? |
Registered Member
|
I'm editing one track of video, with a pan and a normalization plugin, along with one gamma plugin for color correction. I had a very short transition along with a jpeg picture for about ten seconds. With other videos, I ill hvae a project long transition between two video tracks, for a picture-in-picture kind of thing between one track of a camcorder, and another track of a microscope camera. This is the most complex it gets. https://www.youtube.com/watch?v=CPcwq4CS1EE https://www.youtube.com/watch?v=PtEDoMV5oe8 The memory leak is always present. If I try to play a video, or seek through a video without a proxy clip, it will run and use all 16 GB of RAM, go to 1000% CPU usage on a six core hyperthreaded processor, and stay there for 10 to 20 minutes before it finally allows me to seek/play video. I use proxy clips at the moment to make video editing usable. |
KDE Developer
|
Memory leak with daily built MLT? This should be reported to them!
Do you have it running only "melt [source_clip]"? What are the characteristics of the source clip? (resolution, codec...) (run "ffprobe [source_clip]") |
Registered Member
|
Yes, even with daily builds you will see it eats up all the RAM, then dies, then five minutes later it works and plays - until you try to seek again.
Here is some info on the clips.
|
Registered users: Bing [Bot], Google [Bot], kde-naveen, Sogou [Bot]