Same problem here, only on Linux, same version.
Doesn’t matter what I do, crashes at random. And I can not reproduce it.
Most of the time when it crashed I dragged an audio file into an audio track.
But that could just have been coincidence.
Sometimes it works an hour without problems, sometimes only minutes.
I edited 9 hours today and had about 30-40 crashes. Great.
@Oli,
Sorry to hear that. Which version and format?
With so many crashes, have you checked the log file?
Have you tried backing up then removing the ~/.config/Meltytech and the ~/.local/share/Meltytech folders before reinstalling?
Have you tried settings → reset inside the program?
I’m also on Linux (a low spec machine at that) and my experience has been the opposite of yours, with program stability improving over time.
Thanks for your answer!
Shotcut version: 22.09.23
Linux:
Description: Manjaro Linux
Release: 22.0.0
Kernel:
5.15.72-1-MANJARO
Its not really a “crash”, rather its a complete freeze of the process, which I need to kill, otherwise it hangs forever.
The log is rather empty, altough it seems to me the following messages may be related to the crashes:
Util::isMemoryLow available RAM = 10752564 KB
I have 16 gb ram, and there is 10 gb still left, so, that shouldnt be a problem. Maybe wrong direction.
Did reset/file remove you suggested.
No change so far.
16gb of ram is super helpful. That is just one part of the whole picture. Just know that I know what Manjaro is, have yet to try it, and my knowledge of Linux is very basic in nature.
Did you download Shotcut from here?
How about some more computer information:
- What is the size of your data drive?
- What type of data drive do you have? (HDD, SDD, NVME)
- Are you using the same data drive for the OS and for video editing/media storage?
- Specifications of your CPU?
Information about your media:
- Video: Resolution & FPS (As shown in the properties window of Shotcut)
- Video Mode: Click on Output, then Properties
Other helpful information to provide:
- What steps are you performing when the crash happens? The minimal amount of steps the better. Other people may attempt to recreate the same issue you have.
- Are you applying any filters, if so, which ones?
- When Shotcut crashes, it is recorded in shotcut-log.txt Can you upload that file?
- That log file can be found here. Every time Shocut is restarted it the log file is restarted as well.
- The project file (MLT file) that you are working on, is this created with a different Shotcut version?
1 Like
Did you download Shotcut from here?
No, its in the official community repo from manjaro. Thats the normal way to get it for this distro. Dont see where it would make a difference since its the newest version anyway and the source is trustworthy.
- What is the size of your data drive?
1 TB - how does this matter at all? my hard drive isnt full or anything.
I am using ext4 btw.
- What type of data drive do you have? (HDD, SDD, NVME)
SSD- Are you using the same data drive for the OS and for video editing/media storage?
Yes, but it has a read speed of up to 600mb/s. So again, I dont see the point.
- Specifications of your CPU?
i5-2500K
- Video: Resolution & FPS (As shown in the properties window of Shotcut)
1152x864 @ 25 FPS
- Video Mode: Click on Output, then Properties
Set to Automatic.
- What steps are you performing when the crash happens? The minimal amount of steps the better.
Other people may attempt to recreate the same issue you have.
If answered this question above before. Please read my answers carefully.
- Are you applying any filters, if so, which ones?
No
- When Shotcut crashes, it is recorded in shotcut-log.txt Can you upload that file?
Again, like above, it freezes, it does not record anything new after the freeze.
- The project file (MLT file) that you are working on, is this created with a different Shotcut version?
No.
In other posts about Manjaro, it’s been shown that there are versions of Shotcut that are not supported here.
Here are a few posts:
I did read that you were dragging audio files on an audio track. You also stated that you edited for 9 hours. Perhaps that is all you’re doing. I didn’t want to assume that was it.
For finding the Video Mode, when you click on Output, and Properties, it does not say “Automatic”.
On my W10 computer, I attempted to duplicate the same issue.
Steps I took:
- I made a custom video mode 1152x864 25fps.
- Dragged a 1080p 25fps clip to V1 (No use of any filters)
- Created an audio track
- Inserted 20 audio files, from MP3 to WAV files onto it. Either dragging from the File Explorer system, or File Open, then dragging from Source to the Audio track on the timeline.
From a Windows 10 aspect, I couldn’t find a bug. Perhaps someone with Manjaro can attempt to duplicate. Although I only tried once, it doesn’t mean it’s not there.
It shouldn’t, but then again there are all sorts of variables that might cause a particular application to misbehave on a specific system. Another question I should have asked; did your problems start with the latest version? Possibly not, but If so then you could try a previous version from here:
Since removing the .config folders made no difference, here is one way to proceed based on what I know so far (assuming the problem isn’t solved by using an older version).
I’d actually remove the current version using Pamac (or pacman), but you will still need to manually rename the .config folders as a backup (yes I know you’ve removed them once, but since I am taking a slightly different approach below, they need to be out of the equation again).
Then go download an AppImage from here for testing purposes just to see what happens. Once it is downloaded, you will need to make it executable. In a terminal:
sudo chmod 711 /opt/shotcut-linux-x86_64-220923.AppImage
I put all my AppImages in the opt folder, so adjust accordingly (you may not need sudo). Be aware, I am trying to be thorough with my recommendations, so you probably know how to do a lot of this already. However, I’m going for lowest common denominator, so if others who are less experienced with a similar issue read this, they can potentially follow along. If you prefer a portable tar then by all means try that, but I KNOW the AppImages work fine on my machine (Xubuntu and Arch) with an AMD A8 CPU, Radeon R5 Graphics, 12Gb RAM (only 10 usable), and a 1Tb HDD, hence my recommendation.
Then I would start a new project (not an existing one just yet, even though the AppImage is the same version) and do some testing. It seems like it doesn’t take much for your system to freeze up, so you will probably know in relatively short order.
@Hudson555x beat me to it. I’d attach the full log and someone will take a look.
On a side note, I completely forgot to ask, but I assume you have enabled proxy and preview scaling? I can’t work without those enabled when dealing with 1080p and above.
That’s all I’ve got for now.
1 Like
Thanks for your time, and thank you for your answers!
I did not use the preview settings, since my source material was pretty low res, I will use it anyway in the future.
The appimage idea is a good one, ill try that.
I will test a few options and see where it leads me.
So far, thanks for your ideas!
I did not reproduce it.
[Info ] Application::Application install dir = “/usr/bin”
Not one of my builds and thereby not supported by us.
Well, its in the official repos for a whole distribution and its the newest version and you are not supporting it? Ok, in a way I understand, but almost all users of this distribution will be using it the way I do. But, whatever.
I just downloaded the portable version from Shotcut - Download so it’s not a “support” issue anymore and guess what?
Same crash.
./shotcut: line 21: 222691 Segmentation fault (core dumped) bin/shotcut “$@”
Now, this is actually a version you support. So, what now? 
I am a Linux user for over 23 years. Please understand that there are very many distributions, and there are very few technical people helping this project. The two developers in our project are not going to run a bunch of distros and verify every build of every version. Do you not recognize fragmentation, why companies are reluctant to support Linux, and why app bundles are a thing now?
Now we are a step closer to being on the same page. But also you can try to debug it yourself since I don’t know how to since I did not reproduce it.
One thing I found in your project that might be a contributing factor is very odd project resolution and aspect ratio.
This suggests you were using Settings > Video Mode > Automatic, and the first clip you brought it is like this. The weird frame rate also suggests that first clip was variable frame rate, which is not safe for editing. We try to show a warning for that, but it is not perfectly detectable.
I see in your log that you are using proxy and preview scaling. You can try turning those off to see if it makes a difference.
In addition, I just remembered this bug since you said it is drag-n-drop to the timeline. You can try using the timeline toolbar buttons or shortcut instead to see if the problem is specific to drag-n-drop:
1 Like
Do you not recognize fragmentation, why companies are reluctant to support Linux, and why app bundles are a thing now?
Yeah, I totally understand. In the end, I am just grateful that software like shotcut even exists. And I am very grateful that people like you care about it and develop it. So, the biggest point I want to point out is: a big thank you for all that.
Also, Bugs are normal. Software development can be hard, and squashing bugs even harder.
Back2topic:
I took the time and converted all source material to constant framerates/different resolutions/etc. and tested with them: same crash behaviour. So, it does not seem to be the source material.
My workaround was to copy directly into the timeline from another open shotcut instance, that worked out well for me.
But also from the bug report you mentioned:
" Use “Add Selected to the Timeline” from the Playlist menu to avoid dragging and dropping."
works fine as a workaround.
Funny thing: when you add to the playlist and drag it from there, there is no crash. Just when you drag it from the main editing area(or player), but I guess you know what I mean.
So, that workarounds are really ok for me and after reading the bugreport you linked, it seems to me that it could be the same issue.
Anyway, thank you for your time and contribution!
I really love shotcut and just wanted to contribute in a way, maybe I could have done a lot better. (still learning english ;))
I am having exactly the same problem that was described at the beginning of this thread. Like many of you, I have been using Shortcut very successfully for years on my current hardware - but I have never seen odd performance problems with the UI until now.
My i7-5820k (6 cores, 12 threads clocked at 3.3GHZ), 32GB, with 24TB of 7200rpm disk storage (with distributed paging files across all spinning disk drives), Windows system recently upgraded itself from 10 Pro to 11 Pro around the same time Shortcut was upgraded to the most current version (22.10.25). I have seen no adverse reactions whatsoever from any other applications, including many heavy duty games under Windows 11.
In Shortcut once I try to load an input video file, the Shortcut UI’s performance becomes so sluggish that it is practically unusable - often taking 2 or 3 minutes between each fairly trivial interaction with the UI In the Task Manager I see “melt.exe” consuming 60% to 90% of the CPU resources, using a couple of gigabytes of memory, and doing 3 to 4 MB/s of disk activity. I think it’s doing this even before I have created any background job to process the input files.
I’ve tried turning the hardware encoder on and off and de-installing/re-installing Shortcut with no effect. I’m not sure if the particular input files (created by a standalone hardware encoder or a commercial video editing program, “PowerDirector” that I used to use which are usually quite a bit larger than the files I create with Shortcut) may be triggering the problem too. The input files I’ve been seeing these problems with recently are are roughly 4 to 15GB in size. It should also be noted that even when the Shortcut UI is being very, very unresponsive, any other application I bounce back to on the desktop is running fine, with no performance issues at all.
I’ll keep playing with it to see if I can figure anything out that effects this problem, but when this problem is occurring - it makes using Shortcut totally painful! Thanks in advance for any further thoughts or suggestions!
Well there you go. That only runs for jobs, and it is a job from a previous session. You should kill it if you do not need it anymore, or wait for it to complete before using Shotcut.
Thanks for the explanation, but I’ve run tons of jobs in Shortcut for years and never seen the UI get completely stalled like this. I’ve killed “melt.exe” if I see it running when I haven’t queued up a displayed job in Shortcut, and it makes no difference. Literally, to load a video file, move it to the timeline, and then export it as a new file (at the same 1920x1080 resolution) can take 10 to 15 minutes - if it can complete each of those steps at all. I’ve seen Shortcut get so sluggish that Windows starts saying it’s unresponsive and I eventually have to kill the process.
It even takes several minutes to bring up and fully render all the portions of the load and save menus too. Once Shortcut is working on a job it has queued up, consuming about 80% to 100% of the CPU resources in the process - I can even load up and play Destiny 2 with no observable slowness or side effects at all (because Shortcut is running at it’s “low” priority I presume) - so my system hardware is performing. perfectly as expected.
The CPU and GPU aren’t thermal throttling either, peaking out at just over 50C each - even after running 100% load on all cores (video rendering historically) for over an hour.
As mentioned above, I was suspicious that something in the exact format of the MP4 files I’m importing is causing something in Shortcut’s UI to go into a tail spin. Something is different when the input file is 15GB, yet the output file that Shortcut outputs (with the same resolution and frame rate) is only 1.8GB - with absolutely no degradation in observable quality. However a brief test shows that even if I’m importing a much smaller file, one that was actually rendered by Shortcut - the UI still slows down tremendously once the file is selected.
I’ll still keep messing with it, to see what else I can figure out. Thanks again for your thoughts!
When Windows users have this issue, there are some common themes:
- Some antivirus program is getting in the way. Try turning them off as a test
- Some obscure security setting needs to be changed (like ASLR)
- They are storing their media files on some remote or removable disk
I hope you are able to unlock your problem and share the solution with us.
Thanks for your suggestions!
Haven’t tried turning off my Norton anti-virus, but I’ve been running it as long as I’ve been using Shortcut so it’d be surprising if that’s an issue.
In the Windows advanced security settings ASLR is off (and the fine print makes it sound pretty scary to turn on), where as DEP and CFG are both on. I could not turn on the Core Isolation Memory Integrity setting because most of the drivers that run my motherboard audio and gaming devices like my Logitech headset aren’t blessed enough by Microsoft Don’t really see how that would effect the performance of the Shortcut UI going into the toilet as much as out and out crashes anyway?
I have the general Windows performance settings set to “Programs” rather than “Background: tasks”, which seems to have no impact whatsoever on all the background tasks that I do run on this system. (It runs a media server, home security camera hub, the online backup client, and several web servers on my local network - all without missing a beat even when the system is running flat out). None of that environment has changed for years.
All the media files I’m working with as well as Shortcut’s install and temp working folder are on full speed SATA-3 hard drives which are working perfectly for any other processes trying to use them.
Someone way above in this thread suggested going back to an older version of Shortcut, which I may try - even though I’d be pretty surprised if that’ll actually help. It seems unlikely that Shortcut’s UI thread is getting starved for system resources (given that anything else, including a huge game, is able to run just fine). I wish I could see what the UI is actually doing and waiting on, or is it just running at a low priority as the job tasks do, that that’s keeping it from getting enough? I’ll keep playing with it and keep you posted - thanks again for your help!
Does Norton use more, less, or the same amount of memory when using Shotcut?
Have you white-listed Shotcut with Norton?
Thanks for your reply!
None of the Norton processes seem to use any more memory or CPU resources when Shortcut is running. The only program specific white-lists I can find only relate to communication firewall rules, not anything to do with the anti-virus or just running the program. Norton does accept Shortcut’s install program as a “trusted application” based on automatic customer feedback.
I looked at the Windows compatibility settings for Shortcut, but there was nothing there that looked reasonable to try. I sure don’t want it, or anything, to ever run in Windows 8 compatibility mode!
This evening, I was able to process a small file with Shortcut just fine - but like I’ve been seeing it totally bogged down and the UI pretty much stopped responding once I loaded a 5GB input file.
All of my 4 hard drives are formatted with NTFS, using different allocation unit sizes depending on their total size and what’s on them. I just replaced one of the 8TB drives (the one where most of my videos are stored) with a new one, because the old one had been spinning for over 30,000 hours and its brother drive failed a couple of months ago. I formatted the new drive with a 256kb allocation unit, while my other 8TB drive was formatted with a 128kb unit size. I copied one of the input files from the one with the big allocation unit to the smaller one, to see if Shortcut worked better with it on that drive. Well, not really - it still ran through the steps I did on the UI like a stuck pig, much slower between mouse clicks than I would normally expect - so no conclusive differences there.
I may try to download another free, open source video editor to see if it can process the same input files better than Shortcut is currently able to do. Problem is that when I was looking around and found Shortcut several years ago, most of the other ones sucked by comparison. I’ll look around again but If I’m desperate I may try the bloatware one that Microsoft shipped with Windows 11, ClipChamp, which I deleted but wouldn’t expect too much from…
I’ll keep this thread posted, and again thanks for your help!
I tried installing an older version of Shortcut, 22.06.23 just to see if it would behave any differently with the UI hangs, but it did not. As soon as I tried to load a 15GB input file, the UI totally hung and never completed that action. I saw its memory use as reported by the Windows task manager jump to over 21GB - making the total system memory in use go up from about 23% to 97%.
So I know I was probably running version 22.06.23 successfully under Windows 10 for quite a while, so this again focuses attention on what could have changed to impact its performance in the Windows 11 environment. Not clear what could be the direct cause, since every other application I had running before the Windows 11 upgrade is still working and performing normally.
I re-installed Shortcut’s latest 22.10.25 version and will continue to try to understand what’s going on with under Windows 11.