You can upload the file (the little bar with an up-arrow above here).
Here is the bottom of the Shotcut log file, after attempting to import the “Colours.mp4” input file:
Sample=shotcut-log.txt|attachment (2.7 KB)
In the text file you uploaded, it shows you’re using a 1080p, 60fps Video Mode.
I also see that your files are on a HDD.
I used the Colours - 26493.mp4 file. The file is 1080p, 25fps.
For my test, I used the 1080p, 25fps Video Mode.
Used a 7500rpm HDD.
Shotcut open, no files loaded.
Exporting default. Watching a stream, multiple programs open.
32gb Memory
4.3 GHz CPU (water cooled)
Windows 10 Home
Windows Defender is active with Shotcut’s folder whitelisted.
No other antivirus
Windows and Shotcut are installed on an SSD drive.
Shotcut 22.10.25
Not able to duplicate memory issues as outlined in the 1st post.
Based on the following:
I’m assuming you’re doing a clean boot with all startup items disabled before testing any of this?
I’d be disabling Microsoft teams and a bunch of other cr*p too.
At last - Eureka!
I “uninstalled” to removed Shotcut from the system. verified that its install directory was totally gone, manually removed the contents of the app data directory, and then re-installed it with the option to clear all its configuration settings in the Windows registry. I’d done most of these steps several times before, but I’m not sure I did all of them at once, exactly like this.
Anyway, bang - now it works perfectly once again! Not dead sure why though, as the app data directory didn’t have much in it except for some really basic configuration stuff (the SQL DB was empty) and the log file, and the registry entries should have just had more configuration information from the description in the installer. (I would have thought that the “uninstall” process should have removed the registry entries too, but apparently it didn’t).
It’ll be nice to be able to use Shotcut once again, as I really like its interface for editing much better than the other editors I did some testing with!
Thank you all for your numerous suggestions and assistance in working through this and figuring it out! While I still have no clue what was actually going on, the fact that it’s fixed is all that matters!
3 Likes
Congrats, and well done. I bet that feels good!
My bad for not pointing you to this post, which is my go-to for “complete uninstall”.
Glad you got it sorted and reported how you did that. This may help others in similar situaltions.
And just like that, it’s broken again…
After running Shotcut successfully, without issue last night (after cleanly re-installing it), when I tried to use it again this morning on my test input file - it was back to the same old problem! After attempting to import the small MP4 input file, the UI hung, and a minute or so later the Shotcut process once again started consuming memory hand over fist. I killed the process when it was passing 8GB of memory usage for the 56MB input file…
Not clear what could have “broken it” from last night to this morning. About the only desktop apps I had run were the web browser, standard Windows e-mail client, and Destiny 2 (off EPIC). All the normal background services were constantly running of course which included: Abyss web server, Bonic, CoreTemp, CrashPlan online backup, Discord’s background service, Filezilla FTP server, iSpy security camera hub, Telegram, and Zoom’s background service. All of these have been running for years, successfully co-existing with Shotcut for all of that time. None of the messaging apps that Microsoft packaged in Windows 11 were enabled or running.
So as a quick fix, I simply re-installed Shotcut again - this time over top of the same install directory - again having it clear all the registry entries. I also manually removed all the stuff in Shotcut’s working directory - noting that this time the SQL DB actually contained some data, which it had not when I went through this last night.
Upon restarting Shotcut again, I changed it’s temp working directory from its default location on the C-drive and after it restarted itself again noticed that the SQL DB again had something in it - so I manually erased it again.
After all that, yep - Shotcut was able to import the test file just fine, taking a second or two to do it with the UI responding normally as soon as it was done. Now the question is, for how long will this keep working?
It’ll be sort of painful if I’ll have to re-install Shotcut every time I want to use it and begs the question - what is in the Shotcut registry entries and where exactly are these hidden in the registry? I haven’t played around enough with the Sysinternals utilities enough yet to figure out how to get it to show me…
I can’t really imagine that any other app would be messing with the Shotcut registry entries, or how corrupting them could or should cause the hung UI and wild memory consumption effects.
Does anyone know of any way to turn on more detailed debug entries in the Shotcut log file? Really curious about what it thinks it’s doing when it’s grabbing half a gigabyte of memory every second or so.
Also, does anyone know where it stashes its entries in the Windows registry and exactly what type of information it is keeping there? The installer implies that it is configuration information, but that also seems to be some of what’s in the working directory too.
Back to square one!
Forgot to mention, when I had test Shotcut last night I did restart it, and it still seemed to work o.k. afterwards.
I just tried to import another tested video into the same instance of Shotcut that I’d just re-installed, and it went into the weeds again, wildly grabbing a gigabyte of memory a second for a small 150MB input file after it had been “thinking about it” with the UI hung for a couple of minutes. Once again, what’s going on here?
Just did another test sequence - repeatedly importing the same two test input files (one after the other) after hitting “new” from the File pull down menu first. Worked perfectly a dozen or so times in a row.
However, when I exited Shotcut, restarted it, and then hit “File->New” before trying to load one of the test files, it immediately went down in flames again.
The more I look at this, the more confused I get about what’s going on! 
Sorry to hear your problem is back. The Windows Registry entries (and their location) are described here:
There have been previous reports of memory increases on small projects that have been solved by changing the Display Method. What are you using?(Menu item Settings → Display Method)
I am using “DirectX (ANGLE)” on Windows 11, if you have a different setting setting, try that. Another one to try is “OpenGL”.
Thanks! I poked around in Regedit and found a few obvious references to Shotcut - some of which were easy to understand and some were incomprehensible numbers. I’ll look through the link you posted tomorrow.
Don’t forget to try changing the Display Mode.
Thanks! My Display Method defaults to DirectX, which is what I’ve always used historically and never seen any particular problem with. My video card has 8GB of memory and can handle DirectX-12 if need be. I tried switching the Display Method to OpenGL a few days ago with no effect. I don’t have any preview scaling enabled at all
A few days ago I upgraded to the latest 22H2 version of Windows 11 and tried the Pixabay file again. Again, no problems at all. I really don’t know what else to suggest.
I looked at the Shotcut settings in the Windows registry and from the variable description given above, I see that the “appdatadir” is set to the Shotcut working folder which (again from the variable description document) means that all the other variables are being set from the INI file there, not from the registry. Not sure this is correct though, because I don’t see the “savePath” variable set anywhere in the INI file, and Shotcut is remembering it and getting it from somewhere… Anyway, here is my Shotcut.ini file, which I don’t see anything wrong with:
[General]
geometry=“@ByteArray(\x1\xd9\xd0\xcb\0\x3\0\0\0\0\x1\x44\0\0\0\x1c\0\0\x6;\0\0\x3\xcc\0\0\x1\x45\0\0\0>\0\0\x6:\0\0\x3\xcb\0\0\0\0\0\0\0\0\a\x80\0\0\x1\x45\0\0\0>\0\0\x6:\0\0\x3\xcb)”
geometryDefault=@ByteArray(\x1\xd9\xd0\xcb\0\x3\0\0\0\0\0\0\0\0\0\0\0\0\x4\xf5\0\0\x2\xaf\0\0\0\0\0\0\0\0\0\0\x4\xf5\0\0\x2\xaf\0\0\0\0\0\0\0\0\a\x80\0\0\0\0\0\0\0\0\0\0\x4\xf5\0\0\x2\xaf)
smallIcons=false
textUnderIcons=true
titleBars=true
toolBar=true
windowState=“@ByteArray(\0\0\0\xff\0\0\0\0\xfd\0\0\0\x3\0\0\0\0\0\0\x2\x64\0\0\x2’\xfc\x2\0\0\0\x1\xfc\0\0\0T\0\0\x2’\0\0\x1\x45\x1\0\0\x18\xfa\0\0\0\x3\x2\0\0\0\x5\xfb\0\0\0\x18\0P\0l\0\x61\0y\0l\0i\0s\0t\0\x44\0o\0\x63\0k\x1\0\0\0\0\xff\xff\xff\xff\0\0\0|\0\xff\xff\xff\xfb\0\0\0\x16\0\x46\0i\0l\0t\0\x65\0r\0s\0\x44\0o\0\x63\0k\x1\0\0\0\0\xff\xff\xff\xff\0\0\x1,\0\xff\xff\xff\xfb\0\0\0\x1c\0p\0r\0o\0p\0\x65\0r\0t\0i\0\x65\0s\0\x44\0o\0\x63\0k\x1\0\0\0\x46\0\0\x3\x1a\0\0\0Y\0\xff\xff\xff\xfb\0\0\0\x14\0\x45\0n\0\x63\0o\0\x64\0\x65\0\x44\0o\0\x63\0k\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\x95\0\xff\xff\xff\xfb\0\0\0\x12\0N\0o\0t\0\x65\0s\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0Y\0\xff\xff\xff\0\0\0\x1\0\0\x1\x46\0\0\x2’\xfc\x2\0\0\0\x1\xfc\0\0\0T\0\0\x2’\0\0\0\x8b\0\xff\xff\xff\xfc\x1\0\0\0\x2\xfb\0\0\0$\0\x41\0u\0\x64\0i\0o\0P\0\x65\0\x61\0k\0M\0\x65\0t\0\x65\0r\0\x44\0o\0\x63\0k\x1\0\0\x3\xb0\0\0\0\x44\0\0\0\x44\0\xff\xff\xff\xfc\0\0\x3\xfa\0\0\0\xfc\0\0\0\x96\0\xff\xff\xff\xfa\0\0\0\0\x2\0\0\0\x3\xfb\0\0\0\x14\0R\0\x65\0\x63\0\x65\0n\0t\0\x44\0o\0\x63\0k\x1\0\0\0\0\xff\xff\xff\xff\0\0\0r\0\xff\xff\xff\xfb\0\0\0\x16\0h\0i\0s\0t\0o\0r\0y\0\x44\0o\0\x63\0k\x1\0\0\0\0\xff\xff\xff\xff\0\0\0Y\0\xff\xff\xff\xfb\0\0\0\x10\0J\0o\0\x62\0s\0\x44\0o\0\x63\0k\0\0\0\0\x46\0\0\0o\0\0\0o\0\xff\xff\xff\0\0\0\x3\0\0\x4\xf6\0\0\x1\r\xfc\x1\0\0\0\x3\xfc\0\0\0\0\0\0\x4\xf6\0\0\0\xc8\0\xff\xff\xff\xfa\0\0\0\x1\x2\0\0\0\x2\xfb\0\0\0\x1a\0K\0\x65\0y\0\x66\0r\0\x61\0m\0\x65\0s\0\x44\0o\0\x63\0k\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\x34\0\xff\xff\xff\xfb\0\0\0\x18\0T\0i\0m\0\x65\0l\0i\0n\0\x65\0\x44\0o\0\x63\0k\x1\0\0\x2p\0\0\x1\xc8\0\0\0\xc8\0\xff\xff\xff\xfc\0\0\x5\xff\0\0\x1t\0\0\0\0\0\xff\xff\xff\xfa\0\0\0\x3\x2\0\0\0\v\xfb\0\0\0\x1e\0V\0i\0\x64\0\x65\0o\0V\0\x65\0\x63\0t\0o\0r\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0"\0V\0i\0\x64\0\x65\0o\0W\0\x61\0v\0\x65\0\x66\0o\0r\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0\x1a\0V\0i\0\x64\0\x65\0o\0Z\0o\0o\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0\x1a\0V\0i\0\x64\0\x65\0o\0Z\0o\0o\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\xfb\0\0\0\x1a\0V\0i\0\x64\0\x65\0o\0Z\0o\0o\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0\xfb\0\0\0\x1e\0R\0g\0\x62\0W\0\x61\0v\0\x65\0\x66\0o\0r\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0\x1a\0R\0g\0\x62\0P\0\x61\0r\0\x61\0\x64\0\x65\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0$\0V\0i\0\x64\0\x65\0o\0H\0i\0s\0t\0o\0g\0r\0\x61\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0"\0\x41\0u\0\x64\0i\0o\0W\0\x61\0v\0\x65\0\x66\0o\0r\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0"\0\x41\0u\0\x64\0i\0o\0S\0p\0\x65\0\x63\0t\0r\0u\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0,\0\x41\0u\0\x64\0i\0o\0L\0o\0u\0\x64\0n\0\x65\0s\0s\0M\0\x65\0t\0\x65\0r\0\x44\0o\0\x63\0k\0\0\0\x2\x66\0\0\x1\xc8\0\0\0W\0\xff\xff\xff\xfb\0\0\0\x16\0M\0\x61\0r\0k\0\x65\0r\0s\0\x44\0o\0\x63\0k\0\0\0\x3\xf8\0\0\0\xfe\0\0\0\x44\0\xff\xff\xff\0\0\x1@\0\0\x2’\0\0\0\x1\0\0\0\x2\0\0\0\b\0\0\0\b\xfc\0\0\0\x1\0\0\0\x2\0\0\0\x1\0\0\0\x16\0m\0\x61\0i\0n\0T\0o\0o\0l\0\x42\0\x61\0r\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0)”
windowStateDefault=“@ByteArray(\0\0\0\xff\0\0\0\0\xfd\0\0\0\x3\0\0\0\0\0\0\0\0\0\0\0\0\xfc\x2\0\0\0\x1\xfc\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\xff\xff\xff\xfa\xff\xff\xff\xff\x2\0\0\0\x5\xfb\0\0\0\x1c\0p\0r\0o\0p\0\x65\0r\0t\0i\0\x65\0s\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0Y\0\xff\xff\xff\xfb\0\0\0\x18\0P\0l\0\x61\0y\0l\0i\0s\0t\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\xc8\0\xff\xff\xff\xfb\0\0\0\x16\0\x46\0i\0l\0t\0\x65\0r\0s\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\x1,\0\xff\xff\xff\xfb\0\0\0\x14\0\x45\0n\0\x63\0o\0\x64\0\x65\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\x95\0\xff\xff\xff\xfb\0\0\0\x12\0N\0o\0t\0\x65\0s\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0Y\0\xff\xff\xff\0\0\0\x1\0\0\0\0\0\0\0\0\xfc\x2\0\0\0\n\xfb\0\0\0,\0\x41\0u\0\x64\0i\0o\0L\0o\0u\0\x64\0n\0\x65\0s\0s\0M\0\x65\0t\0\x65\0r\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfc\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\xff\xff\xff\xfc\x1\0\0\0\x2\xfb\0\0\0$\0\x41\0u\0\x64\0i\0o\0P\0\x65\0\x61\0k\0M\0\x65\0t\0\x65\0r\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\x44\0\xff\xff\xff\xfc\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\xff\xff\xff\xfa\xff\xff\xff\xff\x1\0\0\0\x3\xfb\0\0\0\x14\0R\0\x65\0\x63\0\x65\0n\0t\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\x96\0\xff\xff\xff\xfb\0\0\0\x16\0h\0i\0s\0t\0o\0r\0y\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\x96\0\xff\xff\xff\xfb\0\0\0\x10\0J\0o\0\x62\0s\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0h\0\xff\xff\xff\xfb\0\0\0"\0\x41\0u\0\x64\0i\0o\0S\0p\0\x65\0\x63\0t\0r\0u\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0$\0V\0i\0\x64\0\x65\0o\0H\0i\0s\0t\0o\0g\0r\0\x61\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0\x1a\0R\0g\0\x62\0P\0\x61\0r\0\x61\0\x64\0\x65\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0\x1e\0R\0g\0\x62\0W\0\x61\0v\0\x65\0\x66\0o\0r\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0\x1e\0V\0i\0\x64\0\x65\0o\0V\0\x65\0\x63\0t\0o\0r\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0"\0V\0i\0\x64\0\x65\0o\0W\0\x61\0v\0\x65\0\x66\0o\0r\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0\x1a\0V\0i\0\x64\0\x65\0o\0Z\0o\0o\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\xfb\0\0\0"\0\x41\0u\0\x64\0i\0o\0W\0\x61\0v\0\x65\0\x66\0o\0r\0m\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0W\0\xff\xff\xff\0\0\0\x3\0\0\0\0\0\0\0\0\xfc\x1\0\0\0\x2\xfb\0\0\0\x16\0M\0\x61\0r\0k\0\x65\0r\0s\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\x44\0\xff\xff\xff\xfc\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\xff\xff\xff\xfa\xff\xff\xff\xff\x1\0\0\0\x2\xfb\0\0\0\x1a\0K\0\x65\0y\0\x66\0r\0\x61\0m\0\x65\0s\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\xc8\0\xff\xff\xff\xfb\0\0\0\x18\0T\0i\0m\0\x65\0l\0i\0n\0\x65\0\x44\0o\0\x63\0k\0\0\0\0\0\xff\xff\xff\xff\0\0\0\xc8\0\xff\xff\xff\0\0\x4\xf6\0\0\x2^\0\0\0\x1\0\0\0\x2\0\0\0\b\0\0\0\b\xfc\0\0\0\x1\0\0\0\x2\0\0\0\x1\0\0\0\x16\0m\0\x61\0i\0n\0T\0o\0o\0l\0\x42\0\x61\0r\x1\0\0\0\0\xff\xff\xff\xff\0\0\0\0\0\0\0\0)”
openPath=B:/Screen_Capture_Videos
recent=B:/Screen_Capture_Videos/2022-11-16_01-10-43.mp4, B:/Screen_Capture_Videos/2022-05-06_00-27-36.mp4, B:/Screen_Capture_Videos/2022-05-06_00-34-09.mp4, D:/Downloads/Colours - 26493.mp4[encode]
parallelProcessing=true
hardware=hevc_amf, hevc_nvenc, hevc_qsv
useHardware=true[player]
gpu=false
muted=false
zoom=@Variant(\0\0\0\x87\0\0\0\0)
jack=false[playlist]
thumbnails=small
viewMode=icons
Here’s what’s in the registry too (the sub categories just have a few simple preference settings in them, not that interesting):
All of the variables listed in the description document seem pretty harmless, as far as telling Shotcut to go nuts or something. Most of them aren’t even set in the INI file at all, and I don’t see any variables that would keep track of running output jobs - something that it does keep track of, but where?
Well, I haven’t really thought of anything else to try… I tried turning off the anti-virus again, after removing Spybot S&D completely - but still the same problem.
The only good news is that I’m getting better at all the weird keystrokes needed to do basic editing with Davinci Resolve (DR), which like OpenShot is able to successfully import and process any input source videos that I have. DR has one unusual rendering setting that tells it not to re-render a clip if it “doesn’t need to” (i.e. the output resolution and frame rate is the same as the input’s I presume) - and that saves a bunch of time to create the output file! I created an edited down 12 minute video in just over 4 minutes, while only using about 15% of the CPU resources, instead of the nearly 1:1 ratio with the video’s length that I can often see. Interesting and useful setting!
Anyway, it seems unlikely that any future version of Shotcut will be able to fix my problem, given that it can’t be duplicated by any of you at all. I know everyone probably thinks my system is weird, broken, or running some odd-ball stuff to make Shotcut behave this way, but everything else I run - even stuff like Cygwin, OBS Studio, more games than I can count, web and ftp servers, VirtualBox, and iSpy universally work perfectly. What ever is going on to make Shotcut fall into a black hole, I still have no clue.
Thanks everyone, for your help and good ideas to diagnose and correct this issue!. I’ll be waiting for a miracle to fix this I guess! -
Hey! Guess what? At first test Shotcut version 22.12 seems to fix my memory leak problem under Windows 11! I see that the update notes for it and last month’s version 22.11 mention some memory leaks, so hopefully that was it!
I ran the small “Colours.mp4” test video file through a re-rendering with a slightly different frame rate with no problems - unlike what I’d been seeing using version 22.10.25 (where it got into a loop consuming memory hand over fist). I’ll try to do some more extensive tests with some bigger files in the next few days and report back if I observe any further issues. I hope not!
Wishing everyone a peaceful and relaxing holiday season!
This topic was automatically closed after 90 days. New replies are no longer allowed.