Ever since I have used shortcut (only about a month, have the newest version as well), when changing the speed of a clip, shortcut crashes every 3/6 times. No filters added whatsoever on each clip either.
I can provide video but it’s pretty self-explanatory. Changing clip speed almost guarantees a crash.
I am not experiencing this. Try changing Settings > Display Method to DirectX.
just did that and it crashed second try, but thanks
Provide the exact steps from an empty project.
Also, provide your OS and how you got Shotcut. I assume Windows because Windows users almost always never specify I guess because they think every computer runs Windows.
open shortcut > drag clip into playlist > drag clip into time line > split clip in half using the split at playhead > copy & paste clip > select clip > properties > change speed > crash
sorry, i am using windows 10. i downloaded from the shortcut website and then recently updated to the latest version via shortcut. also: this happened before newest update
OK, thanks for the info. I am still unable to reproduce it. So, I cannot fix it until then, and I will leave this open.
upon further testing, it crashes almost without fail the 8th time the speed is changed. I am also going slower so I go down via the arrow and press enter if thats any more specific
I was able to reproduce a crash by reducing the speed to a very low value. By using the down arrow of the spinner, it goes 0.9, 0.8, …, 0.1, and then 0.000001.
0.0001 works for me without crash, but I doubt that is what people want because a 30 sec clip becomes almost 84 hours. I should probably set the minimum to 0.1. Do you think that is your problem: it goes below .1 and then crashes?
Is that minimum just via the down arrow? Are you still leaving the 6 digits?
I changed the minimum to 0.0025 regardless of how you are changing the the value, but the number of digits remains the same for good precision above the minimum.
Usually 0.5 is what I like to have clips play at for a certain clip to add a slow-mo effect and it has crashed 3 times consecutively when dealing with the same clip. all the other digits of zero’s are present.
I had the same problem.
System: intel i7 4770K (4th gen), nvidia 980 ti, latest drivers (actually a pretty fresh Win10 install, 3 weeks young and clean), Shotcut hardware encoders not activated,16GB RAM, some vids on SSD, some on regular HDD (doesn’t matter to the crash party).
Sources: Mostly AVC 1080p, some with variable, some with fixed framerate - the speed change death is an equal opportunity disappearing act.
Fiddling with clip speed using OpenGL: Adios muchachooos!!
Software (Mesa): “Adios muchachos” encore.
Automatic: Vamanos, mas adios muchachos! 
(I guess it chooses “OpenGL” or “Software”…)
DirectX (ANGLE): WORKS! Yeeeehaw!
Nice to know: Using OpenGL it actually works if converting the clip to “edit-friendly” first.
Nice to see you spent some time trying different options and documenting their effect (some posts just say they have an eror and don’t give any useful info to track it down), also that you got it working eventually.
Talking about trying options, here’s a quick addition to the tip of converting the clip you want to speed-alter to “edit-friendly” if you really want to or have to use OpenGL and crashing Shotcut just isn’t the right hobby for you:
For me it worked with all three conversion options (H.264/AC-3 MP4, DNxHR/ALAC MOV and Ut Video/FLAC MKV). So use the one that best suits you 
happen to me to all the time but now more whit the new update
Found a 480p, variable framterate AVC clip that crashes with everything when changing speed, meaning also when using DirectX and even with a clip converted to edit friendly. Tried 0.5 to 0.9.
Here are the details:
General
Format : MPEG-4
Format profile : Base Media
Codec ID : isom (isom/iso2/avc1/mp41)
File size : 234 MiB
Duration : 26 min 12 s
Overall bit rate mode : Variable
Overall bit rate : 1 249 kb/s
Writing application : Lavf58.20.100
Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3
Format settings : CABAC / 3 Ref Frames
Format settings, CABAC : Yes
Format settings, Reference fra : 3 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 26 min 12 s
Bit rate : 1 165 kb/s
Width : 640 pixels
Height : 480 pixels
Display aspect ratio : 4:3
Frame rate mode : Variable
Frame rate : 29.970 (30000/1001) FPS
Minimum frame rate : 29.940 FPS
Maximum frame rate : 30.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.127
Stream size : 218 MiB (93%)
Color range : Limited
Color primaries : BT.601 NTSC
Transfer characteristics : BT.709
Matrix coefficients : BT.601
Codec configuration box : avcC
Audio
ID : 2
Format : AAC LC
Format/Info : Advanced Audio Codec Low Complexity
Codec ID : mp4a-40-2
Duration : 26 min 11 s
Bit rate mode : Variable
Bit rate : 76.0 kb/s
Maximum bit rate : 128 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 22.05 kHz
Frame rate : 21.533 FPS (1024 SPF)
Compression mode : Lossy
Stream size : 14.2 MiB (6%)
Default : Yes
Alternate group : 1
A lot of people report this problem, but I still do not have a way to reproduce it. You might find that using Convert to Edit-friendly in Properties helps. I have tried multiple OS with multiple clips and while running in a debugger. If someone has a short file that reproduces it, please share.
Note that editing variable frame rate video is not supported (see replay immediately above), and that should be converted. Shotcut tries to detect variable frame rate and shows a dialog offering to convert it. If you ignore the dialog or suppress it forever, then you can easily put yourself into this situation. But, yes, it should not crash.
My shotcut v19.10.20 (on win7) crashes almost every time when editing a large video file with a large amount of short video snippets (dozens) in it. The initial video used had been converted by shotcut to .mov format, as shotcut found that it had a variable bitrate.
The problem occurs in conjunction with setting (lowering) the play speed of a clip snippet when in project mode. Shotcut so far never crashed when doing anything else than lowering the speed. It does not happen immeditately after the speed had been modified in the properties pane. It only happens if you click somewhere in the window after changing the speed, which in turn seems to generate a window update event (or something like that), and then it crashes.
I attached the x64dbg debugger to shotcut.exe and so far I found 3 locations in the code where it crashes. Unfortunately I didn’t find any debug symbols for shotcut (I’m not going to build it myself), but even though I roughly found out where it happens.
It crashed twice with a memory access violation in different places in mlt_service_apply_filters() and once in mlt_properties_get_double(). The latter crash strangely only happens when I start shotcut for the first time after the operating system was freshly booted. It did never happen in subsequent shotcut launches. But in the subsequent launches, shotcut consequently crashes in mlt_service_apply_filters() [source: mlt_service.c]. To my belief it happens when the “base->filters[i]” expression is involved. It looks like “base” sometimes being zero after the speed has been changed. Interestingly it didn’t always crash at the same location within mlt_service_apply_filters(), but it looks like “base” (I guess “r15” in assembly is that pointer) is always involved there. Thus it could be a concurrency problem between threads, some variables not being thread safe etc.).
The first error in mlt_properties_get_double() seems to happen when that function is called with the “_speed” param. Here the problem looks more like an array overflow as the pointer to the array seems to be well defined. I did not have time to find out what array it is, but to my belief the error happens within one of the inlined functions in mlt_properties_get_double().
I provide you with crash information details (hope it is all you need).
There is no crash1.txt. Crash1 is the first crash location in mlt_service_apply_filters()
where the debugger stopped yesterday. Today it only stopped at Crash2 position,
but I still marked both RIP positions in the assembly excerpt.
crash2.txt (39.6 KB) crash3.txt (57.6 KB)
Dave
Thanks for trying to help. If you download the Shotcut SDK for Windows, it includes a debug build with symbols. Just locate the shotcut.exe and run it. Also, it integrates a crash logger so that when it crashes outside of a debugger, it dumps a stack trace to text file named shotcut.RPT in the same directory as shotcut.exe. You do not need to download our build of Qt and setup Qt Creator as described on that page to use it for simple debugging.
Tonight, I was able to reproduce this in a source-level debugger on Linux. It crashed in the same place as crash2 for @DaveS. I think I fixed this in MLT for the next version 19.12 of Shotcut (at least for our builds using MLT git master). I was unable to reproduce it again in the debugger after trying about 50 times.