timeline only shows 320 times the zoom slider setting

[thyeum]

The timeline only shows the first (320*zoom seeting) seconds of a project.
So if the zoom slider setting is set to 1 s, the timeline stops at 5'20'' (=320'')
if it set to 2 s, it stops at 10'40'' (=640''), 4 s it stops at 21'20'' (=1280''), etc.

How to reproduce:
-launch OpenShot and create a new project of 60 min
-with the default 8 s zoom setting you can only move the timeline up to 42'40'' (=2560 = 320*8)
-try zooming in and see the timeline shorten as you zoom more

1. Ubuntu 10.10 x64
2. PPA installation
3. OpenShot 1.3.0

[Andy Finch (fincha)]

The timeline object has a coordinate limit of around 32000 pixels, due to a limitation in libcairo. You should see the next section of the timeline get drawn as you scroll towards the end.

[thyeum (mchellat)]

unfortunately I cannot scroll toward the end. if you look at my screenshot, you'll see that the scroll bar is all the way at the end and I can only see 42 min 40 sec (even though it is a 60 min project).
the only way to see more is to zoom out which make it harder to edit.

[Seby Carta (sebycarta)]

i have to work at some DVD of duration of 2 hours.This bug is really a problem, because after 1 hour on timeline i have to set zoom at around 100 sec. to see the rest of timeline. This is bad and is difficult to position transitions with this zoom's amount.

[Bernd Faulstich (bernibaerchen)]

Same problem. Set a position in sync with music with a 20 minutes movie is impossible.
Critical Bug!!!

[Bernd Faulstich (bernibaerchen)]

If i play the movie over this limit the cursor is going through the vertical scrollbar over the right screenedge.
The problem is is only the scaling of the scrollbar to the working-area.

Position of shown area = (Scrollbar-position / Scrollbar-max) * length of movie
(+/- width of shown area) or like this.

Lot of Thanks for the good done job.
Like using OpenShot

[James D (demichej)]

Agreed that this is a troublesome bug. When you have a lot of track time, and you zoom in, you can't actually edit past a certain time.

[jonohull (jonohull)]

Any word on this? It seems to be a critical problem for any project over 5 minutes in length. It's impossible to sync an audio track to a video track when one pixel of movement is several seconds.

[Mikko Huhtala (mhuhtala)]

I having trouble with this bug in Openshot 1.4 on Fedora 16 (x86_64). I think the importance should be high for this one. It makes Openshot painful to use for longer videos.

[Seby Carta (sebycarta)]

Hi guys, i can give you all my love if you'll fix this bug ;-)
I'm waiting for this fix to start editing my family's 2hours-DVDs
Please reconsider importance of this problem.
Happy new year.

[Andy Finch (fincha)]

The bug is ultimately caused by a bug in goocanvas/cairo (the libraries that are used to draw the timeline). It seems like it may have been fixed in goocanvas, but the version in Debian/Ubuntu is way out of date - and the Debian maintainer seems to have disappeared so we have been unable to get the later version into Debian.

[Seby Carta (sebycarta)]

Is not possibile provide the newer version of goocanvas in your PPA?

[Andy Finch (fincha)]

We can't fix this in 1.4.3 as it needs a new version of goocanvas that is not in any of the repos.

[madpentiste (antoine-messiah)]

Andy and Cenwen

Bug #93327 might _or might not_ be a duplicate of bug #722285
<https://bugs.launchpad.net/bugs/722285>. I just offered a patch to fix
bug #933227 (Andy, you narrowed me down to the module and the line of
code I should look at, for zoom-button issues, remember?).

My patch might fix bug 722285 <https://bugs.launchpad.net/bugs/722285>,
or at least help fixing it. See the patch (very short, 2 lines of code
and 2 comments were changed) attached at
https://bugs.launchpad.net/openshot/+bug/933227.

Please tell me if this help.

Antoine (madpentiste)

Le 20/03/2012 15:20, Andy Finch a écrit :
> We can't fix this in 1.4.3 as it needs a new version of goocanvas that
> is not in any of the repos.
>
> ** Changed in: openshot
> Milestone: 1.4.3 => 1.5.0
>

[madpentiste (antoine-messiah)]

RE: comments from #7 to #10
=========================

I understand that it is more intuitive and agreeable to work by moving "by hand" (click&hold-slide-drop) the videos and audios on the time-line. HOWEVER, you are then limited by the pixel-to-time-frame relationship. Even if this bug were fixed, there would still be some lack of precision, unless an gigantic magnifying glass were put into place (that is, zooming-in far beyond/below the current 1s limit).

