I have been experimenting with the new Kdenlive KDE4 version from SVN and when I do a render it hogs the cpu to the point that I lose almost all GUI responsiveness for the entire Gnome desktop until the render is finished, and then everything returns to normal (also the sound stutters during this time). I have SVN versions of MLT, MLT++, and FFMpeg, so it might be those that are the issue. Is this psuedo-lockup something that other people are experiencing or is it something peculiar to my build(s) ?

Bill

I can't say if it is a problem of yours, but if you want to make it use less CPU during rendering, then perhaps use top to identify the process that eats all your CPU, then use renice to give it a lower priority.

Both top and renice are konsole programs - 'man top', 'man renice'.

No it is a problem. From my build last night kdenlive took down my Opteron box in a few seconds after hitting render. This was on a Fedora Core 9 install.

I say this is a problem since this same box hosts my comic that was on the fron page of Digg and Reddit at the same time and never went down.

same here on Debian Sid , kernel 2.6.26-1-amd64

latest 0.7beta1 and on the previous 0.5 unstable packages too.

I get this too. It's because inigo (the renderer) sets itself to SCHED_FIFO priority -99, so the scheduler gives it precedence over pretty much everything on the system. I have no idea why the author made it do this - it seems crazy to me. Fortunately it's easily fixed with the following patch:

Index: src/inigo/inigo.c

===================================================================

--- src/inigo/inigo.c (revision 1184)

+++ src/inigo/inigo.c (working copy)

@@ -324,14 +324,14 @@

char *name = NULL;

struct sched_param scp;

mlt_profile profile = NULL;

-

+ /*

// Use realtime scheduling if possible

memset( &scp, '\0', sizeof( scp ) );

scp.sched_priority = sched_get_priority_max( SCHED_FIFO ) - 1;

#ifndef __DARWIN__

sched_setscheduler( 0, SCHED_FIFO, &scp );

#endif

-

+ */

// Construct the factory

mlt_repository repo = mlt_factory_init( NULL );

In other words, just comment or remove those lines of code. Then recompile and reinstall the inigo binary wherever you previously had it, and it works fine. *sigh*

See also http://www.kdenlive.org/mantis/view.php?id=180