GNOME Bugzilla – Bug 639600
[Pitivi] [gnonlin] Rendering hang up on file ~500, too many files opened
Last modified: 2015-09-23 17:10:55 UTC
I'm using the version 0.13.5 from the PPA "http://ppa.launchpad.net/gstreamer-developers/ppa/ubuntu" on Ubuntu 10.04 64 bits, kernel 2.6.32-27-generic. I've created a project with around 550 photos and 1 music track. When rendering, no matter what container/codec i choose, I get an error near the file number 500, which says "system error: Demasiados archivos abiertos", translated to English "system error: too many files opened". This is the output I see in the Terminal window executing Pitivi. Same error hanged the rendering always in the same photo number, with different codecs. Maybe files are not being closed during de rendering script. I tried rendering the same project with 400 photos and it finishes fine.
I'm pretty sure that's because you have reached the Linux kernel's "max open files" limit, which is 1024 by default. If you run: "ulimit -a" You will probably see that open files = 1024. As far as I understand it, this is a kernel limitation and there's nothing to be done about it on the pitivi side... (unless, as you hinted, there's some kind of magical way of "closing" files during rendering, but that doesn't seem to make sense because you'd have a project with closed files afterwards.) I'd be curious to hear the devs' thoughts on that. --------- While we're at it, 500+ photos on a timeline seems a bit crazy. Are you trying to do stopmotion animation? That would be bug #415360 (or there are apps that can do this for you and transform the sequence of images into a video clip).
True, ulimit -a gives me 1024 for open files. About the implementation, I'm sure developers can find a solution with knowledge about the cause. I was not making a StopMotion animation, just a birthday present with a sequence of photos with voice and music background. And 500 photos represent just a 20 minutes video in my case. I've seen this kind of present on many other birthdays and events,so is possibly not an unusual potential use for the application. About bug #415360 (enhacement) for what I see, is some kind related. But this is a bug for what actually is supposed to work, not a feature request. (In reply to comment #1) > I'm pretty sure that's because you have reached the Linux kernel's "max open > files" limit, which is 1024 by default. If you run: > > "ulimit -a" > > You will probably see that open files = 1024. > > As far as I understand it, this is a kernel limitation and there's nothing to > be done about it on the pitivi side... > > (unless, as you hinted, there's some kind of magical way of "closing" files > during rendering, but that doesn't seem to make sense because you'd have a > project with closed files afterwards.) > > I'd be curious to hear the devs' thoughts on that. > --------- > While we're at it, 500+ photos on a timeline seems a bit crazy. Are you trying > to do stopmotion animation? That would be bug #415360 (or there are apps that > can do this for you and transform the sequence of images into a video clip).
this bug is related to the fact that gnonlin doesn't put any contained elements back to the NULL state (where it would release memory and the opened file). It's similar to the memory usage bug related to rendering videos. Making this bug block against the relevant gnonlin bug. I'm working on this.
This is a job for GES' test suite now.
I wonder how bad for transition it would be to put unused sources to NULL.
OK, with the redesign of GNL, that bug does not exist anymore, but... when having many clips in the timeline, I am not getting X errors like: (pitivi:15938): Gdk-ERROR **: The program 'pitivi' received an X Window System error. This probably reflects a bug in the program. The error was 'BadValue (integer parameter out of range for operation)'. (Details: serial 18607 error_code 2 request_code 148 (unknown) minor_code 4) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the GDK_SYNCHRONIZE environment variable to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) zsh: trace trap (core dumped) pitivi test.xges Sounds like a bug in our beloved clutter/clutter-gtk or something :/
OK, that is fixed with the Gtk timeline, we can have many clips and play with them! (though it is very slow to add them to the timeline for some weird reason). Closing :)