Yes, that turned out to be the problem. I made a much faster query in the database that only fetches the LastModified value. But the logic then checked BOTH LastModified and LastSize causing it to think the size changed (current size vs missing size) and then submitted the file for full scanning.
Also, since the metadata was not previously fetched, it would think the metadata was changed as well and instruct Duplicati to re-store the metadata, causing the warning message about unchanged metadata.
Additionally, there was a wrong flag check that caused the OP warning to be triggered on most (all?) files.
For this error, at least the “… but still requires being added?” part should go away.
Not sure how to deal with the “invalid” time. Problem is we cannot read it into .Net, so we are stuck with a missing “current” time. This repeatedly causes Duplicati to thing the metadata has changed, and then it tries to generate new metatdata, only to find that it can’t. Next run we have not stored a valid timestamp, so it repeats.
With the changes from @mnaiman, we can at least see the problematic path. Is it acceptable to require users to fix the timestamps?