Comment 5 for bug 403154

Hello Jonathan,

Yes this still happens with 0.9.8 all installed from .deb packages. The
only bit that I've had happening is the freezing of the viewport whilst
playing. Still the same effects on System Monitor.

One difference (caused I think by the different way of launching
Openshot with a sh script) is that the process doesn't die when I kill
OpenShot. I have to kill the terminal window as well before the 100%
process dies.

This is a menace because it is making it difficult for me to edit the
circus film projects I am working on.

I can reduce the chances of a freeze if I first drag the cursor all the
way along the timeline before trying to play it. I have a niggling
feeling that this has something to do with one of the length attributes.
I was having so much trouble at first with the released form of 0.9.7
and 0.9.8 that I didn't manage to log all the bugs that occurred, but
several of them were giving error messages on the console relating to
length attributes.

The files I am working on for the circus project are all mp4 files
rendered by OpenShot from AVCHD clips from my camera. This technique was
working fine until version 0.9.7 when the freezes became too prevalent.
I was using 0.9.4 before that.

Helen

On Mon, 2009-07-27 at 13:55 -0500, Jonathan Thomas wrote:
> Helen,
> The processors switching between 100% from CPU 1 to CPU 2, etc... are
> probably happening based on how the Linux kernel handles multiple
> processors. The CPU selection happens on a much lower level than what
> I'm doing in Python. However, there is obviously a problem with
> OpenShot maxing out at 100% CPU.
>
> Can you recreate this behavior using the new version you installed
> with .DEB files?
>
> On Thu, Jul 23, 2009 at 5:57 PM, Helen McCall
> <email address hidden> wrote:
> Wow! This test with the system monitor has woken me up from my
> tired
> state.
>
> The video files are all on a "projects" partition on one of my
> internal
> harddrives (SATA2). I ran the subsequent tests with only
> OpenShot,
> System Monitor, and Evolution running.
>
> I monitored first: The clip freezing in the viewport, but
> leaving
> Openshot still working in all other respects.
>
> Prior to this viewport freeze, all processors had their loads
> reasonably
> evenly spread with activity in the middle ranges for all of
> them.
>
> When the viewport froze, one processor went up to 100% and
> just stayed
> there like it was in a never ending loop. The other two
> processors went
> down to a low level of load around 10% or lower. Any activity
> like
> moving the timeline curser or opening a dialogue window caused
> the two
> low level processors to increase their activity a little.
>
> The only thing I found which changed this situation was to
> open a
> file-selection dialogue for importing a clip. This caused the
> 100%
> processor to swap with one of the other processors, so that a
> different
> processor was stuck at 100%, and the original high load
> processor was
> now one of the pair of low load processors!
>
> Second test: Openshot freezing completely on opening the
> project I sent
> you. This did the same thing and caused one processor (#2) to
> go to
> 100%, and the other two (#1 & #3) to go to very low load.
>
> I couldn't use the Openshot file-selection dialogue, so I
> opened gedit.
> no activity on that or on the terminal window affected the
> state of this
> #2 100% processor, except opening the file dialogue on gedit
> caused #2
> to go low level, and #1 to switch to 100%! I tried this a few
> times and
> it always caused a different processor to go to 100%. After
> leaving one
> processor running for a few minutes at 100%, the opening of a
> file-selection dialogue didn't switch the processors any more.
> Leaving
> that processor permanently at 100%
>
> On killing OpenShot with a "Force Quit", the 100% processor
> immediately
> dropped down to low level and joined the other two so I had
> then all
> three processors in a balanced load at low level.
>
> Therefore I would surmise that freezing of the viewport or the
> whole of
> OpenShot both are caused by a never ending loop as some
> process is
> waiting for a result from a sub process which has probably
> died, and the
> waiting is not being timed out.
>
> Women's intuition suggests to me either: that one of the MLT
> functions
> has a bug where it fails to return an error code when failing.
> Or else
> some function in the Python code is failing to test for the
> error return
> from a function, and is just looping and calling until it gets
> what it
> considers to be a valid return value (which never comes)
>
> A clue to where this might be is that any call to the Gnome
> file-selection dialogue, causes that looping process to be
> re-spawned on
> a different processor. (Wow! This takes me back nearly 20
> years to when
> I was learning to program Transputer arrays in the Occam2
> language!)
>
> At soem point in all of this, some process related to the file
> selection
> is timing out but leaving the looping process as an orphan and
> so then
> it never switches until the application is killed and all
> related
> processes are sent the kill signal. Therefore the orphan
> process is
> still open to signals like KILL. (sig something, I can't
> remember all
> the signal codes anymore)
>
> I hope this helps.
>
> Helen
>
>
>
> On Thu, 2009-07-23 at 21:11 +0000, Jonathan Thomas wrote:
> > Helen, are your media files located on your primary
> harddrive? or an
> > external harddrive? Also, please check your "System
> Monitor", and see
> > what the CPU is doing while OpenShot is hanging. And, as a
> side note,
> > see how many "Python" processes are running on your
> computer. There
> > should only be a few. Thanks!
> >
>
>
>
>