View Issue Details

IDProjectCategoryView StatusLast Update
0000125Cinelerra-GG[All Projects] Bugpublic2019-02-11 14:20
ReporterPierreAssigned ToPhyllisSmith 
PrioritynormalSeverityminorReproducibilityrandom
Status resolvedResolutionfixed 
Platformi7-3770k, 32GB(ram), GTX-750TiOSLinux Mint MateOS Version18.3
Product Version 
Target VersionFixed in Version 
Summary0000125: Frame-by-frame scrolling stops working in normal display mode and only works in "full screen" mode
DescriptionFrame-by-frame scrolling stops working in normal display mode and only works in "full screen" mode, both in the Compositor and in the Viewer.

This defect appears unpredictably after many manipulations, including frequent frame-by-frame movement and round trips between normal and full screen display modes.

At the moment I use DNxHD 29.97fps 1920x1080p sources.

No information appears in the terminal when this bug is present.
TagsNo tags attached.

Activities

PhyllisSmith

PhyllisSmith

2019-02-11 14:20

manager   ~0000851

Yeah!! what a relief since we could not reproduce here and we had little space to set up 3 monitors which was a next option that I was avoiding.
I will make a note in the trouble shooting section of the manual that I am trying to work on more diligently to warn others to be aware of compiz. This is not the first time it caused problems.
Pierre

Pierre

2019-02-11 05:09

updater   ~0000849

Problem solved!

Compiz... out, bug... out!

I tested the editing as much as I could... no sign of the bug.

I was using Compiz because every time I tested the options in the Linux Mint window management software list (with Mate), it was the only one that eliminated most of the video tearing problems.

Now... in replacement, "Marco" + "Compton. Their developers had to work hard... because... video tearing, there are no more, I've never seen so few.

So, in summary, the Bug: "Frame-by-frame scrolling stops working in normal display mode and only works in "full screen" mode", is no longer....
Pierre

Pierre

2019-02-10 21:02

updater   ~0000845

Yes, the picture of my desktop with the Shuttels and my three monitors (3x 1920x1080), is that of my normal and constant installation (which I have been using for a long time).

I'm starting to wonder if the problem could not be introduced by the Windows manager "Compiz".

I run LinuxMint with the Mate interface and I have been using "Compiz" (for a long time) because I find that it is with this Windows manager that I have the least video tearring problem when I play video sequences (nVidia GTX-750ti card and its recommended proprietary 384.130 driver).

I'm currently trying the other window managers (even if they're less effective at eliminating tearring) offered by Linux Mint Mate, to see if the bug is still present. I'll give you the results.
PhyllisSmith

PhyllisSmith

2019-02-10 20:37

manager   ~0000843

Are you always using the 3 monitors as in that phone photo you sent Sam of the Shuttles? Is that the initial setup?
Pierre

Pierre

2019-02-10 20:26

updater   ~0000842

I have just noticed that the frame-by-frame bug may appear even if at no time during the editing session (since I opened cinGG) have I used the "full screen" mode.

In this case, the terminal only mentions sound pilot problems). DNxHD files (converted by ffmpeg from HDV) 1920x1080p 29.97fps).


pierre@i7-3770k ~ $ /home/pierre/Cinelerra-GG_5.1/cin
Cinelerra Infinity - built: Feb 6 2019 13:39:34
git://git.cinelerra-gg.org/goodguy/cinelerra.git
(c) 2006-2018 Heroine Virtual Ltd. by Adam Williams
(c) 2007-2018 cin5 derivative by W.P. Morrow aka goodguy
Cinelerra is free software, covered by the GNU General Public License,
and you are welcome to change it and/or distribute copies of it under
certain conditions. There is absolutely no warranty for Cinelerra.

