4K clips on timeline got replaced by proxy files after a crash

OS: Linux Ubuntu 20.04
Shotcut version: 23.12.15, installed from snap, Rev. 1312
Can’t reproduce the issue. Project’s file attached.

I was editing a project while the generation of the proxy files for the clips added to the playlist had been still ongoing. Shotcut crashed, most probably while adapting speed in Proprieties (I’m not sure). After Shotcut restart, when the project was recovered from automatic backup, the clips already added to the timeline were replaced by proxy files (hash-name shown instead of the original file names). I did notice this only when exporting the finished project: the first two sequences were in proxy-like resolution while the original files were in 4k.

proxy_instead_of_clips.mlt (167.0 KB)

OK, weird, I have not been able to reproduce it or see how it can happen after reviewing the code. One can try to reproduce it by:

  1. start Shotcut
  2. turn on Proxy
  3. open a project
  4. make a change
  5. wait one minute
  6. Settings > App Data Directory > Show > autosave
  7. kill the shotcut process (not File > Exit)
  8. locate the most recent autosave file and view its text
  9. look at <property name="resource"> lines and see if they refer to proxy or original
  10. start Shotcut again
  11. open the same project
  12. choose yes on the crash recovery dialog
  13. check timeline clips

There might something else going on in your case that introduced the problem and is not obvious. It should not be that there are proxy jobs still running.

Looking at your .mlt file I see
<property name="resource">0.5:/home/___/.local/share/Meltytech/Shotcut/autosave/proxies/1470417d96e14a6927b475bf5e4b4e75.mp4</property>

Oh, I see that your problem is on a speed-changed clip. In step 4 above, I make my change to Properties > Speed on a clip, but I still do not reproduce it.

I didn’t succeed to reproduce the issue with your instructions, however - after a few hours of testing - I’m quite convinced that the issue was not related to the crash and autosave recovery, but rather generation of proxy files and speed changes in properties. While doing the tests again I’ve recalled that the first time I run into this issue, I had a problem with the playback of the sequences added to the timeline: the screen was black while the play head was on the sequence. That’s where I’ve started trying to resolve the issue by disabling/enabling proxy (F4) and in the Properties > Proxy > Disable Proxy.

I’ve failed to reproduce the exact same behavior (name of resource replaced by the proxy filename) but I’ve succeed to generate a similar issue with the resource name modified by the following steps:

  1. Create a project UHD 25 fps.
  2. Turn on proxy.
  3. Add one clip UHD 50 fps to the playlist and wait until the proxy creation job is done.
  4. Add first fragment of the clip to the timeline, then change its speed to 0,5x in Properties.
  5. Select and add another fragment of the clip to the timeline; at this point on the timeline both fragments shows the filename with (PROXY).
  6. Select the second fragment, open Properties > Proxy > Disable Proxy.

Result: the name of the first sequence on the timeline will disappear, leaving only (0.5x) and the name of the second sequence changes to "timewarp:0.5:/home/path_to_file/filename.mp4. This doesn’t have any negative impact on the video quality, but I hope it will help to trace the original issue. MLT file attached.

test_5.mlt (10.6 KB)

By messing around with proxy and removing/adding the clip to the playlist in different combinations, I’ve succeed also to repeat a few times the effect of the clip added to the timeline being all black or being a grid of gray squares instead of video, but I’m unable to describe the steps to reproduce this (it seems to be random).

Remark (maybe unrelated): any operations on the original video files (not proxy) makes Shotcut to print on the console the series of messages:

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f6b48ce4080] stream 0, timescale not set
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f6b48ce4080] Stream #5: not enough frames to estimate rate; consider increasing probesize