In time in clip properties is not set correct

[Bjorn Hjortsberg]

Openshot 1.4.3 on Linux Sabayon.

Under the "length"-tab in clip properties there is a textbox with start time for the clip, this time is always 0 (or actually -0.01).
The reason for this is that when clip properties dialog is loaded the txtIn-textbox is set before txtOut-textbox which lead to that local_out is 0.0 in on_txtIn_value_changed(). The logic:
  if local_in >= local_out:
   local_in = local_out - 0.01
   self.txtIn.set_text(str(local_in))
will then set textbox text to -0.01.

One solution to this is to switch the order for setting txtOut and txtIn, that is set txtOut before txtIn (in frmClipProperties::__init__()).

[Olivier Girard (eolinwen)]

Thanks a lot.

2013/7/7 Bjorn Hjortsberg <email address hidden>

> ** Patch added: "in_time_fix.patch"
>
> https://bugs.launchpad.net/openshot/+bug/1198555/+attachment/3727614/+files/in_time_fix.patch
>
> --
> You received this bug notification because you are a member of OpenShot
> Bugs, which is subscribed to OpenShot Video Editor.
> https://bugs.launchpad.net/bugs/1198555
>
> Title:
> In time in clip properties is not set correct
>
> Status in OpenShot Video Editor:
> New
>
> Bug description:
> Openshot 1.4.3 on Linux Sabayon.
>
> Under the "length"-tab in clip properties there is a textbox with start
> time for the clip, this time is always 0 (or actually -0.01).
> The reason for this is that when clip properties dialog is loaded the
> txtIn-textbox is set before txtOut-textbox which lead to that local_out is
> 0.0 in on_txtIn_value_changed(). The logic:
> if local_in >= local_out:
> local_in = local_out - 0.01
> self.txtIn.set_text(str(local_in))
> will then set textbox text to -0.01.
>
> One solution to this is to switch the order for setting txtOut and
> txtIn, that is set txtOut before txtIn (in
> frmClipProperties::__init__()).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openshot/+bug/1198555/+subscriptions
>
> --
> Mailing list: https://launchpad.net/~openshot.bugs
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~openshot.bugs
> More help : https://help.launchpad.net/ListHelp
>

--
Olivier
Cenwen un elfe sur la banquise/ an elve on the ice
Mon blog perso sur le multimédia, Ubuntu, Linux et OpenShot :
http://linuxevolution.wordpress.com/
Le forum d'Openshot où vous me trouverez : http://openshotusers.com/
http://openshotusers.com/forum/index.php
Nothing is lost until the last second.
The family motto : When we want, we can.
Astuces, Actualités, Logiciels, bref sur tout ce que je ne fais d'articles
dessus Google+ <https://plus.google.com/u/0/111472725110173916234/posts>

[Andy Finch (fincha)]

The In time is supposed to show the point within the clip where it starts playing. In other words, unless you have trimmed the start off of a clip it will always be zero. So if you have 5 clips in a row they will all show zero as the IN time, unless you trimmed the start of a clip. There is a 'Position On Timeline' textbox on the general tab which shows the actual startime of the clip in relation to the timeline.

I can't get it to show a < 0.0 figure.

[Bjorn Hjortsberg (bitbjorn)]

Ok, didn't know that. But then something else isn't working correct.

If I cut one clip in two, then open properties for clip2, verify that In time is 0.00. Click Apply (this is important).
Then start a preview. When preview reaches clip2 it will start from time 0 again. It seems to start from "In" time because with the fix I suggested (where "In" time is position of the clip) it works with the preview.
Maybe its the preview code that needs a fix, I haven't looked at it.

[Scott (scottmoelker)]

On Ubuntu 13.10, running Openshot 1.4.3 I have this same problem (I think). Whenever I go to the properties for a clip on the timeline, the "In" time on the length tab, it is set to -0.01, even though I have resized the clip and trimmed content from the beginning.

[librin.so.1 (vinislentoje)]