RenderFarmClient::main_loop: client started
AudioALSA::write_buffer err -32(Relais brisé (pipe)) at sample 733
AudioALSA::write_buffer err -32(Relais brisé (pipe)) at sample 1
AudioALSA::write_buffer err -32(Relais brisé (pipe)) at sample 223
Session time: 0:04:26
Cpu time: user: 0:04:41.231 sys: 0:00:21.703
pierre@i7-3770k ~ $
Pierre

Pierre

2019-02-10 02:58

updater   ~0000832

The problem is independent of the focus of the windows. The focus continues to follow the mouse cursor, even when there is a problem. If I move the cursor to a window where the problem is located, the title of that window becomes Bold as long as the mouse cursor is there.

The bug always occurs in the normal display mode of the Viewer or Compositor, every time I switch to Full Screen mode the problem is absent; I can move forward image/image, but as soon as I return to normal display mode, the problem reappears immediately.

The bug can appear either in the Viewer or in the Compositor. The bug may be present in one window but not in the other. If I continue, eventually the problem is present in both windows.

Once the problem appears, it no longer disappears (you have to quit CinGG and restart it). Whether I choose another source for the Viewer or place the cursor elsewhere on the timeline does not change it; the bug remains present in the normal display mode of this window, while still being absent in full screen mode.
PhyllisSmith

PhyllisSmith

2019-02-07 05:42

manager   ~0000784

A couple of ideas just came up on how to debug this.
The next time it happens in any window,
1) look at the title bar at thetop of the window to see if that window actually has focus. I do not know what Mint looks like, but in Fedora, if the window has focus the title bar is highlighted, else ghosted when it does not have focus.
2) explain to me how you then get single frame to work again as that may be a hint as to what is going wrong. By explain I mean, do you change back or forth between fullscreen and normal screen and that fixes it? or do you move to another window and then back?
Pierre

Pierre

2019-02-06 02:55

updater   ~0000761

The opposite also happens: Only the Compositor suffers from the bug; in this case the frame by frame suddenly only works in full screen mode and refuses to work in normal display mode, while in the Viewer, at the same time, both normal and full screen display modes still allow the frame by frame...
Pierre

Pierre

2019-02-06 01:02

updater   ~0000760

More information:

The problem may also only affect the Viewer, while the compositor still allows advance frame by frame in both display modes. Only the Viewer refuses to advance frame by frame in normal display mode.

In addition, if I place in the Viewer (by identifying the areas used) a source whose segment has been used, the area used is represented by a blue line whose end marker is yellow, but it is impossible for me to select the start marker; it does not turn yellow, it remains blue. In addition I can click in the bottom bar of the viewer to activate the reading of this place, but no indicator registers there as it should, the bar is as dead.
PhyllisSmith

PhyllisSmith

2019-02-05 23:46

manager   ~0000759

Notes to Phyllis (myself) -- leave this open until can duplicate here (even if that is a really long time!); check settings in Cin for focus policy and test variations; test with Mint more; better to test in a 2-3 monitor configuration. GG says may be X is not giving focus back?

Issue History

Date Modified Username Field Change
2019-02-05 06:18 Pierre New Issue
2019-02-05 23:42 PhyllisSmith Assigned To => PhyllisSmith
2019-02-05 23:42 PhyllisSmith Status new => assigned
2019-02-05 23:46 PhyllisSmith Note Added: 0000759
2019-02-06 01:02 Pierre Note Added: 0000760
2019-02-06 02:55 Pierre Note Added: 0000761
2019-02-07 05:42 PhyllisSmith Note Added: 0000784
2019-02-10 02:58 Pierre Note Added: 0000832
2019-02-10 20:26 Pierre Note Added: 0000842
2019-02-10 20:37 PhyllisSmith Note Added: 0000843
2019-02-10 21:02 Pierre Note Added: 0000845
2019-02-11 05:09 Pierre Note Added: 0000849
2019-02-11 14:20 PhyllisSmith Status assigned => resolved
2019-02-11 14:20 PhyllisSmith Resolution open => fixed
2019-02-11 14:20 PhyllisSmith Note Added: 0000851