I’m assuming this is a bug because it’s only started happening with 18.05.08 and it is intermittent, but can happen several times a day Until I found out what it was it was quite frustrating but it’s easy to fix when it happens. First time was on the day I installed 18.05.08. I have done a reinstall with the registry settings overwritten for a separate reason but it still occurs.
Every now and again whilst running SC the program will become extremely slow and unresponsive and audio playback is silent. Restarting the software doesn’t fix it and at that point it becomes clear that it’s not just SC, it’s the whole PC that is running slow. It happens (or at least I usually notice) when I start a timeline playback - I can’t stop the playback or save the mlt file so I have to hope that the autosave has preserved all my changes.
On checking the task manager I find that even though I have shut SC down, there is a process running in the background called “Shotcut” that is consuming anywhere from 80-99% of the CPU resources (the cooler fans are spinning like crazy as you can imagine) and using a GB or more of memory on it’s own. Shutting down this process allows everything to run as normal, however on any given day it happens again, several times at seemingly random intervals.
I’ll happily provide any info required, just let me know what is of use. If it is a conflict with any other software that is already known about I can hopefully fix it by uninstalling that.
FWIW I’m running Windows 10 Pro 64bit on an AMD FX8350 based system with 16.0GB RAM
Which version of Shotcut are you running? Please state exact version as there has been multiple releases this month.
Have you tried restarting the computer?
Which Operating System? If it’s Windows 10, I just had an update last night, so Windows might be downloading the update.
This still happens to me quite regularly. The way to MAKE it happen is to run 2 or more instances of SC simultaneously then shut down all but one. About 50-60% of times I’ve done that I end up with the background process burning up the CPU.
It also sometimes happens randomly, but just shutting down the unwanted process is all that’s needed. Don’t even need to shut SC itself down, just that unwanted process. It’s annoying but it’s nowhere near a deal-breaker.
Still running on the same PC setup as above and I DL updates as soon as I know they’re out - I always click the “new version” prompt on first start up.
Only exception was last month when I had to go back to 18.06 cos of the sound bug but all 3 versions of 18.08 have done it on me (even the one that came out yesterday).
Hi Hudson. I first tried restarting my computer, but that didn’t work. I asked my husband for help and he concluded it was probably because my ShotCut was out-dated relative to Windows updates, so he reinstalled it for me. It seems to be working thus far. Thanks.
When you do this the database (sqlite) becomes locked by whichever process starts using it first. The database is currently only used to store thumbnails and waveforms (it is a size-limited cache, does not grow indefinitely). Then, whenever the process without db access needs to show thumbnails and waveforms, it must rebuild them in a background thread. This is all that I have come up with so far to understand what it causing this slow behavior. Unfortunately, I do not see a way to open the database in read-only mode as a fallback. The best remedy to this is to run a full on client/server database ala mysql, but that will make Shotcut much more complicated for all: users, developers, support.
Running 2 instances is something that only happens occasionally by accident and although the lock up still happens now and again for reasons I can’t fathom, it’s no longer causing me the aggro it once was. Now I’ve got used to it, the moment SC starts lagging I hit CTRL-ALT-DEL and shut down the background process - Bob’s yer uncle- all is well again
If it’s a big deal to fix it, it’s no longer a big deal for me to live with it - though obviously I can only speak for myself.
This should be fixed or significantly improved in v18.09.
If there is another, intentional shotcut process; then one of them may periodically stop showing audio waveforms. Only one process can write to the database at a time, and computing audio levels is often heavy. Thus, it should not compute the audio levels if it will be unable to cache it in the database. On top of this, I found a big bug that was causing it to not reliably shut down its process completely. To make matters worse, upon failing to shut down, it was recomputing audio levels for everything in the timeline and loading the system! Furthermore, it would use up to all CPU threads to do that activity! Now (v18.09), all background activity like thumbnails and audio levels for waveforms are limited to at most 4 threads.
