Can anyone tell me why my disk is at 100% when using shotcut? I think it is a bug with the new shotcut. Also changes throughout my usage of shotcut (what I am doing in shotcut). Another thing shotcut is now really slow with this new update. One last thing is that shotcut keeps on locking up.
Obviously, your computer does not have enough free disk space, and I suspect Shotcut is really slow because your disk is full. I do not think this is a Shotcut problem. Read the FAQ to learn about where Shotcut stores some data like thumbnails in a database file if you want to remove it to free up some space, but I doubt it will do much help. Shotcut does not save a lot of temporary data. If you are exporting a lot of video files and not paying attention to their sizes or what you are doing, then of course your disk will fill up - video files are big.
277 gb of free space on my C: drive.
Is that enough?
Yes, so I do not understand the problem. What says the disk is at 100% when running? Please make a screenshot that shows Shotcut running, the 100%, and the 277 GB free space at the same time.
That is when I launch shotcut. So i do not want to close and reopen shotcut. (to take the screenshot) (because I have a project)
Also what about the constant locking up?
I misunderstood what you meant. When you add a clip to the Timeline, Shotcut creates an audio waveform in the background. This will use your disk a lot and slow things down. If you don’t like that, then wait for it to finish. As for the constant locking up, I do not know. I do not have that problem.
This continues to be an issue. I recently switch back to Linux. Prior, in windows, after an update, I noticed seeking, adding files, undo, as well as other functions, slowed, and resulted in A LOT of hard drive access, especially when the file was large, and the recording was long, and would completely lock the computer for many seconds to minutes on end. I blamed my PC as it is old.
After switching to Linux, the distro presented shotcut version 22.01.30, which works VERY well, with VERY… please note the capital case, I would make it 20x larger, as the issue is just VERY… VERY reasonable HDD seeks. Editing a long and large file was easy with few slowdowns or lockup. This version lacks many of the new filters, so I upgraded to 23.09.29, and began wishing for death. Workflow ground to a halt… undos began taking minutes, rebuilding waveforms lagged the process, and seeking became painful… my PC becomes unusable. It was exactly as it had been in windows, centuries ago, last week. I reverted to 22.01.30, opened the exact same project, and started working again… at a reasonable pace, my will to live restored, music and youtube playing in the background.
I cannot convey to you the difference between 22.01.30 and 23.09.29 that would do the slowdowns justice… It was like the difference between driving an hour to get someplace, or spending four hours walking there. No changes to hardware or drivers occurred, no other changes to the operating system, no other programs were added or removed… it was even the same melt file, although the new filters were removed upon reload. Using 23.09.29 in either Windows or Linux, is like editing with a shot gun to my head.
Is the hard drive SSD or magnetic?
How much RAM does the computer have? Wondering if the disk access is swap file activity.
It’s an HDD, but the same happen if I move the files to my SSD, although the slowdowns are not as long, they are as severe. Memory is not a whole lot, 32 gigs, but mem usage does not spike during these operations, and I usually have a fair amount free. As for swap access, I checked in both Linux and Windows what files were being touched, and the swap files were largely unmolested.
Try the following in version 23.09:
- Open a project
- Choose File > Backup and Save
- Restart Shotcut
- Reopen the project (not the backup one with the last modified date & time in its name)
Any better?
Responding to shotcut. No, behavior persists.
Expanding on answer to Austin. I rechecked, and you are indeed correct, the swap file is being accessed, but physical memory is never really filled. Version 22.01.30 continues to have no problems, and barely uses the swap file… 23.09.29 exhibits random behaviors. Please note, this is all in Linux, I’ll die to a bee sting in the eye before dual booting into windows any time soon, but I assume, as there are similar symptoms, similar things are occurring.
I upgraded back to 23.09.29, and coincidentally, on first load, after loading the file and playing for a few seconds, swap activity maxed out, maxing the transfer rate on the SSD, which holds the swap. Very little CPU usage, and not a lot of physical memory used, not going over 40%. Swap size also maxed. After 45 minutes or so of non-stop activity, Linux killed the process. On reload, shotcut behaved itself, loaded properly, but still used more VSZ, but not more than 60%, and more RSS. I was able to make random edits and undo them for about 10 or so times, then the swap ran away again, but after 10 minutes, Linux killed the process. During edits, the process stalls for several seconds, sometimes up to 15 or 20 seconds, but CPU and HD activity remain low, I have no idea what it’s doing. 22.01.30 undos in less than 5 seconds, even with a very large file.
On the next reload, I developed a way to consistently lock the process and computer each and every time. I make a series of edits, removing segments of a video, creating transitions, sometimes I do these randomly, sometimes I make the exact same edit on the exact same frame… I did this to determine consistence, there was none. I then undo my edits one after another. At between 5 and 20 undos, the swap file size maxes out, R/W to the SSD maxes, then soon after physical memory maxes and freezes the computer. On try number 1, I left the PC for 45 or a hour or something, and the kernel eventually killed shotcut. From try 4 onward, I restart after a few minutes. I can lock and freeze my computer in up to 10 minutes consistently with shotcut without fail, and ran the testing for 3 hours. I probably didn’t damage anything… It’s fine… I’m not worried…
EDIT: I should also specify, that with 22.01.30, apple of my eye, song in my heart, I edited for quite a long time, developing a very mature undo history, and was able to restore to previous points without issue, or even waiting very long. At one point, I believe I had over a thousand entries in history. I have not been able to do that with shotcut on the new versions in windows… but I also only started working with larger files in like December/January, and really have no idea which versions I used. I updated regularly however.
EDIT2: I vastly increased swapfile size, but greatly lowered swappiness. This increased the speed at which undos completed, and prevented shotcut from locking the whole system… but now, I can only do 1 to 3 undos before Linux kills the process. 22.01.30, angle, darling, sweet pea… I couldn’t get to crash. I kept executing undos, it kept doing them, mem usage creeping up, taking minutes, than, when it maxed out… it graciously terminated the action… and told me it was out of memory… I wept!
Sounds like a lot of pain and suffering for not much reward! Hopefully you have some masochistic tendencies to make this all worthwhile 
What was your initial swap value before you went really low? Instead of something like 1, you could try 10 or 20.
Have you also tried adjusting the cache pressure? Something like:
vm.vfs_cache_pressure=50
Default is 100 but you can adjust this value and try 50 and 200 for testing, although I doubt it will help much.
Have you tried Xkill (assuming X server of course)? That has never failed me and I use it – mapped to a keyboard shortcut – sometimes to kill Shotcut after a hang, instead of having to execute a forced shutdown. I know it doesn’t solve your problem but it might help avoid some unwanted PC trauma.
OMG! I am a masochist! Thanks for noticing. Whenever I feel I’m getting too comfortable with the world, I call up my mom, just to remind myself how miserable life really is. Or, I call up an ex, and try SUPER HARD to have a civilized conversation with them… ah, like squirting mustard in your eye… Sometimes, when I’m in a really good mood, I take a spoon, and… No, no, this is a tech forum, no one wants to know where I put the spoon and why I need a cordless drill for it.
The swap started off default, 60 swappiness… which is a swingers term I think… and a paltry 2 gigs. I then changed it to the lowest setting, 1, for testing purposes, but increased the files size to 64 or something, I can’t remember. The narrative above describes that journey of fun and adventure… I’m like Fin the Human! Cept so old, I’d be placed on a list for existing in that world, so, I guess I’m more like Ice King. I then changed swappiness to like 20 or 30 or 40 or something… something reasonable, but still lower… whatever Bing suggested, because google sucks now, and sucks so much, that a pain seeker such as myself, avoids it! There’s a reason they removed do no evil from their motto. Since then, I’ve been using version 22.01.30 very effectively. I hate video editing, and this is the only interface I can stand without breaking out the TENS machine to teach my face a lesson about accepting adversity. Punching yourself repeatedly through the power of electricity, what a world we live in! It has some bugs, but I’m not bothering reporting them, because I figure there’ll never be a 22.01.31, and I die of brain cancer before I use 23.09.29 as my primary editor. My guess, is that 23.09.29 is not handling garbage destruction properly. Both versions seem to not be handling multi-threading very well, I’m not sure they’re even capable of it, or if it’s just my settings, but 22.01.31 is working well enough, and I barely care. I’d much rather be felt up by an Iron Spider. That’s not a Spider-Man reference.
At least you have a sense of humour, and when it is made glaringly obvious, some things are hard not to notice.
Bee stings and squirting mustard. You have a thing for eye pain huh?
Bing, what blasphemy! You do know when you go and deliberately misbehave, the punishment received is never the one you are looking forward to, right? DuckDuckGo! Use it and thank me later.
OK so you did progressively up the swap. Change/add cache pressure to 50 and leave swap at around 20 or 30. Then go back a few Shotcut versions. Try something like the v23.05.14 AppImage. That way you can have multiple versions without repeatedly uninstalling/reinstalling while testing. Based on what you’ve previously written you don’t seem to need instructions on how to do that but if I’m wrong just ask.
And when using a new or different version, make sure to test with a new project and not an existing mlt file. Good luck!
Much like banana peels, eyeballs are stand-ins for other body parts that can get people banned if you make jokes about mutilating them… for some reason, eyeballs are okay… Banana peels were stand-ins for horse… droppings…
I regret to inform you, that I didn’t really take your advice and download the one link you provided… I downloaded every version from 22.01.30, and briefly tested them all. I’ll also sometimes keep wounds open for extended periods of time! I also wasn’t re-installing versions, I have the two major ones I was using side-by-side. I also disagree with needing new mlt files, they’re XMLs and do little else but tell Shotcut to run a bunch of orders on load, and it seems like Shotcut runs some kind of clean up when deleting a segment. The only entry which differs significantly in the files, is the hashes, which are easily removed to leave version changes to re-hash. And I’d set my swappiness to 45 if anyone is following that pot-line with baited breath.
An obvious and profound change to how Shotcut handles files and memory occurred between 22.06.23 and 22.09.23, which, I figured out is the date of release, and the first number has NOTHING to do with major updates! I also suspect some changes were made to CPU and GPU usage… new version don’t seem to use my older CPU as efficiently.
End of chapter 5.
Then it sounds like you’ve done everything possible regarding testing the different versions and I guess you are screwed for the time being! Luckily, there are always new versions to look forward to.
I am not surprised to read that.
You are free to disagree and ignore, since what you say makes sense … but … just because an mlt file is written in xml, that doesn’t mean there aren’t occasionally compatibility issues with new versions; if you’ve been observing this forum for a while you might have noticed that users very occasionally have issues with an old project after a major upgrade. It is rare, but it happens. That’s why a new project is the recommended way to find out if the installed version is behaving correctly from a troubleshooting perspective, and also why it is advisable to finish a project in the same version that it was created. 
Obviously I can’t make you follow that course of action, and chances are it won’t make a difference, but are you telling me you haven’t bothered starting from a blank slate during your extensive diagnostics?
No, I’ve tested with blank projects as well, and old projects, and by adding the exact same files, making the exact same cuts, adding transitions of the exact same length, copy pasted from one version to another, copy paste into text files then re-adding them that way… I’ve controlled as many variables I could think of. I’ve also saved and looked at all the mlt files… ran perf while trying different versions… watched files access, CPU and thread usage… probably going to do more later when I’m bored… probably going to end up looking at the source at some point too.
On a side note, there seems to be a lot of cache misses while working with temporary files.
And different resolution files… Multi tracked audio verses sound files… Cutting up videos into smaller section… Editing with scratch files then replacing them in the mlt files before rendering… so on a so forth
1 Like
Yes I figured, and I had assumed the conclusion already.
Good luck with the source, and I hope you have lots of mustard handy!
Remind me again, how many chapters in the Story of O?
As many as it takes man, as many as it takes…
Also, I think this might be something with Qt… Which would make sense, as I experience the problem in both Windows and Linux.
EDIT: I also did an oppsie doopsie and loaded Shotcut without permission for the sound sink… and had an interesting result… It greatly sped up file handling, At first, I thought maybe this meant something was up with SDL, but undos were still obnoxiously slow, so I think it’s still something to do with how Qt handles large/long files.
EDIT2: I think it might be a change to Qt 5.15
EDIT3: Problem with large files also exist in Qt 6, but to a lesser extent. Qt 6 however, is just as temperamental regarding undoing anything repeatedly or rapidly. There might also be something wrong with the Flatpack distro? I donno, it seems more unstable than the AppImage version.