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.
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.
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.
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.
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, 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)
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?
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?
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?
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:
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.
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?
./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.
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!
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!