Re-tagged items appearing in Recently Added

[Peter StreamMagic]

(14-12-2022 18:13)simoncn Wrote:  The simplest way to remove these albums from your "recently added" list is to change the "last modified" dates of the files in the albums to the dates the albums were added to your library. I presume this is the "last modified" date of the folder containing the files.

MinimServer does not use "last modified" dates of folders in "recently added" processing, only "last modified" dates of files.

Do you mean change de date in added-files.txt?
Like this?
  added-files 14-12-2022.date change.txt (Size: 46.25 KB / Downloads: 2)

[simoncn]

(14-12-2022 19:37)paulM Wrote:  Does this mean that it is not possible to erase a "recently added" list and start again from scratch?

The reason that I ask is because I have recently added replay gain settings to over 2500 (very old) files. This was achieved by a batch edit using dBpoweramp and I presume that this action is enough for minimserver to identify the files as "recently added". Either way, my current "recently added" list is full of stuff I've had for over 10 years. I'd like to start again, but every time I try to edit or delete added-files.txt, minimserver re-creates it.

Given what I have done to the files, I think it is probably right that minimserver identifies them as "recently added", but in my case, I would like them to disappear. Is this possible?

The added-dates.txt file contains files that are detected as new files by a MinimServer rescan, together with the date/time of the rescan that added the file.

Retagged files are only shown as added if they were retagged before the first date that appears in added-dates.txt. For example, if the first date in added-dates.txt is 1st November 2022, files that were added or retagged in October 2022 would appear but files that were retagged in November 2022 would not appear.

Deleting added-files.txt makes no difference as this file is recreated after every rescan. It is for information and diagnostic purposes only.

Deleting added-dates.txt would make things worse, not better. If you do this, the entire contents of the "recently added" list would be recreated based on "last modified" dates including files that were modified by bulk retagging.

You could add a "fake" entry at the start of added-dates.txt that is older than the date when you did the bulk retagging. This would make all the bulk retagged files disappear after the next rescan. I think it would be OK for this "fake" entry to have a file path that doesn't correspond to any real files in your library, as long as it is a valid path. For example the fake entry could be something like:

2022-10-01 00:00:00.000 /share/Music/Fake/Path.flac

and this would eliminate any files retagged after 1st October. I will try this tomorrow and post back here.

A nicer solution could be to have a new property setting instead of this "fake" entry, something like addedStartDate=2022-10-01.

[simoncn]

(14-12-2022 22:08)Peter StreamMagic Wrote:  Do you mean change de date in added-files.txt?
Like this?

Editing added-files.txt makes no difference to anything. You need to change the dates on the filesystem.

[Peter StreamMagic]

(14-12-2022 23:13)simoncn Wrote:  

(14-12-2022 22:08)Peter StreamMagic Wrote:  Do you mean change de date in added-files.txt?
Like this?

Editing added-files.txt makes no difference to anything. You need to change the dates on the filesystem.

Than my first interpretation was correct.
I tried to change these dates but didn't get it done.
How am I supposed to change these dates?

[Peter StreamMagic]

An other question related to this thread: what triggers MinimServer to add an album to added-dates.text?
The reason I ask this: 2022-12-14 21:06:38.978 /share/Multimedia/Multimedia (NAS)/Jimmy Aldridge & Sid Goldsmith/01-01-Jimmy_Aldridge_Sid_Goldsmith-Hope_and_Glory-SMR.flac was added and appeared after the recan (the faulty one with changes made to the added-files.txt)
  added-dates.txt 15-12-2022.txt (Size: 26.65 KB / Downloads: 2)
I cant figure out why this album was added to Recently Added.

[simoncn]

Changing the file path (any folder names or the filename) would cause an album to be recognised as having been added.

There are few tools for changing the "last modified" date of a file. I haven't tried any of these myself. The top match from a Google search is FileDate Changer. Another tool that can do this is Attribute Changer.

[Peter StreamMagic]

(15-12-2022 13:11)simoncn Wrote:  Changing the file path (any folder names or the filename) would cause an album to be recognised as having been added.

The Jimmy Aldridge & Sid Goldsmith file was retagged 28-05-2022 , latest changes in folder date: 01-05-2022
       
I think it has something to do with this:

When filling the "recently added" list, MinimSever looks first for files in the library that it can identify as being added by a rescan. If there are not enough of these files to completely fill the "recently added" list, MinimServer places other files in this list in the order of their "last modified" dates. This is how the "recently added" list is populated the first time "recently added" is enabled. In most cases (except for retagged files), the "last modified" date will be similar to the date the file was added to the library

I think if there is no recently added album (e.g. last week)MinimServer should show nothing.
The Jimmy Aldridge & Sid Goldsmith album is now displayed as added last day
but originally added 30-09-2018.

[simoncn]

Your explanation is not consistent with the file being added to added-dates.txt. A file is added to added-dates.txt by a rescan only if it was not present in the library before the rescan (using a complete file path match). A change to a folder name would cause this to happen but would not change the "last modified" date of the folder.

[Peter StreamMagic]

(15-12-2022 14:12)simoncn Wrote:  Your explanation is not consistent with the file being added to added-dates.txt. A file is added to added-dates.txt by a rescan only if it was not present in the library before the rescan (using a complete file path match). A change to a folder name would cause this to happen but would not change the "last modified" date of the folder.

So, why did this album appear after rescan?

[simoncn]

The only explanation I have is that a folder name or location was changed.