Linux: Cannot export

[shotcut]

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

[mevla]

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.

[ndq0345934]

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.

[shotcut]

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

[mevla]

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.

[mevla]

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.

[brian]

@shotcut

Failed with exit code 11

There are also some ideas here:

Export failed - Find solutions

Your export failed for one or more reasons. There is always a reason why it failed. Below are the posts by others describing their faults and solutions. This tutorial is not a definite tutorial as you may have a unique situation not described in here. Time Code After failure to export it may display a time code, make a note of the time displayed and look on your timeline to see what’s there that could be causing the problem. It could be a clip, audio or video file, transition. [firefox_20…

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.

[paulsharry23]

i am also facing same problem

[paulsharry23]

Same problem..

[mevla]

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.

[leebut]

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.

[mevla]

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.

[ndq0345934]

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)