I’ve noticed that the load times for MLT files/Projects in the latest version of shotcut ( win64-250125 ) is obscenely high and randomly crashes or hangs ( Becomes Unresponsive ) while loading projects. If I let it sit sometimes it will load the project after 10 minutes and sometimes it does not, so there is an element of random total failure ( 20% chance to just totally crash while loading ) or randomly taking a very long time.
I was originally using the exe installation file [shotcut-win64-250125.exe] and tried downloading the portable version of 250125 and it has the same misbehavior.
The misbehavior does NOT exist for my system with version 241117 ( using portable version as well ). In fact, 241117 is even able to open projects made with 250125 roughly 10 times faster than 250125 can, does not become unresponsive, and does not randomly crash when doing so.
What is your operating system? Windows 10 What is your Shotcut version win64-250125 Can you repeat the problem? If so, what are the steps? Try loading an MLT file with 10~20 number of items in the timeline using win64-250125, compare load times to win64-241117, observe that they are 15-50x longer and sometimes the program hangs/becomes unresponsive while loading projects which does not happen in win64-241117.
Hi @Rando
I’ve noted that projects created with version 25.xx open very fast.
But it seems that most of the projects created with previous versions will take a long time to load.
Do you experience these crashes and long loading time in projects created in v25.xx as well?
It seems to be having the playlist in icons mode turns out what causes the problem for me. Things in 250125 load about as well as 241117 when set to either “details” or if the playlist is closed out before loading a project. I had it originally set to thumbnails.
-Still randomly crashes on load though, but when it does not randomcrash it at least loads quickly.
OK, I just pushed what I believe is a fix for the next version 25.03. It will build tonight. It would be great if you can download it tomorrow from our GitHub and try it out. If you do not have a GitHub account and do not want to make one, I can paste a download URL here.
I did some testing of last night’s build, and this problem is not yet solved. Sometimes, it is back to its normal self and loads quickly, but more often not. But the workaround still works for me. I will keep trying.