I suggest that, once you have put your clips (video, audio, etc.) and transitions on the time-line ROUGHLY were you want them to be, you use the tools provided by the "properties" menus, as follows. When you right-click on a clip or a transition and select "properties", you have access to its position on the time-line with a 1/100s precision. This position is modifiable, which allows you to fine-tune where you want each of your objects (videos, audios, transitions) to be placed on the time-line (and many more fine-tuning possibilities).

Please tell me if this helps.

[Alfredo Rubio (alfredx8)]

Hi:

Your proposal should fix the precision problem working with clips longer
than 5 minutes, but yes, it would loose the intuitive way from drag and
drop, i guess.

Thanks

El mié, 21-03-2012 a las 14:42 +0000, madpentiste escribió:
> RE: comments from #7 to #10
> =========================
>
> I understand that it is more intuitive and agreeable to work by moving
> "by hand" (click&hold-slide-drop) the videos and audios on the time-
> line. HOWEVER, you are then limited by the pixel-to-time-frame
> relationship. Even if this bug were fixed, there would still be some
> lack of precision, unless an gigantic magnifying glass were put into
> place (that is, zooming-in far beyond/below the current 1s limit).
>
> I suggest that, once you have put your clips (video, audio, etc.) and
> transitions on the time-line ROUGHLY were you want them to be, you use
> the tools provided by the "properties" menus, as follows. When you
> right-click on a clip or a transition and select "properties", you have
> access to its position on the time-line with a 1/100s precision. This
> position is modifiable, which allows you to fine-tune where you want
> each of your objects (videos, audios, transitions) to be placed on the
> time-line (and many more fine-tuning possibilities).
>
> Please tell me if this helps.
>

[madpentiste (antoine-messiah)]

In response to comment #3, see patch enclosed.

Unfortunately, while with this patch one have plenty of room on the right side of the horizontal scroll bar, once the limit of 320*zoom_setting seconds of the project is reached, the canvas stops sliding.

