The setting is quite confusing. After having difficulty getting the autotagger to accept an id for a specific release that I knew was correct, I investigated and count [this closed issue][0] that totally explains the problem.
To clarify the issue, I quoted Adrian from the issue and elaborated a bit, providing the solution. Unfortunately, the solution is undocumented. I'd like to document it, but I am unsure what the actual weighting system in `distance_weights` is. Adrian says 0.9 to ignore missing_tracks, which implies it's similar to the distance weighting in the other settings, but other settings in the default config are set to multiples of 1, implying it is not.
[0]: https://github.com/beetbox/beets/issues/3064
- Rename config option to overwrite_null
- Leave overwrite_null empty by default
- Handle more potentially null fields for both album and tracks
- Remove documentation and changelog entries for now
Add a new `no_clobber` config option that contains a list of
"miscellaneous" metadata fields not to be overwritten by empty values.
I'm not entirely happy with the `no_clobber` name. Suggestions welcome.
Document important facts for self-hosting musicbrainz with beets. I don't want the beets docs to be the go-to reference for hosting MusicBrainz, but the search index requirement is not explained well on the beets wiki.
Full disclosure, I haven't finished building my index yet so I'm not sure if that is actually why I can't self-host right now. But I remember doing it before to fix beets integration with my Musicbrainz server.
This is related to #2688 where a list of hard-coded non-audio formats to
ignore has been added. Some users may want to rip the audio portion of
video tracks (e.g. DVD-Video) so it would be beneficial to let them
control exactly which formats to ignore.
I added a `ignored_formats` setting for that purpose and moved the
hard-coded list into the config. Test and documentation have been
updated accordingly.
Aside: I also clarified the changelog a bit regarding this change and
the related one for #1210.
Changed the return in case of a relative date, by default precision is
to the second, aka 5
Removed old 'relative' precision that indeed isn't necessary anymore
Corrected doc according to current relative date format, no more @
