[ryamoo]

So, more testing and what I've found. 
Date modified/mtime is only used for dateAdded when the file is initially added to the database. 
If I then amend the "mtime" (using Touch) and Refresh that movie, or remove and re-scan into the database, the dateAdded is still the mtime from the original add, regardless of what the mtime or create date is now. 

On V20.4, I've just removed the Movie from my database (right click, manage, remove from library), and the movie file is still in the database's "files" table with the original dateAdded as above. 
I then re-scan the folder after doing a "touch" to amend the modified date, and the movie is added back to my library, and the dateAdded in the files time isn't updated. 

If I repeat that process on V19.5, the dateAdded in the files table is updated to the new modified date. 

Is that a bug, or intended behaviour?

[beeswax]

This thread reminds of an issue waaaaay back, is it related?

6670 (PR)
https://web.archive.org/web/201603122344...cket/15590
210579 (thread)

[ryamoo]

Similar issue and use case, but different cause.
That old thread looks like it was using changed instead of modified.
Currently, nothing is used after a re-scan, just the original date stored in the database.

[Augmatic]

So, more testing and what I've found. 
Date modified/mtime is only used for dateAdded when the file is initially added to the database. 
If I then amend the "mtime" (using Touch) and Refresh that movie, or remove and re-scan into the database, the dateAdded is still the mtime from the original add, regardless of what the mtime or create date is now. 

On V20.4, I've just removed the Movie from my database (right click, manage, remove from library), and the movie file is still in the database's "files" table with the original dateAdded as above. 
I then re-scan the folder after doing a "touch" to amend the modified date, and the movie is added back to my library, and the dateAdded in the files time isn't updated. 

If I repeat that process on V19.5, the dateAdded in the files table is updated to the new modified date. 

Is that a bug, or intended behaviour?

Just came across this issue when replacing some older movies with better quality versions. I would prefer the date added to reflect when that newer version of the file was added. Not the old version. I thought removing the file from the library and then re-scanning would update it, but it's not the case. It seems to retain the original date added, no matter what I do. I've tried playing with <dateadded> in advancedsettings.xml, but to no avail. It seems like the only workaround is to use a different filename for new versions, which I'd rather not do.

Anyone have any more info on this?

[beeswax]

If the filename hasn't changed, the sensible assumption is that it's the same file and it's just been moved, in which case I wouldn't want Kodi to touch the added date or bump this movie to the top of Recently Added.

Best practice for file naming in media collections has always been to use the properties of the file to make up it's name.  At minimum, the Source (Blu-ray, DVD, HDTV etc), resolution and video codec should be in there and if you're upgrading a movie, at least one of these should be different and therefore have a different file name.

So just to be clear, I'm a strong supporter of having options so that stuff works the way any particular person might want and if the scenario described above can be accommodated with an option somewhere - great, but I just wanted point out that there are lots of users who would not want the default behaviour to change regarding this.

[Augmatic]

For sure, I accept that this might be the preferred behaviour for others, and that my problem is essentially the opposite of the OP of this thread. I guess I just wanted to make sure that this is the intended behaviour with v20 onwards, and that there isn't an option to change it. If not, I can live with it.