Hi,
i have been noticing a few things on the picard app. Firstky there is no stop or pause button to pause or stop the search if it’s going to take too much time/ also where do you select what Tags you want saved, I thought this would be i9n options - Tags - It’s not there and really should be.
Also, the program should save the current set up (auto-save) progress in case the app or computer crashes so you don’t have to go back to the beginning.
a. Autosave - I suppose we could have an option for Picard to save the album as soon as it has completed loading - but this would not be like e.g. the Microsoft Word autosave where it saves it in a separate file, but would instead overwrite the existing metadata without any opportunity for the user to review it first. Is that how you would see “autosave” working?
b. Selecting tags you want saved - I guess the answer here is that Picard starts from the perspective that you want as much metadata saved as possible. You can list tags you don’t want Picard to overwrite in the Options / Tags page. You can script to delete tags that you explicitly don’t want. But there is no easy checklist of tags where for each tag you can select whether to write the updated tag, leave the tag as-is or delete existing tags - and perhaps such a feature would be nice.
c. Stopping or pausing “searching” - I am unclear what exactly you mean by “searching”. Searching (i.e. doing something explicitly called “searching” in Picard) is typically a one-off manual activity that is not long running in the way you suggest. But of course Picard does have many potentially long running activities (Loading files, lookup of MBIDs, getting metadata from MusicBrainz, getting cover art, plugins getting data from 3rd party sites (like AcoustId), saving files are a few that immediately come to mind) that you might want to stop. The difficulty is that each of these types of activity would have different consequences were you to stop them - and we would not want to leave Picard in any form of inconsistent state. That probably means that we would need to consider how “stop” would work for each of these types of activities and write code to clean up and maintain a consistent state. We might also need to consider how to allow the user to stop particular type(s) of activity without stopping others.
My own experience of long running Picard activities, is that I started with small sets of files when I didn’t really know whether what I was doing was correct - thus avoiding super long running activities - and only when I had the confidence to know that things were working the way I wanted them to would I try to load my entire music collection (and then I wouldn’t have a need to cancel anything). In practice, in the early days there were definitely a few times where I closed Picard and started afresh because I had loaded a lot of files and then decided that I needed to start again - but those were teething problems and I learned to avoid them.
Hope this helps.