Gopro proxy file issue with changing trimmed subclip speed

What is your operating system?
Windows 10

What is your Shotcut version (see Help > About Shotcut)? Is it 32-bit?
21.10.17, 21.09.20

Can you repeat the problem? If so, what are the steps?
(Please be specific and use the names as seen in Shotcut, preferably English. Include a screenshot or screen recording if you can. Also, you can attach logs from either View > Application Log or right-click a job and choose View Log.)

If I change the speed of a subclip that has a proxy .lrv, then close and reopen the project, the subclip will revert to 1x speed even though in timeline it still says 3x.
This happens 100% of the time if I use GoPro clip with the in camera proxy (.lrv file) and proxy enabled. It seems the presence of the (properly named) .lrv file is enough to trigger this.


  1. start a new project, Settings → Use proxy already enabled
  2. add a (gopro named, I don’t know if this happens with other proxy types) video file that already contains the proxy to timeline (in my case I have GH015004.MP4 and GL015004.LRV in the same folder). Just make sure Shotcut doesn’t create proxy for this in the jobs panel, it must use the one already present. [note for reproducing: it doesn’t matter if this is the original .lrv from gopro, or the proxy shotcut makes but moved and renamed, or even the original full size .mp4 copyed and renamed to this]
  3. make a split after 5 seconds, select the second subclip and change the speed to 3x (the numbers or the split location don’t matter at all but it makes it easier to see)
  4. save and close project
  5. reopen project and hit play
    Result: the second subclip is not at 3x anymore (even though it says so in the timeline UI), but 1x and also keeps the previously calculated trim time (ie: starts at 5/3=1.66 seconds instead of 5s where the cut was if it were to ignore the 5x). This is also seen in final exported video or in playback.

A few notes:
-[i just noticed this:] even if shotcut already has internal proxy file created, if I close the project and put a [properly named] .lrv file in the original file’s folder, after opening the project again I can see the bug. Closing the project and deleting the .lrv file will then make the bug go away. --no changes are happening in the .mlt file between these states but the original file must be named gopro-style: GH#####.MP4 (it doesn’t need to be created by a gopro camera)

-same issue happens if I don’t start with Use proxy checked and do the cut+speed increase on the original clip, but then hit Use proxy and close + reopen project → this is how I first hit the bug but just assumed I did something weird
-if shotcut creates the proxy internally instead of step 2 (when adding the file or enabling Use proxy) it means the .lrv file is not “found” so the bug doesn’t happen anymore
-after the issue is hit it doesn’t matter if I disable/enable proxy again, that subclip will remain “bugged” (as long as the .lrv file is there)
-if I select the bugged subclip and do ctrl+c to see it in the source view there is a wrongly sized (original size/3) clip there at 1x speed that can’t be recovered to full length

Btw this sounds like some weird use case but it is very likely to be seen randomly if editing gopro files (the camera automatically creates them so it’s very easy to just use them with literally no wait time instead of editing 4K footage directly)

Thanks for finding and reporting it. I just fixed it for the next version 21.10

1 Like

That was fast, thank you!

Also relating to gopro proxy, the change made here to fix gopro’s bad .lrv aspect ratio is being kept even after disabling proxy usage and after exporting thus the output has a few black pixels of padding at top and bottom.

I see the .mlt has this line for all videos that had gopro proxy, luckily it’s easy to find+replace it away.

<property name="force_aspect_ratio">1.00629</property>

Ugh, that’s a big problem. I see no easy way to fix this other than to revert the change and live with the less minor problem of slightly inaccurate and ugly proxy.

I agree, pixel peeping into the proxyed output is less important than the final export.