After updating my Linux machine to 16 Gb and treating it to an Nvidia GTX-1050 TI, I expected Shotcut to work much faster. Instead it’s become glacially slow. When I booted up, Shotcut seemed to be doing well, but any launch is immediately so slow it takes a minute or two for the blue update banner to show up.
This a system that isn’t working hard.
The real stunner is there are four processes named shotcut. They seem to be doing a lot of disk activity. Even though Shotcut isn’t running or at least it’s not on the desktop and Activities doesn’t list it as running.
My guess is these processes are pulling Shotcut to its knees. But I have no idea why they even exist with no app visible on the desktop.
All of this is under Ubuntu Linux 17.10.
Not too surprisingly, killing the four instances of shotcut, and launching Shotcut again, brought Shotcut back to reasonable performance. And exiting Shotcut left the two processes, presumably associated with the launch, still in the list of processes.
Opening Shotcut 17.10.02 (no project) in Linux Mint 17.3 shows 2 processes named Shotcut and when I exit they go away. Those on this forum running ubuntu have had problems even getting Shotcut to run. I used the Linux portable zip (tar.bz2) and created what Mint calls a “Launcher” shortcut for my Desktop. -=Ken=-
The snap version of the Shotcut distro is well named: “Oh snap!!”. I use the portable version, too, although I was able to coerce the latest snap version to run. I haven’t put in a shortcut for launching, but that’s mostly out of laziness (lets see, opening Nautilus, drilling down two folders to click on the distro click-here… yep, building a shortcut seems like a time-saver).
Anyway, I don’t understand why the processes don’t die when the program ends. The other thing that puzzles me about them is the one process that’s doing all sorts of disk writes after the program (allegedly) ends.
After doing housekeeping on excess processes, Shotcut’s running well although I still get occasional stutters and delays, which clear up after a minute or two. The system monitor doesn’t show anything else eating up cycles - for no obvious reason, Shotcut just slows down.
For me the Mint 17 releases don’t support the Snap daemon while Mint 18 releases do support Snapd.
Shotcut supports multiple instances and if you set one instance off to Export a project you can open another instance and start a new one at the same time. So, I tried opening a second instance of Shotcut and got the four Processes display like yours. But closing each Shotcut instance saw the proper removal of each pair of processes.
Incidently, I am often fascinated by the “plumbing” of these machines and noticed that leaving my desktop PC running “idle” for a while results in higher than normal CPU spikes which I think are being caused by the Google Chrome Internet browser. Closing and reopening Chrome restores proper operation - but I’m going “Hmmmmmm, I wonder why?”
Based on past experience, I generally ignore snap. I’m sure it has its value, but I’ve never seen the value, and I have seen it fail with Shotcut. Too regularly. Thank goodness for the portable release.
It didn’t dawn on me that I can run multiple iterations of Shotcut
It’s very puzzling that the processes don’t end. They’re not zombie processes (mercifully, haven’t seen any in a very long time). That is, they respond to end and kill. Hmmmm… I suppose I could launch Shotcut with a script that does killall at the start of a session…
AFAIK, nothing else I run hangs around after it’s been ended.
I haven’t tried Chrome under Linux. I’ll keep an eye out for something else that decides to use CPU cycles for no obvious reason.
You are probably seeing multiple processes for threads. If you added a clip to the timeline, then a thread is generating waveforms, which can take a while on long source clips.
At the moment the project has 14 additional audio clips (music, typically about 3 minutes long). Is there anything which sppeds up generating the waveforms, or at least doesn’t slow down the process?