openshot-render never end

Bug #643151 reported by Tony Manero
26
This bug affects 5 people
Affects Status Importance Assigned to Milestone
OpenShot Video Editor
New
Undecided
Unassigned

Bug Description

command line renderer never exit, it creates output file without any problem but after call sys.exit() it hangs forever. Only way to stop it is to send a signal kill -1.
Some work around is to use return instead of sys.exit() where possible eg in function main in openshot_render.py
and in main program use os._exit(0) to force exit the script, instead throwing exception SystemExit with sys.exit().

Used OS: Linux Mint 9 based on Ubuntu 10.04, OpenShot 1.1.3

Revision history for this message
Olivier Girard (eolinwen) wrote :

Could you update àt the version 1.2.2 and tell us if , for the same operation, have you always this bug ?
Thanks.

Revision history for this message
Tony Manero (ased) wrote : Re: [Bug 643151] Re: openshot-render never end

I've tried also version 1.2.2, but it behaves in same manner.

2010/9/22 cenwen <email address hidden>:
> Could you update àt the version 1.2.2 and tell us if , for the same operation, have you always this bug ?
> Thanks.
>
> --
> openshot-render never end
> https://bugs.launchpad.net/bugs/643151
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in OpenShot Video Editor: New
>
> Bug description:
> command line renderer never exit, it creates output file without any problem but after call sys.exit() it hangs forever. Only way to stop it is to send a signal kill -1.
> Some work around is to use return instead of sys.exit() where possible eg in function main in openshot_render.py
> and in main program use os._exit(0) to force exit the script, instead throwing exception SystemExit with sys.exit().
>
> Used OS: Linux Mint 9 based on Ubuntu 10.04, OpenShot 1.1.3
>
> To unsubscribe from this bug, go to:
> https://bugs.launchpad.net/openshot/+bug/643151/+subscribe
>

Revision history for this message
Emelar (martin-rothbaum) wrote :

I've reproduced on version 1.3.1, and confirmed that changing sys.exit() to os._exit() works fine as a workaround. I've had a look around but can't see anything obvious that is intercepting the exception raised by sys.exit().

Andy Finch (fincha)
Changed in openshot:
milestone: none → 1.4.0
Changed in openshot:
milestone: 1.4.0 → 1.4.1
Revision history for this message
Jonathan Thomas (jonoomph) wrote :

Any thoughts on whether openshot-render is needed anymore? MLT already contains a powerful command line tool called "melt", which can render openshot XML files, and those XML files can be exported from OpenShot. Anyone disagree with me? =)

Changed in openshot:
milestone: 1.4.1 → 1.5.0
Revision history for this message
Emelar (martin-rothbaum) wrote :

I only managed to have a quick re-look at this, but I think something may still be missing. When editing a longer video, I tend to use individual OS projects for each segment (eg: items in a kids dance show). This allows isolated editing of each segment, and avoids introducing sync problems when editing changes the length of an early segment (I have two cameras, and use one track for each video and a single track for audio - this makes cutting between the cameras simpler).

Once I have made some edits to one or more segments, I then want to render the whole project from the command line, only rendering the segments that have changed (think make). If there was a way to do the export from the command line as well as the MLT render, then this would work. Otherwise I would have to remember to export each time I make an edit.

Many thanks
Martin

Revision history for this message
Marcin Owsiany (marcin-owsiany-pl) wrote :
Download full text (14.5 KiB)

Attaching with gdb in my case shows thread stacks such as below - Thread 1 is the main thread and Thread 2 is the thumbnailer.
Since the thumbnailer is not a daemon thread (is there a reason for this?) it prevents the Python interpreter from exiting.
Attaching a patch which fixes the hang for me.

(gdb) thread apply all bt

