[BUILD] Cannot retrieve download links for versions prior than the latest one

[gnolooo]

Download links are not available for versions prior than the latest one (d09c494 and before). It just gives the message:
Failed to retrieve download link. Please try again later.

[Simran-B]

The download links are only valid for 90 days after the build. The retention period cannot be extended unfortunately. Self-hosting the build artifacts would be possible but users complained about slow download speed in the past.

[gnolooo]

I mean, I get it but at least with slow speed I could still download previous, working versions... Now that even nightly releases come once every 3 months, how can the previous download links last for just 90 days?
Is there any other way I could get d09c494 or 55eedbf? Thanks

[Simran-B]

90 days is the maximum that GitHub Actions provides for any build artifacts.

Why do you want these specific builds in particular? There haven't been any code changes on the main branch in a year, except for a small fix for the chromakey shader. The binaries should be the same.

[gnolooo]

I've opened some other issues with specific problems regarding either Arch Linux and Wayland or Windows.
I need the previous builds because they used to work fine on Windows, without taking too long to export (#2321), and they used to even build / launch on Arch Linux with Wayland, while now they're broken (#2319 and #2320).

[Simran-B]

The versions you ask for can't be any different as basically nothing changed on Olive's side. The prebuilt Windows and macOS dependencies used in the CI have also not been touched since May 2, 2023. The Linux build image is two years old. What changed are GitHub's build machines, although Linux should be unaffected because the compilation happens in a build container. I don't really see how, for instance, a different Windows runner could suddenly cause Olive's exports to fail, however. If it worked in an older version then that must have been in a significantly older version from before a related code change. Or the settings are simply different, like a higher resolution than before that cause out-of-memory crashes perhaps? Or the footage is different and somehow problematic...

[Simran-B]

Here is a rebuild of 55eedbf with 10ce5fb on top:
https://github.com/olive-editor/olive/actions/runs/8968310669 (artifacts at the very bottom; you need to be logged in to GitHub)

The build conditions are obviously different because GitHub changed their runners. There is no way to reproduce the exact builds or get the original build artifacts back.

[gnolooo]

Thanks for sharing it.

I don't really see how, for instance, a different Windows runner could suddenly cause Olive's exports to fail, however. If it worked in an older version then that must have been in a significantly older version from before a related code change. Or the settings are simply different, like a higher resolution than before that cause out-of-memory crashes perhaps? Or the footage is different and somehow problematic...

About this, how could I troubleshoot it? My only 2 takes were: testing the same version on a different platform (e.g. Linux, but there I've the aforementioned problem with building and using Wayland), or using an older version on the same platform (not possible because I couldn't retrieve old download links).
The thing is, it's possible that the footage is problematic, but how would I know it, and what could be causing the problem? I exported a dozen clips from a ~100 min movie (Cars) without any problem for weeks; then I updated Olive and tried to export a single clip from its sequel (Cars 3, so similar duration, resolution etc) and I had the aforementioned export problems.

[Simran-B]

It's difficult to find the cause. You can try ffprobe and ffplay, preferably the version used in the AppImages (5.0), and check if any issues are reported for the media file. However, I remember Olive having trouble with a particular video file from a smartphone once whereas ffmpeg and video players had no issues at all to process/play it. Re-encoding the file with ffmpeg fixed it for me.

Does it already fail with a single short clip of the potentially problematic footage? If yes, then I think it's a general problem with that file. If it only starts causing issues in Olive if you have many clips, maybe watch the memory consumption and see if it eventually fails because it runs out of memory. There might be some mishandling of the file/ffmpeg, or a memory leak, or there might be an issue with the file that only manifests when seeking a lot (because of many clips) - sometimes there can be trouble determining the duration and might throw things off, and it's possible that handling these cases isn't implemented correctly in Olive's code (which I would say is likely if ffmpeg on its own has no trouble playing/transcoding the same file).

[gnolooo]

I've done a bit of testing and I've exluded the footage as possible cause. I tried to cut other clips from another movie, and few other videos, and the export didn't work in either case. At this point, I think the problem is either in this particular version, or in Windows itself. If the same version worked on Linux, I would test it there; but since I can't manage to build and/or launch it, I just can't.

P.S. Do you think it would be more appropriate to continue the discussion in the proper thread (#2321)? Since this one is just about retrieving download links, and it's pretty much solved (I mean, there's nothing we can do to extend the 90 day limit).