Windows 11
v 22.09.23 64 bit
Just like someone else stated on here, I’ve used Shotcut for years without issue, now suddenly as soon as I move or click on anything within the program it freezes. It will eventually free itself up but only after a couple of minutes. This happens with every single click or movement. Again, I’ve been using Shotcut for years. What has changed? Not my computer.
Works for me without that issue on multiple Windows computers. Some ideas… maybe you made a bad upgrade; try reboot, uninstall, reinstall.
Maybe Windows is installing updates in the background while you are using Shotcut now.
Try with Windows Display Scale 100% if you have not.
Do some troubleshooting.
Download a recent previous version such as 22.04 as portable and compare.
There are about a million downloads per month with the vast majority being Windows. Surely if it worked as bad as you claim there would be more complaints.
Read this for what has changed.
Specifically for 22.09.23 things that have changed:
Do you have Shotcut’s folder whitelisted with your Anti-Virus programs?
Depending on when you upgraded, there would be substantial changes, which may cause older projects to no longer work or have undesired results.
You can go back and download any older version here. Zip files are stand-alone versions that don’t require installations.
While your computer may not have changed, your phone or software you are using to create video may have. It may be as simple as converting your cell phone footage to edit-friendly.
Thanks for the quick responses, very good tips and insight. I’ll try them out to see if they work. Especially comparing a portable version, white list, or just trying it again to see if it was something in the back ground (I looked at task manager and didn’t see anything else significant running).
For clarification, it was an older version that started doing it. So I updated Shotcut to the current version and unfortunately the same issue of lag/freezing existed. Other than windows updates nothing on my computer changed that I’m aware of. But if its working for everyone else I guess something has changed on my computer.
Hopefully it’s something simple like updates running in the background. Also, I ran across someone suggesting using proxy videos. I’m hopeful that if all else fails that will be a solution so that I can use this awesome program, but again, I didn’t use that before and had no issues.
Again, thanks for taking the time to help me out.
That is significant and important information that changes things.
It might not matter, but do you recall the version this started happening on?
Have you done a full uninstall including the removal of registry entries before reinstalling?
Try creating a new “testing” user profile and install on that to see what happens.
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:
Information about your media:
Other helpful information to provide:
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:
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.
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:
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!