After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 639600 - [Pitivi] [gnonlin] Rendering hang up on file ~500, too many files opened
[Pitivi] [gnonlin] Rendering hang up on file ~500, too many files opened
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-editing-services
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on: 596849
Blocks:
 
 
Reported: 2011-01-15 14:16 UTC by Pablo Bueti
Modified: 2015-09-23 17:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Pablo Bueti 2011-01-15 14:16:00 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.
Comment 1 Jean-François Fortin Tam 2011-01-15 22:00:09 UTC
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).
Comment 2 Pablo Bueti 2011-02-11 20:56:53 UTC
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).
Comment 3 Edward Hervey 2011-02-12 10:28:20 UTC
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.
Comment 4 Jean-François Fortin Tam 2013-11-23 18:56:01 UTC
This is a job for GES' test suite now.
Comment 5 Nicolas Dufresne (ndufresne) 2013-11-23 22:25:40 UTC
I wonder how bad for transition it would be to put unused sources to NULL.
Comment 6 Thibault Saunier 2014-11-01 10:10:32 UTC
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 :/
Comment 7 Thibault Saunier 2015-09-23 17:10:55 UTC
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 :)