[Bug] `upload_date_index` is unnecessarily recomputed in the migration from `upload_date` to `uploaded_at`

[Iliannnn]

Describe the bug When a force redownload of a video is performed and the new video has a different resolution, the old version of the video is not removed. This results in both versions occupying storage space unnecessarily.

To Reproduce Steps to reproduce the behavior:

1. Go to a source with lower resolution videos than the 'Preferred Resolution' was set to.
2. Actions > Redownload Existing
3. Check the storage and observe that the old video version has not been deleted.

Expected behavior When a force redownload of a video is performed with a different resolution, the old version of the video should be automatically removed to prevent duplicate storage usage.

Screenshots

Luckily, it does switch the path of the new file in the database. It just doesn't remove the old version:

Diagnostic info

- App Version: 2024.5.30
- yt-dlp Version: 2024.05.27
- Apprise Version: v1.8.0
- System Architecture: x86_64-pc-linux-gnu
- Timezone: Europe/Brussels

Additional context

Not sure if it's expected. It's not a super big deal, but I wasn't sure if this function was meant to be this way. I was assuming it would replace the old version because of the "REDOWNLOAD Existing" feature name.

[kieraneglin]

Ah, good catch! I think I know what the issue is, but could you please tell me the inserted_at datetime for this media item?

[Iliannnn]

inserted_at: 2024-05-29T14:56:53Z

[kieraneglin]

Ah yeah, in that case it's an unexpected consequence of #269.

It's not to do with changing resolution per se, but instead because when the upload date gets set it fires some code to compute the upload date index (the 99/98 at the end of the sXXXXeXXXXXX string). This should normally only run once but #269 means re-downloading will update the upload date, fire this code again, and result in mismatched filepaths (ie: doesn't overwrite)

Easy fix, will look at it later today or tomorrow

[kieraneglin]

Changes made in #284 and that'll go out with the next release!

I've also merged these changes back in with the YouTube API PR so it'll be available with the api-fast-indexing tag shortly