This bug is a great hindrance to me – I very often trim the beginning of clips. But each time I open the clip properties, it gets set to -0.01
Unless I set it to the required value again, the trimming resets itself. So I need to remember what start position / in-length I gave for each and every clip or even keep a list on a text file.
This gets extremely frustrating when having dozens upon dozens of clips and having to fine-tune the in/out times for some of them – turns a half a minute task into one that can take over a half an hour.

[MorrisseyJ (morrissey-james1)]

I agree that this is a major bug. Notably it also seems that it is triggered by clicking the lengh tab in the clip properties dialogue. In addtion to the problems pointed out by vinislentoje, if you are changing the length of the clips (which you now apparently have to do if you change the speeds) the info contained in 'position in timelinel' also goes wrong. At that point you have no information about the lengh of your clip.

To create the problem.

1. Add a clip.
2. Split that clip in half
3. Right click on the second clip (generated by splitting the first clip in two) and open 'clip properties'
4. Under the 'general tab' you should see the 'position in timeline' statistic
5. Click play on the preview, and clip will play as expected.
6. Click 'length tab' - here you will see the problem, described by bitbjorn above, that the In time is 0.00 or -0.01 (this is clearly wrong)
7. Now click play in the preview and the clip will run from the start of both clips (from 0.00).

- So it seems to be the length tab which is messing things up

Things get even more confusing if you start changing the lenght of your clips which you now have to do in order to change thier speed (post #2: http://openshotusers.com/forum/viewtopic.php?f=11&t=2000), with differnt clips running at multiple differents speeds. In this case the information given in the lengh tabs and position in clip tabs both go wrong.

[bill (fourthirtysix)]

Experienced on Openshot 1.4.3 on Ubuntu 13.10 - Please fix, this is a big problem!

[Øyvind Stegard (oyvindstegard)]

Yeah, this bug makes basic splitting and cutting a pain to deal with in OpenShot... [Ubuntu 14.04]

[Michael Suelmann (suelmann)]

I'm affected too. I looked into the code and the cause are the functions on_txtIn_value_changed and on_txtOut_value_changed which try to sanitize the start and end times of the clip.

on_txtIn_value_changed checks if the start time is not bigger than the end time, but it is called before before the txtOut (end time) is set, so it always checks agains an end time of 0. This can be fixed with the patch from Bjorn Hjortsberg which first sets the end time and then the start time.

on_txtOut_value_changed checks if the end time is at least as big as the start time and if the end time is no bigger than the clip length. The first check doesn't do harm if we change the order of the initializing as the check is then performed with a start time of 0. The second check is not valid though: If you slow down the clip you have to enter an end time according to slowed time which can be larger than the clip length. And if you want the last frame of a clip to be visible after the clip is finished, you need a bigger end time than clip length too.

I attached a patch which includes the patch from Bjorn Hjortsberg to reorder initialization and additionally removes the bogus check of the end time against the clip length.

[Olivier Girard (eolinwen)]

Thanks a lot for your patch.

2014-11-16 9:35 GMT+01:00 Michael Suelmann <email address hidden>:

> I'm affected too. I looked into the code and the cause are the functions
> on_txtIn_value_changed and on_txtOut_value_changed which try to sanitize
> the start and end times of the clip.
>
> on_txtIn_value_changed checks if the start time is not bigger than the
> end time, but it is called before before the txtOut (end time) is set,
> so it always checks agains an end time of 0. This can be fixed with the
> patch from Bjorn Hjortsberg which first sets the end time and then the
> start time.
>
> on_txtOut_value_changed checks if the end time is at least as big as the
> start time and if the end time is no bigger than the clip length. The
> first check doesn't do harm if we change the order of the initializing
> as the check is then performed with a start time of 0. The second check
> is not valid though: If you slow down the clip you have to enter an end
> time according to slowed time which can be larger than the clip length.
> And if you want the last frame of a clip to be visible after the clip is
> finished, you need a bigger end time than clip length too.
>
> I attached a patch which includes the patch from Bjorn Hjortsberg to
> reorder initialization and additionally removes the bogus check of the
> end time against the clip length.
>
> ** Patch added: "in_time_out_time.patch"
>
> https://bugs.launchpad.net/openshot/+bug/1198555/+attachment/4261685/+files/in_time_out_time.patch
>
> --
> You received this bug notification because you are a member of OpenShot
> Bugs, which is subscribed to OpenShot Video Editor.
> https://bugs.launchpad.net/bugs/1198555
>
> Title:
> In time in clip properties is not set correct
>
> Status in OpenShot Video Editor:
> New
>
> Bug description:
> Openshot 1.4.3 on Linux Sabayon.
>
> Under the "length"-tab in clip properties there is a textbox with start
> time for the clip, this time is always 0 (or actually -0.01).
> The reason for this is that when clip properties dialog is loaded the
> txtIn-textbox is set before txtOut-textbox which lead to that local_out is
> 0.0 in on_txtIn_value_changed(). The logic:
> if local_in >= local_out:
> local_in = local_out - 0.01
> self.txtIn.set_text(str(local_in))
> will then set textbox text to -0.01.
>
> One solution to this is to switch the order for setting txtOut and
> txtIn, that is set txtOut before txtIn (in
> frmClipProperties::__init__()).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openshot/+bug/1198555/+subscriptions
>
> --
> Mailing list: https://launchpad.net/~openshot.bugs
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~openshot.bugs
> More help : https://help.launchpad.net/ListHelp
>

--
Olivier
Cenwen un elfe sur la banquise/ an elve on the ice
Mon blog perso sur le multimédia, Ubuntu, Linux et OpenShot :
http://linuxevolution.wordpress.com/
Le forum d'Openshot où vous me trouverez : http://openshotusers.com/
http://openshotusers.com/forum/index.php
Nothing is lost until the last second.
The family mott...

[przemjaskier (przemjaskier)]

Due to this bug editing in OpenShot is a nightmare. It's 1.5 year since first patch was provided. No included and released until today?

This project is in a very poor shape. What a waste of potential. Actually this sentence is repeated by many people over and over again, so it's about time to realize that is a permanent condition and there is no sense in expecting any change here.

[przemjaskier (przemjaskier)]

So to keep things meritorical... I've just patched my local installation using this patch and everything works as it should from the beginning.

This bug and https://bugs.launchpad.net/openshot/+bug/499739 is something that hits users from day 0 of tool usage, the latter patch waiting for inclusion for almost 2 years now...

Quo vadis?

[Stefan Taferner (taferner)]

Please apply this patch to the sources, its a pain to use openshot without it.
I even switched to Cinelerra due to this bug .... but came back, however ;-)