It looks like the canvas has an absolute horizontal size. Is this what Andy meant when he said (#2) "The timeline object has a coordinate limit of around 32000 pixels, due to a limitation in libcairo"?

If this is the case, I am wondering whether we could get the left side of the project to get out of the canvas, in order to make room for the right side. Currently, because the left side of the project is hard-glued to the canvas, the right side (beyond the 320*zoom_setting seconds) is always outside of the canvas.

Any ideas, clues, hints or suggestions any one?

[madpentiste (antoine-messiah)]

Follow-up on #11 -- Goocanvas issue?
==============================

http://developer.gnome.org/goocanvas/unstable/goocanvas-coordinates.html -- Coordinate Limits

<< GooCanvas uses the Cairo graphics library to render canvas items. For performance reasons Cairo uses 32-bit fixed point integers internally when rendering graphics, with 24 bits used for the integer part of values and 8 bits used for the fractional part. This means that values are limited to roughly +/- 8,388,608. >>

Since there is also a decimal part on 8 bits, which encompasses the range from 00 to 99 (but not to 999), Goocanvas can work with coordinates ranging from -8,388,608.00 to +8,388,607.99 . Assuming that a desired time-line precision would be 1/100 sec, Goocanvas should be able to accommodate a time-line of 16,777,216 seconds, which is ... 4660 hours (and a handful of additional minutes, around 20)!!
And even if one wanted to go for a 1/1000 sec precision, Goocanvas would accommodate a time-line of 466 hours.

The 2-hour video projects that we are speaking about should fit in, couldn't they?

[Andy Finch (fincha)]

I'm almost certain the canvas limits of +/- 8,388,608 only apply for later versions of goocanvas. For a long time, all the distros have shipped version 0.15 of goocanvas - it is now at version 2.0.1. The important part from that page is this:

<< Prior to Cairo 1.6 16 bits were used for the integer part and 16 bits for the fractional part, meaning values were limited to +/- 32,768 >>

On my system (Linux Mint 11), Cairo is version 1.10.

However, in the last few weeks goocanvas 2.01 has finally been packaged in Ubuntu, although strangely not in Debian. So hopefully soon we can make some progress on this issue. It might not be totally straightforward though, as we will somehow have to deal with all the potential users who won't be on the latest distros and so won't have goocanvas2.

[madpentiste (antoine-messiah)]

Ok, but even if this is the case (old Cairo/Goocanvas, 16 bits integer + 16 bits decimal), there the comfortable 16-bit decimal part encompasses a range from 0000 to 9,999 (but not to 99,999). Combined with the integer part, one can go from 0.0000 to 65,535.9999 which represent 65,360,000 distinct values.

Assuming that a desired time-line precision would be 1/100 sec, old Goocanvas/Cairo should be able to accommodate a time-line of 653,600 seconds, which is ... 1820 hours !!
And even if one wanted to go for a 1/1000 sec precision, old Goocanvas/Cairo would accommodate a time-line of 182 hours.

So maybe it's all about using that decimal part, with an appropriate canvas-to-time ratio??

[madpentiste (antoine-messiah)]

I also found out that:

    1) only the right half of the canvas is used, from X = 0 to X = +32,768

    2) some GooCanvas features are not used, such as (in C++ syntax) the "scale-x" property, which is the horizontal magnification factor of the canvas with a default value of 1 (cf. http://developer.gnome.org/goocanvas/unstable/GooCanvas.html#GooCanvas--scale-x and http://lists.cairographics.org/archives/cairo-commit/2007-May/008061.html)

Therefore (please tell me wrong if it is the case), if we used the full range that GooCanvas can handle, from -32,768 to +32,768, we would double the size of the video that the time-line can show. This means that the canvas should originate at X = -32,768 instead of the current X = 0. On the top of that, we could use a horizontal magnification factor of the canvas above 1, so that even when we zoom-out in order to see a long video on the time-line, we could see details as if we were zooming-in (maybe in another window?).

In my opinion, the main difficulty here is to find each and every piece of code that deals with that horizontal canvas coordinate (it looks to me that there is many...).
Can anyone help?

[Joseph Eoff (joseph-eoff)]

This patch works around the short comings of the underlying library. It dynamically scales the available range in the scrollbar to whatever OpenShot needs to control the timeline. If you set the zoom control to one second, you will still be able to scroll through all of a very long project (tested with a project of 3 hours length.) This scaling comes at the cost of making the scroll itself coarser the larger the project is. For the 3 hour long project I tested, moving the timeline thumb by one pixel moves the timeline itself by nearly 2 seconds.

[Joseph Eoff (joseph-eoff)]

For got to mention, the patch is against the current development source from bazaar. This version of OpenShot calls itself version 1.4.3-alpha1.

[Joseph Eoff (joseph-eoff)]

Class Override patch for 1.4.3Alpha1
I've figured out how to do a class override cleanly with PyDev with Eclipse and Glade. . If I had any say in the final fix, I'd vote to do it this way. Anything else runs the risk of confusing developers sometime in the future.

All it took was to create a widgets folder with a catalog file in xml for Glade together with the class override. Then, I setup an external program runner in Eclipse to start Glade with a couple of environment variables telling Glade where to look for the new widget. Now I start Glade from Eclipse, and it can see the new widget. Additional widgets can be created in the same folder and added to the catalog withjust a couple of lines of xml.

This fix is clean - it requires a single import import added to MainGTK.py and of course the widgets folder. It doesn't confuse Glade and the developers don't have to remember to use some special functions instead of the object methods. On top of that, it leaves you with things setup for future custom widgets

If you'd like to try this out, it applies to the current development version (1.4.3Alpha1.) The patch has been made such that it will create the new files. I'm not so sure about the folder, though. You may need to create openshot/widgets by hand.

Once you apply the patch, you can start Glade from the command line like this:
export GLADE_CATALOG_PATH="/home/joseph/workspace/OpenShot Video Editor/openshot/widgets/"&&export GLADE_MODULE_PATH="/home/joseph/workspace/OpenShot Video Editor/openshot/widgets/"&&glade-3

You'll of course have to modify the paths to fit your setup. If you are using Glade above 3.10 then you will need to change the environment variables to "GLADE_CATALOG_SEARCH_PATH" and "GLADE_MODULE_SEARCH_PATH" Iam using Glade 3.7 (which is older than Glade 3.10) so the Glade 3.10 settings are what I've gleaned from the Internet.

Glade will have an "OpenShot Widgets" group on the left side with all the other widgets. It'll be way down at the bottom.

You can integrate this into Eclipse as shown in the attached picture. Do NOT use the ~ (tilde) for your home directory. Eclipse doesn't seem to like it.

[Joseph Eoff (joseph-eoff)]

Class Override patch for 1.4.3Alpha1 - The Patch

[Joseph Eoff (joseph-eoff)]

Patch for 1.4.2
At the request of Antoine (madpentiste ) I'm posting my original patch for Version 1.4.2 here. It isn't a really clean fix (not easily maintainable,) but it may be of use to folks with 1.4.2.

To install this "patch:"
You'll need to unzip the 1.4.2 source again, and replace the attached files as follows:
Put scrollbars.py and MainGTK.py in the "windows" folder of your 1.4.2 tree, and sequences.py in the classes folder of your 1.4.2.

Run "python setup.py install" to install the new files to your already installed OpenShot, or cd into bin and do "python openshot." to run the modified version without installing it.

[madpentiste (antoine-messiah)]

Indeed, Joseph had provided me with these 3 files so that I could try
his solution on my 1.4.2 version, and it worked. Therefore, I suggested
to Joseph to provide the community with these files.
This fix solves a bug which, for many including me, was quite a problem.
Now we can work on long video projects without having to zoom out. Thank
you Joseph!

Le 28/05/2012 09:43, Joseph Eoff a écrit :
> Patch for 1.4.2
> At the request of Antoine (madpentiste ) I'm posting my original patch for Version 1.4.2 here. It isn't a really clean fix (not easily maintainable,) but it may be of use to folks with 1.4.2.
>
> To install this "patch:"
> You'll need to unzip the 1.4.2 source again, and replace the attached files as follows:
> Put scrollbars.py and MainGTK.py in the "windows" folder of your 1.4.2 tree, and sequences.py in the classes folder of your 1.4.2.
>
> Run "python setup.py install" to install the new files to your already
> installed OpenShot, or cd into bin and do "python openshot." to run the
> modified version without installing it.
>
> ** Attachment added: "1.4.2Modifications.tar.gz"
> https://bugs.launchpad.net/openshot/+bug/722285/+attachment/3166680/+files/1.4.2Modifications.tar.gz
>

[Luis Alvarado (luisalvarado)]

Confirmed. The videos only show up to 42 minutes. After that I can't scroll to the right. using 1.4.0.

[Olivier Girard (eolinwen)]

You should use this patchs (above) done by Joseph on the latest stable version. She is not yet put in the trunk.
Here how to got the latest stable version : https://answers.launchpad.net/openshot/+faq/1850

[madpentiste (antoine-messiah)]

Bodo,

This is normal, you are half-way through. Do the following:

 1.

    Pick one version (either 1.4.2 or 1.4.3)

 2.

    Download the appropriate fix from Joseph Eoff, which will provide
    your with new/fixed files (scrollbars.py and MainGTK.py in a
    "Windows" folder, and sequences.py in a "Classes" folder):

      *

        Fix for 1.4.2 is available at
        https://bugs.launchpad.net/openshot/+bug/722285 posting n° 26,
        click on 1.4.2Modifications.tar.gz
        <https://bugs.launchpad.net/openshot/+bug/722285/+attachment/3166680/+files/1.4.2Modifications.tar.gz>

      *

        Fix for 1.4.3 is available at
        https://bugs.launchpad.net/openshot/+bug/722285 posting n° 25,
        click on classoverride-1.4.3A1.patch.tar.gz
        <https://bugs.launchpad.net/openshot/+bug/722285/+attachment/3166331/+files/classoverride-1.4.3A1.patch.tar.gz>

 3.

    Once the appropriate download is finished, unzip the archive, and
    replace the original files of your OpenShot code by the fixed/new
    files as appropriate (new scrollbars.py and MainGTK.py in your
    original "windows" folder , and new sequences.py in your original
    "classes" folder; say "yes" to any message telling you that there is
    already a file with the same name, since that file must be replaced).

 4.

    In a terminal, run "python setup.py install"

 5.

    You're done. You can launch OpenShot and the problem should have
    disappeared.

Antoine/Madpentiste.

Le 10/07/2012 23:48, Bodo Bigalk a écrit :
> Am 09.07.2012 19:03, schrieb Cenwen:
>> You should use this patchs (above) done by Joseph on the latest stable version. She is not yet put in the trunk.
>> Here how to got the latest stable version : https://answers.launchpad.net/openshot/+faq/1850
>>
> I did not understand which patches to use. I installed both versions of
> openshot first from the openshot-edge and then from the daily repository
> but both versions (1.4.2-1 and 1.4.3-alpha1) show up the same problem.
>
> Best Regards
> bibodo
>

[Bodo Bigalk (bib-odo)]

Am 09.07.2012 19:03, schrieb Cenwen:
> You should use this patchs (above) done by Joseph on the latest stable version. She is not yet put in the trunk.
> Here how to got the latest stable version : https://answers.launchpad.net/openshot/+faq/1850
>
I did not understand which patches to use. I installed both versions of
openshot first from the openshot-edge and then from the daily repository
but both versions (1.4.2-1 and 1.4.3-alpha1) show up the same problem.

Best Regards
bibodo

[Bodo Bigalk (bib-odo)]

Thank you, Antoine, for the detailed description.
The problem is now fixed.
Thanks again.

bibodo

Am 10.07.2012 18:30, schrieb madpentiste:
> Bodo,
>
>
> This is normal, you are half-way through. Do the following:
>
> 1.
>
> Pick one version (either 1.4.2 or 1.4.3)
>
> 2.
>
> Download the appropriate fix from Joseph Eoff, which will provide
> your with new/fixed files (scrollbars.py and MainGTK.py in a
> "Windows" folder, and sequences.py in a "Classes" folder):
>
> *
>
> Fix for 1.4.2 is available at
> https://bugs.launchpad.net/openshot/+bug/722285 posting n° 26,
> click on 1.4.2Modifications.tar.gz
> <https://bugs.launchpad.net/openshot/+bug/722285/+attachment/3166680/+files/1.4.2Modifications.tar.gz>
>
> *
>
> Fix for 1.4.3 is available at
> https://bugs.launchpad.net/openshot/+bug/722285 posting n° 25,
> click on classoverride-1.4.3A1.patch.tar.gz
> <https://bugs.launchpad.net/openshot/+bug/722285/+attachment/3166331/+files/classoverride-1.4.3A1.patch.tar.gz>
>
> 3.
>
> Once the appropriate download is finished, unzip the archive, and
> replace the original files of your OpenShot code by the fixed/new
> files as appropriate (new scrollbars.py and MainGTK.py in your
> original "windows" folder , and new sequences.py in your original
> "classes" folder; say "yes" to any message telling you that there is
> already a file with the same name, since that file must be replaced).
>
> 4.
>
> In a terminal, run "python setup.py install"
>
> 5.
>
> You're done. You can launch OpenShot and the problem should have
> disappeared.
>
>
> Antoine/Madpentiste.
>
>
> Le 10/07/2012 23:48, Bodo Bigalk a écrit :
>> Am 09.07.2012 19:03, schrieb Cenwen:
>>> You should use this patchs (above) done by Joseph on the latest stable version. She is not yet put in the trunk.
>>> Here how to got the latest stable version : https://answers.launchpad.net/openshot/+faq/1850
>>>
>> I did not understand which patches to use. I installed both versions of
>> openshot first from the openshot-edge and then from the daily repository
>> but both versions (1.4.2-1 and 1.4.3-alpha1) show up the same problem.
>>
>> Best Regards
>> bibodo
>>

[madpentiste (antoine-messiah)]

I recently installed a standard version of OpenShot, numbered 1.1.3-1, which did not have the current bug (722285).

Characteristics of that installation are the following:

- OS = Ubuntu Lucid Lynx (10.04 LTS)
- sources of software were only "Ubuntu" and "Canonical"
- updates set to "security" and "essential" bi-weekly
- I did the OpenShot installation the second half of June this year (2012)
- the computer had never had any OpenShot installation before, and no other software installed except: (1) those coming by default with Ubuntu; (2) Mozilla Thunderbird; and (3) VLC multimedia reader.

I have no idea of the reasons of this, but here it is, good piece of news. Maybe some underlying library has been fixed (in which case I am curious about why these libraries are not updated on my other computer, where I have the bug unless I download the source code and fix it with Josef Eoff patch)?
On this version of OpenShot, the default zoom value is 15s, instead of the usual 8s.

[Olivier Girard (eolinwen)]

At first look several patchs (as this one of Josef Eoff) are not yet included in the trunk.
We are not sure that all our problems in the timeline will be resolved but it seems to be a good workaround. Anyway, we are studying the best way to resolve it because at first look, pygoocanvas seems to be dead and on the Gnome side, nobody want to do things.
So I put it for the next milestone.

Just a thought, is it 1.1.3-1 or 1.4.3-1 ?

[madpentiste (antoine-messiah)]

It is 1.1.3-1.

I tried to install OpenShot from scratch on a 3rd computer, under similar circomstances :
- the software sources were only the standard/default ones, Ubuntu and Canonical
- no other software had been installed yet, apart from the ones that come along with Ubuntu 10.04

This time again, it was version 1.1.3 (not even 1.1.3-1) that came up, without bug 722 285, and the time-line was zoomed by default on 15s. Exact same result as described above in posting #33.

This is why I am surprised and wondering what have happened later on, beyond 1.1.3 (the bug is absent on version 1.1.3, but present in 1.3 and 1.4 -- and maybe 1.2 ??)
Or is it that a fix was done in underlying libraries, so that the bug is fixed for whoever does install OpenShot from scratch now, provided that the libraries in question are installed from scratch as well, during OpenShot installation.

[Andy Finch (fincha)]

I've had a look at this patch, and while it does fix the limitation, it breaks another aspect of the timeline scroll behaviour. Normally when the timeline is longer than what is visible, the timeline 'auto' scrolls while playing, so that the playhead stays in the center of the timeline. This seems to be broken with this patch, the playhead disappears to the right.

If I get a chance I'll try and take a look at working out why. But I don't want to apply the patch while it breaks something else.

[madpentiste (antoine-messiah)]

Not on my computer: the timeline scrolls, and the playhead stays in the
middle.

Can any one else share his/her experience with Joseph's patch?

Le 06/09/2012 17:32, Andy Finch a écrit :
> I've had a look at this patch, and while it does fix the limitation, it
> breaks another aspect of the timeline scroll behaviour. Normally when
> the timeline is longer than what is visible, the timeline 'auto' scrolls
> while playing, so that the playhead stays in the center of the timeline.
> This seems to be broken with this patch, the playhead disappears to the
> right.
>
> If I get a chance I'll try and take a look at working out why. But I
> don't want to apply the patch while it breaks something else.
>

[madpentiste (antoine-messiah)]

P.S. I have OpenShot 1.4.2 and its specific patch.
             Maybe the problem is with 1.4.3 and the 1.4.3 patch?

Le 06/09/2012 18:41, Antoine Messiah a écrit :
> Not on my computer: the timeline scrolls, and the playhead stays in
> the middle.
>
> Can any one else share his/her experience with Joseph's patch?
>
>
>
> Le 06/09/2012 17:32, Andy Finch a écrit :
>> I've had a look at this patch, and while it does fix the limitation, it
>> breaks another aspect of the timeline scroll behaviour. Normally when
>> the timeline is longer than what is visible, the timeline 'auto' scrolls
>> while playing, so that the playhead stays in the center of the timeline.
>> This seems to be broken with this patch, the playhead disappears to the
>> right.
>>
>> If I get a chance I'll try and take a look at working out why. But I
>> don't want to apply the patch while it breaks something else.
>>
>

[Joseph Eoff (joseph-eoff)]

I'll check tomorrow and see what it does. I'm pretty sure I would have noticed if the playhead had disappeared during playback - but then again, I was concentrating on getting the video edited so maybe my attention was elsewhere.

[Andy Finch (fincha)]

I was testing it against the very latest 1.4.3 trunk, so something may have changed in between when you created the patch and now.

[madpentiste (antoine-messiah)]

I am now working on a long project (2 hours), made itself of long video-clips ("rushes" of around 30 min each), which I chop into shorter clips on the tracks. I am using 1.4.2 with Joseph Eoff's patch.

Here are few abnormal behaviors:
1. When right- clicking on a clip on a track and choosing "properties", the play-head goes to position 0 (as soon as the properties window pops up, before doing anything)
2. Same behavior when "saving as"
3. Most actions take very long to complete (around 1 minute for most of them), with the screen turning gray.

Since I used neither the "classical" version (provided by Ubuntu or Canonical repositories) nor the non-patched 1.4.2 version on long projects and long imported video-clips, I don't know if this is due to 1.4.2, to Joseph's patch, or to the fact that both the project and the material it deals with are unusually long.

[Andy Finch (fincha)]

I'm aware of number 1, but haven't tracked it down yet, so I don't think it's related to the patch. I assume #1 & #2 have the same cause.

I don't know about #3, I don't normally do long projects.

[madpentiste (antoine-messiah)]

Update on my comment #42 point #3:

The problem disappear if files are on separate, fast-access, USB keys (i.e. Patriot). I tried the following configuration: videos on one USB key, projects (.osp) on another, and other files (music, pictures/photos, sequence of pictures) on a third one. With that configuration, everything works instantly.

This indicate that the issue might be some traffic jam when the programs has to access several files, some of which are big, at the same time (or in a short period of time), on the same media.

Two, fast-access, USB keys might suffice, but I did not this yet (e.g. small files like projects, pictures/photos/picture-sequences, and music on one USB, and large files like video clips on the other).

[Joseph Eoff (joseph-eoff)]

Patch for 1.4.3
This patch applies to the source tarball from https://launchpad.net/openshot/1.4/1.4.3/+download/openshot-1.4.3.tar.gz

That is (currently) the latest stable release.
Download the tarball from the link above.
Download the patch attached to this post.
Untar the openshot tarball.
Untar the patch and copy it into the openshot-1.4.3 folder created by untarring the openshot tarball.
In the shell, change directory into the openshot-1.4.3 folder
Apply the patch:
patch -p1 <patch1.4.3.patch

You can test the patched version by cd'ing into bin and executing ./openshot or you can install it by doing sudo python setup.py - just like always.

This is the same patch I originally made for 1.4.3Alpha1, but applied to the 1.4.3 release. There's really not much difference between the two, mostly just line numbers and I didn't edit the Main.ui file with my ancient copy of Glade, so the patch is much smaller.

If anyone wants it, I could make a patch for the current version from bzr.

[Joseph Eoff (joseph-eoff)]

Forgot to mention:
The comments from post 24 regarding Glade integration apply to this patch as well.

[Joseph Eoff (joseph-eoff)]

I had a look at the playhead problem mentioned in post 37. There was an error in the patch for Main.ui
I've corrected the error - patch is attached.
I also tested the patch against the current bzr code. It applies cleanly and works correctly.

[Arkadiusz Miśkiewicz (arekm)]

#47 works for me (note, it is missing patching setup.py for widgets component)

[Quentin (qvandekerckhove)]

The patch of the post #47 works for me too. Thanks a lot.

[J D Champ (jdchamp111)]

Thanks for the patch. Anxious to try it but getting stuck, appreciate any help:

Had Openshot 1.43 running fine on Ubuntu 12.04. But the show is over 60 minutes so I NEED that patch.
-DL'ed per instructions in 45 and 47.
-Installed patched version through terminal. (Did not uninstall first)
-Ran openshot thru terminal. Error:
"No LADSPA plugins were found!
Check your LADSPA_PATH environment variable."

-Uninstalled openshot with purge and autoremove.
-Preparing to reinstall the patched version. But now looking at
http://www.openshot.org/ppa/
it says "This is now the preferred way to install OpenShot for Ubuntu 9.10 and above."

I don't know from PPA, MLT3, python, etc... I just want to get Openshot running again, but with the timeline patch, and preferably with the auto-updates that PPA promises.

Thanks for any ideas.
JD

[Joseph Eoff (joseph-eoff)]

For those who would like to install the patched 1.4.3, here is the corrected setup.py

[Joseph Eoff (joseph-eoff)]

Patch for 1.4.4 Alpha1 (Current source code from bzr)
Follow the directions under this link to get the newest source code:
http://www.openshotusers.com/help/1.3/en/ar01s29.html#sect2_87
Steps 1 and 2 should get you started.
Download the patch attached to this post.

Copy the patch into the openshot folder created when you created the local branch on your computer
In the shell, change directory into the openshot folder
Apply the patch:
patch -p0 <OpenShot1.4.4A1-Timeline.patch

You can test the patched version by cd'ing into bin and executing ./openshot or you can install it by doing sudo python setup.py - just like always.

I've updated the patch for 1.4.3 to match 1.4.4 Alpha 1.
This patch includes the corrected setup.py.
The play head stays properly centered during playback.
I've tested this with a project of 3 Hours length - you have 1 second resolution on the timeline, and the entire project is accessible.

[Thomas A. F. Thorne (tafthorne)]

Knowing that I can hold ctrl & scroll down on the mouse wheel while over the timeline as a work around it helpful. Using that technique I was able to see past the initial 42:32:000 limit.

Confirming a me too, as this bug is still present in Ubuntu 16.04 with OpenShot 1.4.3. The workaround of zooming of the time bar helps though.