Locked fields

[nichobi]

I've been considering a feature of locking fields on tracks and albums from being modified by other operations like mbsync.

Details on my usecase

A lot of music software will group albums by album artist and album title, ignoring any other differences. Two examples of where this causes issues:

• Multiple versions of an album, such as deluxe editions or remasters.
• Artists releasing multiple albums with the same title. (For an extreme case, see Caetano Veloso's 4 self-titled albums from 1968, 1969, 1971 and 1986)

For these I usually end up appending (Deluxe Edition) or (1971) to the album title. Running mbsync will however reset these fields each time, and often times the list of changes is so large it's easy to miss.

Approaches

I've considered two approaches, but I'm not sure which would be easier to implement.

1. A new locked_fields field, consisting of an array of field names that cannot be modified. Would require a hook to interrupt the edit (is this possible?) or hooks before and after editing which save away the values before editing and restore it afterwards.
2. *_override fields (such as album_override), which would utilise a hook to reset album to the value of album_override if it has been changed.

Before I go down one route or the other, I'd love to get feedback on which one (if any) people would find useful, or whether they are even feasible to implement within the beets plugin system.

[JOJ0]

Hi @nichobi, nice ideas, there's a quite old thread discussing similar things: #4087

I just renamed it since it initially was about discogs genre overwrite only and then evolved to a more general feature idea by wisp3rwind. Have a look and see if there's some in common with your ideas.

@arsaboo FYI renamed your issue. Better name idea?

[arsaboo]

I like that. It is increasingly clear that we must clearly define when/how existing fields should be updated. Here are a few of my general thoughts:

1. Plugins should only update their respective fields.
2. The only exception to this rule should be initial import. Note that some fields (e.g., album_id) are required at initial import, and plugins must use some value for those fields.
3. At the time of re-import, plugins should only overwrite fields with the correct value. For example, MB fields should not be overwritten by non-MB data Musicbrainz fields should not be overwritten by non-MB data #4797
4. Some mechanisms to define which fields to ignore.

[afontenot]

I like the idea of

A new locked_fields field, consisting of an array of field names that cannot be modified.

However, I suggest the implementation should have one list of fields that are "locked", meaning that attempts to update them (by mbsync, by re-importing, etc) get ignored (but not silently, I would argue) by Beets, and another list of fields that are "protected" (possible name), meaning that attempts to updated them always get a user prompt from Beets.

A good example of a need for the latter is the "country" field, which often can't be interpreted correctly by Beets. If MusicBrainz has release events for a single release in multiple countries, Beets will use the first country for tagging.

While we're in wishlist mode, an option to have the import function ignore the locked fields and update everything would be very useful for doing initial imports of new files.

A solution along these lines would pretty much solve my issue: #4907