In my case, the workaround was relatively simple: I added a lot (350+) of covers all at once, in a short timeframe, so I could rewrite the update_at fields on those relatively easily with this query:

UPDATE album SET updated_at = created_at WHERE updated_at > '2023-03-06' AND updated_at < '2023-03-10' AND created_at < '2023-03-01';

But of course, if I fix an old cover again, that poor old album is going to come back up the list and try to play with the young kids and everyone is going to look at him sideways and think "ok boomer" and release a barely hidden sigh that will just make everyone really uncomfortable...

You have set ND_RECENTLYADDEDBYMODTIME to true which is not what you want from what your description reads.

https://www.navidrome.org/docs/usage/configuration-options/#advanced-configuration

The functionality you describe is implemented with #2553 as long as you dont Set ND_RECENTLYADDEDBYMODTIME (default is False)

Hmm... well that setting doesn't do what I thought it did though: I thought that would set the created_at field on import, but from what you seem to be saying here, it influences how the albums are displayed?

the created_at fields are correctly set here, just to be really clear.

but from what you seem to be saying here, it influences how the albums are displayed?

That's correct. It is used for controlling how to display the Recent Added Albums view.

That's correct. It is used for controlling how to display the Recent Added Albums view.

okay, so couldn't this be made in reverse, like at import time, if that setting is on, use the file mtime as the created_at field instead of updated_at? for me this thing is completely setup backwards, but maybe that's just me. :)

I think the fields should be used for what they mean: created_at for when the file was created/first imported (see #1350), and updated_at for when was the last time the record was changed in the DB. Inverting these two can cause confusion when maintaining the codebase, and it is just a matter of displaying sorted by one or the other, with no need to change their semantics.

Also, making this distinction at scan time, means that if you want to change it, Navidrome needs to rescan everything again - with a full scan - which can take days sometimes for some large libraries.

i see. so what are my options here?

i guess i could remap the created_at timestamp to updated_at if the latter is lower? would that work?

Instead, "Recently Added" should only rely on the creation (or import?) date of the file that's being processed.

That should be the behaviour if you remove ND_RECENTLYADDEDBYMODTIME: "true". The default behaviour (false) is to use import date (or birth date as per #1350)

That should be the behaviour if you remove ND_RECENTLYADDEDBYMODTIME: "true". The default behaviour (false) is to use import date (or birth date as per #1350)

okay well maybe that's where my confusion comes from: I thought ND_RECENTLYADDEDBYMODTIME was a feature flag that enabled the "birth date used on import" defined in #1350 - those two are actually unrelated?

ND_RECENTLYADDEDBYMODTIME was a feature flag that enabled the "birth date used on import" defined in #1350

No it is not!

ND_RECENTLYADDEDBYMODTIME selects whether to use created_at (false, default) or updated_at (true) for sorting the Recently Added albums view. This was implemented by #822 a couple of years ago.

#1350 (fixed by #2553) was released in 0.50.0, which replaces import date with birth date, on systems that support it, as that's a sensible thing to do (use the actual file creation date instead of the import date)

Ookay... I completely misread this! thanks for the clarification...

is there a way to rescan files so that their creation date is retrofitted back into the created_at field?

Try a full rescan. If that doesn't work, there's no other option except for re-adding all your files, which currently will make you lose your playlists and favourites/ratings/play counts :/

i noticed to that if the song is already in the database, a full rescan will not refresh it with the file creation date.

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Navidrome team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.