Replacing files does not update resolution

This looks like a nice way to fix the initial issue, Thanks.

I have another issue with Infuse on the same screen, but with internal logic (or I am doing something wrong).

I have video files that do not have any description (metadata), and they are in H.264 format. When I open a folder with such files, all is fine. Then I compress that files to x265 format and add a description (metadata) but leave the file name exactly the same. When I do that, most of the times, Infuse will not update file information (no description and in Modern view it says at the bottom H.264instead of HEVC)

For new files, proper data is found. For converted ones, it is random. Can be all data, can be half, can be none.

How can I force rescan/refresh?

This is expected, as Infuse will cache info about your files and not check them again (this process is rather slow).

To resolve this, you can simply give the files a different name when replacing them. Or, if keeping the same name use the Edit option in Infuse and reselect the correct title to update details.

That is expected, but some big refresh button with warning and progress bar in settings to refresh everything would really help in this case.

Not sure I agree this should be the expected behavior. I have many movies that get automatically updated to higher resolution where available. Infuse sees the file has been updated (since it appears in Recently Added) but the metadata is not updated. This is problematic, since when I browse for movies by resolution (eg for 4K), Infuse does not behave correctly. This is a bug and should be addressed.

(Furthermore, this doesn’t appear to be slow and anyway I don’t care how slow it is, what I care about is having the correct metadata)

1 Like

This poor behaviour might be “expected” by the devs but it’s certainly not expected by the users.

As @dave1447 says, we care about correct metadata.

Exactly. No user would expect a file to have incorrect metadata. They also would not expect filter by resolution to return incomplete/incorrect results. Nor would they want these things. It’s simply nonsensical to suggest otherwise. This is a bug. Expected behavior: when a file is detected as recently added, refresh the metadata.

This is exactly the same issue I have and why I opened this ticket not too long ago;

Seriously, how hard is it to run a refresh on something that has a changed timestamp?
You’ve already flagged it as updated as the file now appears in the recently added list again, but you don’t automatically refresh the metadata?