Recently Added

[simonbun]

For local content Symfonium can make use of the ENCODINGTIME tag instead of relying on file creation/modification times to denote when a track/album was added.

Over the years I've re-tagged and re-encoded my collection multiple times to the point where the file dates are now meaningless, but I've always held this information in a tag called DATEADDED for this very purpose - which I would be very happy to modify (although it would be nice if any solution could take date or datetime).
Prioritizing this tag over the file creation/modification date I think would provide a more reliable and stable solution, although I do appreciate that I can modify the file attributes to achieve the same result.

Thanks for 3.61.0 by the way it fixed ALL my album attribution issues, and I'm looking forward to importing playlists in 3.62.0!

[epoupon]

Hello!

I am working to properly handle "recently added" / "recently modified" tracks:

• recently added: uses "added" time, i.e. the date/time when it has been actually added in the database (immutable once set)
• recently modified:: uses the date/time of the last file modification

If I understand correctly, you want to set the "added" time using the date/time you put in the ENCODINGTIME tag?

[simonbun]

Hi!

Just a clarification:

recently added: uses "added" time, i.e. the date/time when it has been actually added in the database (immutable once set)

For the very first LMS scan it should be based on the file's modification date, with all subsequent additions using the scan date (just as you do for playlists). I'm sure you remember that conversation but I thought I'd mention it just in case.

Yes I was hoping that ENCODINGTIME could be used instead of the above logic. I guess it's probably safer if this is disabled by default - assuming you were planning to make it configurable.

It looks like v3.63.0 is going to be a big one 👍

[epoupon]

For playlists, the "created" time should be the actual playlist creation time in the db (not the last modified time when the playlist is imported), if we do speak about the same thing!

Edit: "with all subsequent additions using the scan date (just as you do for playlists)", but that's if we have a single field?
For now we have both fields in database (added / last modified)

[simonbun]

For playlists, the "created" time should be the actual playlist creation time in the db (not the last modified time when the playlist is imported), if we do speak about the same thing!

Don't introduce "created" :-)

From this conversation, date added is based on the modification date during the initial scan, with scan date used for all subsequent scans/additions.

I think.

[epoupon]

Ah this conversation indeed!
And what do you expect in case of a forced manual full rescan? Reset both "added" and "last modified" entries to the last modification time of the file?

[simonbun]

My assumption is that a full rescan maintains the existing paths and object id's.

To keep it simple (to communicate), for existing objects I would just refresh the contents (tag data and playlist contents) and leave the added and modified dates alone, unless the added date is being pulled from ENCODINGTIME.
In other words a full rescan refreshes the CONTENT of existing objects.

For new objects I would treat it as a non-first time load (scan date for added and modification date for modified).

I believe a subsequent scan would refresh all modified dates, so the only unhandled scenario is where one wants to reset the date added. I'll have a think but I can't imagine ever wanting to do that.

[simonbun]

There really is no reason to retain the existing modification dates (given they'll be updated on a subsequent scan), so maybe the simpler rule is that everything will be refreshed apart from date added (if not sourced from ENCODINGTIME).