 |
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. |
 |
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.... |
|
|
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. |
|
|
Are you always using the 3 monitors as in that phone photo you sent Sam of the Shuttles? Is that the initial setup? |
|
|
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 ~ $ |
|
|
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. |
|
|
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? |
|
|
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... |
|
|
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. |
|
|
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? |
- Anonymous