Thread 2 (Thread 0x7f1dd8817700 (LWP 28984)):
#0 0x00007f1de2e2e5b3 in select () from /lib/x86_64-linux-gnu/libc.so.6
#1 0x0000000000502a40 in floatsleep (secs=<optimized out>) at ../Modules/timemodule.c:943
#2 time_sleep.53112 (self=<optimized out>, args=<optimized out>) at ../Modules/timemodule.c:206
#3 0x00000000004b1764 in call_function (oparg=<optimized out>, pp_stack=0x7f1dd88166f0) at ../Python/ceval.c:4021
#4 PyEval_EvalFrameEx (f=<optimized out>, throwflag=throwflag@entry=0) at ../Python/ceval.c:2666
#5 0x00000000004b1f94 in fast_function (nk=<optimized out>, na=<optimized out>, n=1, pp_stack=0x7f1dd88168d0, func=<function at remote 0x2708aa0>) at ../Python/ceval.c:4107
#6 call_function (oparg=<optimized out>, pp_stack=0x7f1dd88168d0) at ../Python/ceval.c:4042
#7 PyEval_EvalFrameEx (f=<optimized out>, throwflag=throwflag@entry=0) at ../Python/ceval.c:2666
#8 0x00000000004b1f94 in fast_function (nk=<optimized out>, na=<optimized out>, n=1, pp_stack=0x7f1dd8816ab0, func=<function at remote 0x7f1de3c6f938>) at ../Python/ceval.c:4107
#9 call_function (oparg=<optimized out>, pp_stack=0x7f1dd8816ab0) at ../Python/ceval.c:4042
#10 PyEval_EvalFrameEx (f=f@entry=Frame 0x2afade0, for file /usr/lib/python2.7/threading.py, line 525, in __bootstrap (self=<thumbnailer(profile=<Profile(this=<SwigPyObject at remote 0x28a8b10>) at remote 0x28ac710>, c=None, _Thread__ident=139766163142400, p=None, _Thread__block=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x7f1de3d30e50>, acquire=<built-in method acquire of thread.lock object at remote 0x7f1de3d30e50>, _Condition__waiters=[<thread.lock at remote 0x7f1de3d30eb0>], release=<built-in method release of thread.lock object at remote 0x7f1de3d30e50>) at remote 0x28ac6d0>, _Thread__name='Thread-1', _Thread__daemonic=False, file_name='', _Thread__started=<_Event(_Verbose__verbose=False, _Event__flag=True, _Event__cond=<_Condition(_Verbose__verbose=False, _Condition__lock=<thread.lock at remote 0x7f1de3d30e30>, acquire=<built-in method acquire of thread.lock object at remote 0x7f1de3d30e30>, _Condition__waiters=[], release=<built-in method release of thread.lock object at remote 0x7f1de3d30e30>) at remo...(truncated), throwflag=throwflag@entry=0) at ../Python/ceval.c:2666
#11 0x00000000004b9158 in PyEval_EvalCodeEx (co=<optimized out>, globals=<optimized out>, locals=locals@entry=0x0, args=<optimized out>, argcount=<optimized out>, kws=kws@entry=0x0, kwcount=kwcount@entry=0, defs=defs@entry=0x0, defcount=defcount@entry=0, closure=0x0) at ../Python/ceval.c:3253
#12 0x00000000004b9cec in function_call.15272 (func=<function at remote 0x7f1de3c6f848>, arg=<optimized out>, kw=<optimized out>) at ../Objects/funcobject.c:526
#13 0x000000000047c9c4 in PyObject_Call (kw=0x0, arg=(<thumbnailer(profile=<Profile(this=<SwigPyObject at remote 0x28a8b10>) at remot...

Revision history for this message
Gregory Weber (spottedmetal) wrote :

Jonathan Thomas (jonoomph) wrote on 2012-01-29: #4

"Any thoughts on whether openshot-render is needed anymore? MLT already contains a powerful command line tool called 'melt', which can render openshot XML files, and those XML files can be exported from OpenShot. Anyone disagree with me? =)"

Yes, openshot-render is needed. See my comments 19 and 21 in Bug #729359.

For those of us with lots of small projects, it would be extremely useful to be able to do something like (shell script pseudocode follows):

for P in *.osp:
  if file $P.webm does not exist (or is older than $P):
    openshot-render --outputfile=$P.webm ... $P

But this is impossible when openshot-render does not terminate properly!

Revision history for this message
Lucio (lgvalent) wrote :

#3 worked for me, but I changed:

sudo xed /usr/share/openshot/openshot/openshot_render.py&
  sys.exit()
to
  os._exit(0)

I tried sys.exit(0), and didn't work for me.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.