Click on the timeline doesn't move playing position sometimes

[singalen]

Seems to mostly work when I click and drag the mouse a little.

System Details:

• Operating System / Distro: MacOS 10.13
• OpenShot Version: 2.4.2
  

[peanutbutterandcrackers]

Can't reproduce on my Elementary OS machine. Perhaps it is a mac related issue? o.O

@DylanC - Care to test this one out, Cap'ain?

[DylanC]

@peanutbutterandcrackers - No problem. I've a bunch of Mac issues I will need to test in a testing session. :)

[N3WWN]

It seems to me that the "trick" is clicking on the timeline above the minor graduations (the top of the short lines). Clicking below the top of the minor graduations results is no playhead movement for me, too. Even if I click and drag, if the cursor is below the top of the minor graduations, it won't work.

[peanutbutterandcrackers]

@singalen - Does @N3WWN's suggestion work for you, sir?

@N3WWN - Is the action a little less responsive on a mac, and thus in need of some work? o.O

[N3WWN]

@peanutbutterandcrackers - I don't think it's any different on a Mac.

I noticed in @singalen 's animated GIF that it was the vertical location of the cursor that determined if the click caused movement or not. I replicated in Linux, FYI.

If there's no reason to NOT extend the clickable location to move the playhead, I can look at increasing it to include more of the lower portion.

[peanutbutterandcrackers]

@N3WWN - I see. I wonder if there is any reason NOT to increase it. But perhaps @DylanC or @ferdnyc might have some insight into this? I don't really see why not...

[ferdnyc]

The strange thing about this is that it's supposed to be clickable all the way down to the bottom of the ruler marks. And it is, in the timeline JS debugger. So, something's being set in Qt that's shrinking the clickable area of the ruler.

[DylanC]

@ferdnyc - I don't think something is shrinking the clickable area. I feel the click events are not registering sometimes. It happens at random intervals from my testing. A click on the ruler would just do nothing, clicking the same area again later works.

[ferdnyc]

Hm, really? ...Do you mean in the debugger, or in OpenShot?

I felt like, in OpenShot, it was pretty reliably the case that clicking above a certain point (roughly, as @N3WWN said, the top of the smaller ruler ticks) would always register, and clicking below that point never did. When I felt like a click didn't register (because it seemed that way to me, too, like it sometimes just ignored my clicks), it was actually because I'd slipped down below that invisible line. And if you look at @singalen's GIF, it seems to be showing the same thing.

Whereas, in the debugger, it seemed to take my clicks all the time, no matter where I was. Though I didn't test that as extensively, just confirmed that I could click down low on the ruler and it would still move the Playhead.

Actually, experimenting a bit more now, I'll be even more specific: The area where it doesn't seem to register, in OpenShot, appears to correspond to the Marker icon region. Whether or not there are any Markers actually present on the ruler. But if there are Markers present, and I RIGHT-click in the vicinity of one, I either get its context menu (If I'm over it), or the Playhead moves (if I'm not). No middle ground (that I can find). So, it feels like the area where it doesn't move, if I'm not over a Marker, would correspond to the area where, if there were a Marker there, I'd be clicking on the Marker instead. ...If that makes any sense at all.

[ferdnyc]

