Re-tag the files based on the information in the catalog or external service

[martinatime]

(I'm still trying to work on what is best for this requirement)

• Copy the existing file for historical back up and fall-back in the event of failure or unwanted change
• (optional) create a historical record within the catalog
• Provide the user with a before and after layout of the changes
• Update the file's internal tagging (ID3) with the information from the catalog or an external service such as MusicBrainz
• Upon any changes re-index the file so that the catalog record and file are consistent

[evnjones]

Is the file backup permanent, or only for fallback during the update operation? If it's permanent, then that should be a user option, as not everyone would want (or could store) a complete backup of their library. Another thought, it would be useful to be able to track the permanent backup files in the catalog. So, the datastore becomes a set of "master" records that represent the current state of the catalog, and a set of referenced child records that track the location and metadata from the historical backup. Actually, these child records could take the place of backing up the file itself, as they would represent a complete historical reference of all changes to the file, which could be displayed to the user, if desired.

[martinatime]

I was only being ultra-paranoid especially if this application would have the ability to make mass changes and mass duplicate removals or changes based on a triggered event. I do like the idea that this should be optional. We can discuss all of these options. I like all of these ideas.