 |
GG looked at this dump today and says it is a very unusual dump because it appears to be hung in libz, which is not used by Cinelerra. I attempted to set up the same scenario several times but can not get a hang. Send any more dumps if it occurs again. |
 |
I had another similar freeze. This time no video was loaded, I was reviewing Appearance tab layout for various languages. The UI froze, this time I saw the CPU stuck at 100% in CinGG (according to top). This might have happened other times, I just noted it now. It froze when I closed the appearance tab using Enter, the Preferences window disappeared leaving only the CinGG main window. This I have done umpteen times today, only now it went wrong. I created a dump using ctrl-C in terminal CinGG was started from (attached). System Mint 19.3 XFCE in recovery mode (ati,vesa graphics driver) Possible related error in ~/.xsession-errors: (xed:5259): Gtk-WARNING **: 13:43:26.127: Calling org.xfce.Session.Manager.Inhibit failed: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such method 'Inhibit' cinelerra_1012.dmp (82,254 bytes) |
|
|
Re-opening for more analysis. |
|
|
Per MatN, can not reproduce. I will still look at the SimpleScreenRecorder output (as MatN provided me) to see if there is some reason, other than being mkv, that Cinelerra has problems with this format. |
|
|
@Phyllis, I propose to close this issue. I tried for days now to reproduce it and no go. I am fairly sure it was related to either a timed screen lock (requires login), or suspend. But I have tried everything I could think of and it does not re-appear. It must be a local graphics driver issue, unrelated to CinGG code. |
|
|
Duh. Before I posted the note below, I tried it (note 2) at least 5 times, loading cin each time again, with and without va-api. The problem was completely repeatable. Just for the heck of it, I rebooted the system to recovery mode, and the problem (from note 2) is gone! I went back to normal mode, and it was gone too. There were no system updates or any other changes to the system. Normally I run kernel 5.4.0.37 generic, I tried it's recovery mode, and also kernel 4.15.0.106 in normal mode. After the first time I cannot reproduce that problem anymore. This might also explain why I did not have it on the test machine which normally runs in recovery mode. Sigh. It looks like this is a local problem, but I don't see how it can influence looping. I should note that this looping occurred on multiple places in the timeline, It might well have been each time after 1 second+10 frames, I remember it always flipping between frame 10 and 11 no matter where it looped. I only reported the simplest case. 1 second frame 10 would be frame 40/41 because the video is exactly 30 fps. I don't see anything weird in the .xsession-error log but of course the original one has been overwritten already after multiple reboots. |
|
|
@Phyllis, 1. I sent you a small file, 6M, created by SSR for the interlace test. I noticed that in the detailed info it shows "video1 h264 1280x1024 30.00 pix yuv420p" so the "non-interlace" info is there. 2. I sent you the original file which showed the problem per wetransfer, about 49M. I found a easier problem with the file, maybe that helps pin it down. If I start cin (which is set to "use hw device: none") and load the file as "replace current project", it loads with some "stream times estimated" msgs. I go to the beginning, hit space bar to play, then it starts looping around 1 second frame 10 . I'm fairly sure I deleted that part in the very beginning before I got the original problem. This is on the machine I found the problem first. On my test machine yesterday it did not exhibit the original problem, but I'll go back and test again. I need to reproduce it there before testing a new git version, obviously. 3. Maybe we need to find the best settings for SSR if the video is to be edited later bij CinGG. |
|
|
@MatN I am not sure the "interlace flag" is always correct. GG wanted to delete this because of this. Could you send a small sample file so he can look at it? |
|
|
The SimpleScreenRecorder author already replied, and SSR does set the non-interlace flag. Indeed, ffprobe shows "yuv420p(tv, bt709, progressive)" on the .mkv file created. When I use this file in Cinelerra (replace current project), the info from the file in resources->media shows Asset's interlacing "unknown" , and the Settings->Format has adapted all settings to this file except interlace mode, which remained as it was before the file was opened. Is interlace mode an exception in CinGG taking over format settings during "replace current project"? I presume that the YUV color settings in Settings->Preferences->Appearance are not influenced by any file loaded, else they would be in the Settings->Format screen. |
|
|
@Andrea_Paz, Interesting, SimpleScreenRecorder recommends to use mkv, and specifically not use .mp4 . I just found out that it's custom options allow setting the keyframe interval, see https://www.maartenbaert.be/simplescreenrecorder/custom-codec-options/ . I´ll try this next time, maybe then I don't need to transcode first. Also, CinGG reports that SimpleScreenRecorder does not set the interlace flag, I filed an issue for it on its github page. I'll do a CinGG build from the current git, see if that fixes the freezes already, although resources were set to text list mode. |
|
|
@MatN These freezes are bad news, but I do think that what you are seeing is the bug discovered/analyzed by Andrew that is related to the Vicons in the Resources window. If you have time, try setting the preview mode to "No Play" instead of "mouse over/full play" and see if you still get the freezes. If that works, then it probably is the Vicon bug checked into GIT. |
 |
I get freeze sometimes, too. I always compile from git. SimpleScreenRecorder by default uses mkv, I suggest you to use another container because it gives you a lot of problems and slowdowns in CinGG. And it's the mkv container's fault and not the codec it contains. |
|
|
Release 2020-05. If I have some time, I'll build from git and check. |
 |
Does this bug occur with released version, or with version from git? (I think I had similar freeze/hang bug, but it was fixed in git ...hopefully) |
|
|
The freeze occurs later if after loading CinGG, I _first_ delete all tracks and _then_ load the XML project file. Then I get the problem when deleting somewhere around 4 minutes into the video. After that, I used a workaround by rendering the project before the action that caused the problem, and then started anew with the rendered file. The project involved mainly adding lots of short titles and deleting unwanted pieces of video. This in-between rendering causes some quality loss but not a problem for this video. |
|
|
Cin_freeze_2020-05.png (69,263 bytes) |
- Anonymous