I also just noticed that if you drag a selection box from the Timeline area up into the ruler area, it moves the Playhead (which it probably shouldn't do), but only after you cross above the top of the Markers. While you're down in the Marker region, the Playhead ignores you. But the moment the selection rectangle crosses the point at the top of a Marker, the Playhead jumps to the mouse position, and keeps following as long as you're above that point.

OK, I take that last part back. The Playhead's selection-box drag-following thing will continue all the way down to the bottom of the ruler area. It doesn't START until you pass above the invisible line, but then it will keep going when you cross below it again, until you pass back into the Timeline area proper. That appears to be unrelated to the presence of Markers on the ruler. (IOW, I've gotten it to do the same thing on a project with several Markers, and I've gotten it to do it immediately following a File > New Project.)

[DylanC]

@ferdnyc

Hm, really? ...Do you mean in the debugger, or in OpenShot?

It was happening to me inside OpenShot. I will need to check the debugger to see what is happening there but I feel like it wasn't happening inside the debugger. You may be right about the marker area not being clickable. I will need to go over this again as your statements are making me question my own. 😆

[ferdnyc]

Yeah, in the Timeline debugger I never had any problems clicking anywhere on the ruler, it always moved the playhead. That was the thing that surprised me, that the ruler behaved so differently between the debugger and OpenShot.

[DylanC]

@ferdnyc - I've had another look and unfortunately its as I first thought. So the ruler does have a "dead-zone" where the markers go. Clicking there produces no result. (obviously)

However, clicking the ruler in the "active" zones works perfect in the debugger/Chrome 100% of the time. The bug only happens inside OpenShot. Some of the clicks do not trigger in the "active" zone at all. You can reproduce this behavior by clicking random spots until a click doesn't register any action as a result(click only, no dragging).

[ferdnyc]

So the ruler does have a "dead-zone" where the markers go. Clicking there produces no result. (obviously)

Regardless whether it's in the debugger or Qt, you mean? Yeah, I think I see that now. It's weird how the markers seem to extend up so much higher in the Qt interface than the debugger, even though in reality I know they don't.

However, clicking the ruler in the "active" zones works perfect in the debugger/Chrome 100% of the time. The bug only happens inside OpenShot. Some of the clicks do not trigger in the "active" zone at all. You can reproduce this behavior by clicking random spots until a click doesn't register any action as a result(click only, no dragging).

Honestly, I can't get it to do that, even after clicking around quite rapidly for quite a while. It always seems to register my clicks.

It could possibly be a thread preemption / resource contention issue, since any move of the Playhead both (a) potentially triggers a cache frame being generated, and (b) always involves the preview thread. Are you using memory or disk cache, and how many cores does your machine have? On my 4-core i5 box with cache in memory (8G of RAM), so far I haven't been able to reproduce the issue.

Also, if you launch OpenShot from a terminal window so that you can see the console output, does it output either/both of the

preview_thread:INFO previewFrame: 170
preview_thread:INFO self.player.Position(): 170

lines, for the missed clicks?

Next thing might be to add a timeline.qt_log(playhead_seconds); at src/timeline/directives/ruler.js line 116, to see whether the clicks are getting dropped in the JavaScript or the Qt end. When I do that, I get this output for each click (unless I accidentally drag instead):

timeline_webview:INFO 66.88
preview_thread:INFO previewFrame: 1606
preview_thread:INFO self.player.Position(): 1606

[ferdnyc]

(Unrelated:) I don't understand why those messages would only be output for ruler clicks. ← and → presses to move the Playhead also update the preview frame, and should involve the preview thread, but they only trigger this output:

      logger:INFO 16777236
 main_window:INFO keyPressEvent: Right

...Which means there's a different code path for generating preview frames on mouse click, vs. generating preview frames from keyboard moves. That just seems bizarre.

[ferdnyc]

Oh, wow, it gets better. These lines:

preview_thread:INFO previewFrame: 170
preview_thread:INFO self.player.Position(): 170

Are output only when you either:

1. have no clip selected,
2. are clicking somewhere inside the area the selected clip occupies on the timeline

If you have a clip selected, and you click somewhere before or after the clip (on the ruler), no log output is generated. 😱

ETA: ...Yup, I think that's enough OpenShot for today.

[DylanC]

@ferdnyc - I'll have to get back looking at this again. Seems the problem may run deeper than we first thought.

[DylanC]

@ferdnyc

Also, if you launch OpenShot from a terminal window so that you can see the console output, does it output either/both of the

preview_thread:INFO previewFrame: 170
preview_thread:INFO self.player.Position(): 170
lines, for the missed clicks?

Nope, I don't get those lines for the missed clicks. I do get them for any successful clicks.

Next thing might be to add a timeline.qt_log(playhead_seconds); at src/timeline/directives/ruler.js line 116, to see whether the clicks are getting dropped in the JavaScript or the Qt end. When I do that, I get this output for each click (unless I accidentally drag instead):

timeline_webview:INFO 66.88
preview_thread:INFO previewFrame: 1606
preview_thread:INFO self.player.Position(): 1606

For the missed clicks I do not get output for this to the console. I guess its on the Qt side then. Would make sense considering its perfect inside Chrome. Its definitely doing something on each click and just hanging every now and then on that function or thing its doing.

[stale]

Thank you so much for submitting an issue to help improve OpenShot Video Editor. We are sorry about this, but this particular issue has gone unnoticed for quite some time. To help keep the OpenShot GitHub Issue Tracker organized and focused, we must ensure that every issue is correctly labelled and triaged, to get the proper attention.
This issue will be closed, as it meets the following criteria: - No activity in the past 180 days - No one is assigned to this issue
We'd like to ask you to help us out and determine whether this issue should be reopened. - If this issue is reporting a bug, please can you attempt to reproduce on the latest daily build to help us to understand whether the bug still needs our attention. - If this issue is proposing a new feature, please can you verify whether the feature proposal is still relevant.
Thanks again for your help!