[Wolfgang Flatter (78luphr0rnk2nuqimstywepozxn9kl19tqh0tx66b5dki1xxsh5mkz9gl21a5rlwfnr8jn6ln0m3jxne2k9x1ohg85w3jabxlrqbgszpjpwcmvkbcvq9spp6z3w5j1m33k06tlsfszeuscyt241hasoyapndax-launchpad-a811i2i3ytqlsztthjth0svbccw8inm65tmkqp9sarr553jq53in4xm1m8wn3o4rlwaer06ogwvqwv9mrqoku2x334n7di44o65qze67n1wneepmidnuwnde1rqcbpgdf70gtqq2x9thj5tlcsac12abiuk2rb)]

Hello, I'm also hardly affected.
Any why is the Importance of this bug "low"?! It makes the software completly useless for cutting "real" movies. You always have to adjust the start of a clip.
How can I fix this myself? :(

[Olivier Girard (eolinwen)]

Because we are working on the 2.0 version and this takes more times that we
have planned.

2015-05-30 18:01 GMT+02:00 Wolfgang Flatter <email address hidden>:

> Hello, I'm also hardly affected.
> Any why is the Importance of this bug "low"?! It makes the software
> completly useless for cutting "real" movies. You always have to adjust the
> start of a clip.
> How can I fix this myself? :(
>
> --
> You received this bug notification because you are a member of OpenShot
> Bugs, which is subscribed to OpenShot Video Editor.
> https://bugs.launchpad.net/bugs/1198555
>
> Title:
> In time in clip properties is not set correct
>
> Status in OpenShot Video Editor:
> New
>
> Bug description:
> Openshot 1.4.3 on Linux Sabayon.
>
> Under the "length"-tab in clip properties there is a textbox with start
> time for the clip, this time is always 0 (or actually -0.01).
> The reason for this is that when clip properties dialog is loaded the
> txtIn-textbox is set before txtOut-textbox which lead to that local_out is
> 0.0 in on_txtIn_value_changed(). The logic:
> if local_in >= local_out:
> local_in = local_out - 0.01
> self.txtIn.set_text(str(local_in))
> will then set textbox text to -0.01.
>
> One solution to this is to switch the order for setting txtOut and
> txtIn, that is set txtOut before txtIn (in
> frmClipProperties::__init__()).
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openshot/+bug/1198555/+subscriptions
>
> --
> Mailing list: https://launchpad.net/~openshot.bugs
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~openshot.bugs
> More help : https://help.launchpad.net/ListHelp
>

--
Olivier
Cenwen un elfe sur la banquise/ an elve on the ice
Mon blog perso sur le multimédia, Ubuntu, Linux et OpenShot :
http://linuxevolution.wordpress.com/
Le forum d'Openshot où vous me trouverez : http://openshotusers.com/
http://openshotusers.com/forum/index.php
Nothing is lost until the last second.
The family motto : When we want, we can.
Astuces, Actualités, Logiciels, bref sur tout ce que je ne fais d'articles
dessus Google+ <https://plus.google.com/u/0/111472725110173916234/posts>

[Clint (grandpied2000)]

This solved my problem. I had the very same problem per described by previous posters. For a rather easy workaround, I received the following answer from Manfred Hampl (m-hampl) source: https://answers.launchpad.net/openshot/+question/273161

The following should work as a manual workaround:

Issue the command
gksudo gedit /usr/share/pyshared/openshot/windows/ClipProperties.py

(if the command gksudo is not installed, try
sudo gedit /usr/share/pyshared/openshot/windows/ClipProperties.py
instead; if gedit is not available on your system, then use any other text editor.)

This should ask for your password as confirmation for an administrative action and then open the editor with one of the Openshot Python programs loaded.

Scroll down near line 91 and change the sequence of two lines
from
 self.txtIn.set_value(round(self.current_clip.start_time, 2))
 self.txtOut.set_value(round(self.current_clip.end_time, 2))
into
 self.txtOut.set_value(round(self.current_clip.end_time, 2))
 self.txtIn.set_value(round(self.current_clip.start_time, 2))
Keep the indentations exactly as they are in the file!

Search for the occurrence of 0.01
After the second occurrence (probably line 663) delete the block of the three lines

if local_out > local_max_length:
 local_out = local_max_length
 self.txtOut.set_text(str(local_out))

Attention, you have to make sure that you do not touch the indentation of other lines.
Save the file, close the editor, and try using OpenShot again.

In case that OpenShot does no more work after these modifications, just reinstall the openshot package and you should be at the same status as before.

[Paddy Landau (paddy-landau)]

@grandpied2000 — Thank you! This has fixed my problem, and was such an easy fix.

(Instead of reinstalling OpenShot should this fail, make a backup of the file before editing it. If it doesn't work, simply restore the file from the backup. In my case, though, it worked perfectly first time.)

[Paddy Landau (paddy-landau)]

@eolinwen — This is such a simple fix for such a serious problem! Is there no way that you can implement this?

The priority definitely should not be set to "Low" — it should be "High", because if you don't realise the problem and don't have an backup from the last few seconds, you end up losing important information — especially in a large project.

[David Chappelle (chappedm)]

There is one more part to patching this correctly that must be taken into account. When setting the speed to a fractional amount to slow the clip down (ie. 1/2, 1/3, etc), you will notice that the clip length is not properly adjusted on the timeline even after making the suggested changes above. To fix this I also had to modify the following around line 892:

        if speed_multiplier < original_speed:
            # clip is longer now (keep the short version)
- clip_object.end_time = clip_object.start_time + original_length
+ clip_object.end_time = new_end_time

Why would you want to "keep the short version"? We are changing the speed of the clip so setting the end_time back to what it originally was seems to be a bad idea. Regardless, with this modification, the automatic resizing of a clip due to slowing the speed down now works correctly.

[Paddy Landau (paddy-landau)]

@chappedm, thank you for the new fix.