Linux: Cannot export

This is simply a warning and not blocking export. It cannot accurately predict how large the file will be. Read it; it is simply telling you getting low on disk space.

You see that time code next to “failed” in the job view? There is likely a problem around that point. But maybe also you are running out of memory.

I am not a developer of Shotcut (though I have done software development on other projects), so take this with a grain of salt - but in general, I would say that running any modern OS with your disk drive 95% full is likely to run into intermittent problems. The OS needs some room to swap things out, and even though the “swap file” may “only” be, say, 4Gb, the way that the system allocates temporary files can chew up a lot more space than that.

Keep in mind that video is VERY memory/disk intensive. If your RAM is not overly generous, on top of a 95% full disk, then I would say you need to address the memory and disk space issues before trying to pin down any particular cause for any software that may be crashing.

Hello. To everyone else: I haven’t had much time to pursue the problem these last few days. However there was one successful export of the current state of the project. I’ll be back to it in the coming days.

@awake : There are currently three disks. The disk here labeled /VM is not hosting the OS. And there’s no user partition on that one. However the main disk with the OS and the user partition is also on the low side. That might be a good point and I can do some cleanup on that one. I can rather easily clear up 16GB on the OS drive, which in turn would give more space for /tmp.

System memory is 16GB and the swap is on the /VM disk with the /VM disk having 14GB free. Which means that after cleanup the thing that will be different will be the /tmp directory having at least 16GB available (actually more). I can give this a try, no problem. In the next few days. Thanks.

1 Like

Hello. Sorry for the delay ! I have made some space. Now the main drive which hosts the OS and /tmp has 18GB free. I have tried an export of a very simple clip taken from youtube which I split in two parts and put the last part to the beginning.

It failed again. I rebooted and tried another export w/o changing anything and it worked.

Looking at the log it reported the following when it failed:

(cannot include the log text, see screenshot)

Looking at the log when it succeeded, it reported the following:

(cannot include the log text, see screenshot)

My question is: Is it possible to add a ‘verbose’ or ‘debug’ flag to melt-7 ?

Ans here’s the log text:

You need to look at the job log, not the application log. right-click the failed export job and view log.

Here’s attached the export job log that was shown just now. I had to export twice since the first export worked all right. Then I moved a clip a bit to ‘do something’ and tried to export again, and it failed.

exportLog2.txt (2.5 KB)

From the application point of view, melt-7 is called and apparently is failing. There’s a verbose switch passed on to melt-7 although it does not provide much feedback in that case. Is the export log the actual output from melt-7 ?

RAM is 16GB
OS is Xubuntu 18.04
/ has 18GB free space, which includes /tmp

The project is made of a single youtube clip which is then split in two halves. The 2nd half is put in front of the first and that’s it. Nothing else except just a little transition where the two clips are overlapping.

I tried again and it failed. Not at the same location. There are two clips but it does not failed always at the same place.

Thanks.

i use Linux exclusively. that said, most of my troubles came from export settings. some codecs are better than others and some quality settings, etc are better/worse as well. hardware acceleration or not, is also a factor (i actually get better results with software than hardware, at the cost of speed). one huge factor for me in the past was removing movflags=+faststart from the “other” tab in export. but i have not tried replacing such recently.
just some considerations to pursue. squashing to 1 track is not necessary.

From the log

Failed with exit code 11

Not enough information, and I am unable to reproduce your problem. Turn OFF Export > Advanced > Video > Parallel processing. See everything written above again plus FAQ

Export > Advanced > Video > Parallel processing is already disabled.

As for information that’s all the information shotcut is giving, I cannot squeeze more debug information out of it.

I am willing to do everything to provide more information but shotcut as it is now will only give what was shared here. Hence I was asking about additional debug flags for either shotcut and/or the mset-7 utility.

My domain of expertise are embedded Linux devices. I can debug things. Provided the software I use and write does have additional very verbose debug flags. Otherwise it is guessing and that takes time and is not efficient. 11 as a signal is a segfault.

So if shotcut supports more debug options, let me know I’ll be happy to try them.

I’ll browse the faq just in case.

Since it works one time and the other it doesn’t without any modifications, there’s obviously some instability. Is it hardware related or software related is the question.

Thanks. I did a couple of exports removing that parameter each time and it did not improve the state. I’m using the default settings for export. I do not know much about codecs so I’m not that much inclined in just ‘fooling around’ with parameters hoping to strike the right combination.

There’s clearly, from how I see it, some instability as it exports nicely once and w/o any modification to the projet will not the second time around. As far as I know the computer I built and use does not have any hardware support for videos. I’m using the ASUS mobo’s display output. It is an i5-3570 CPU @ 3.40GHz with 16 MB RAM. Not the latest around although I think it can handle this.

1 Like

There are also some ideas here:

Coincidentally, one of the solutions for exit code 11 was to delete a video track. But I suspect that having more than one video track is not the problem itself.

If an export fails inconsistently, and at a different time for each try, then we typically ends up being a resource problem (memory or disk). If an export fails consistently at the same spot, then there is usually a problem occurring with a specific filter or transition. In those cases, the user can delete the filter or transition that occurs around the time of the failure and then recreate it.

i am also facing same problem

Same problem..

I tried to help by asking questions. For instance, I asked if the Qt multitasking framework was also used. I asked about mset-7. I was about to ask for a debug version to help troubleshoot the problem. Debug versions at the text level incorporates much more details in the log files. If not enough, or if debug statements are pretty much lacking (which is common in software development), core dumps can be produced and traced back.

I worked in the domain for more than 20 years so I know that when a developer says he can’t reproduce the problem when OBVIOUSLY he wouldn’t be able to do so (in this case by not having the same video project to start with) it actually means he’s not interested.

Nevertheless I was able to save the current project successfully twice in a row (not three times) but it feels like a lottery. Due to hardware ? Not so sure. It would mean to run hardware and memory tests for a day or two to prove that the hardware is OK, which I haven’t done.

Not having any problem using DAWs (Bitwig, Harrison Mixbus 32C, both with wine/linvst Windows audio plugin bridge) or using the computer in other ways. I know, these are not video applications but, no problems.

Have you tested your RAM for problems? I ran memtest86 on my RAM after various issues with Inkscape crashing. My RAM produced errors and failed one test on each pass of four. New RAM = no problems.

Sorry for the delay. I did run a RAM test. memtest86+ 5.01, 2 passes over more than 4 hours. No problems at all.

I noticed that it was possible to actually ‘hear’ the exporting as the machine’s fans were speeding up making more noise. It was possible to determine when there was a pause in the heavy processing as the fans would go back to normal. Then they’ll speed up again as another stage of exporting went on. So on so forth.

So I looked into the BIOS and saw that the motherboard was set on ASUS’ top speed configuration. I must have set that some long time ago. I’ve put it back to the default normal configuration and since then no problems exporting although it’s a bit too early to confirm. Also, no more extra fan noise when exporting, everything runs as usual.

I think it could make sense as far as if the CPU was under strain because already running at max speed, it could create the conditions for random failures.

not sure if it will help, but i’ll offer my export presets.
these files should be saved in ~/.local/share/Meltytech/Shotcut/presets/encode/
most are software export (vaapi264 & libx265), one is hardware export (hevc_nvenc [nvidia]).
YMMV. i use these for youtube. 65% quality is nominal. i only use 70% when i really “need” more detail.
I use the AppImage releases.

encode-presets.zip (4.6 KB)

This topic was automatically closed after 90 days. New replies are no longer allowed.