-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discogs (and other metadata sources) polluting mb_albumid #604
Comments
This is a great point; reusing the MBID fields is an abuse that can cause weird problems. We should instead set a flexible attribute. Alas, we currently don't have a mechanism for setting flexible attributes from metadata matches, but we should definitely add this. (In fact, doing so could simplify the |
I played around with a few solutions, but none were ideal. The first was to store The second idea was to change class AlbumInfo(object):
def __init__(self, **kwargs):
values = {}
values.update(kwargs)
object.__setattr__(self, 'values', values)
def __getattr__(self, item):
return self.values.get(item, None)
def __setattr__(self, key, value):
self.values[key] = value In this scenario the data-source plugins could set their own fields (to be stored as flexible attributes) when instantiating AlbumInfo. Discogs could set The advantage here is that you're not limited to just the one data-source. |
Absolutely; the second approach is definitely the way to go! The AlbumInfo and TrackInfo objects should be able to carry along arbitrary field settings that are then applied in apply_metadata. The only trick is that they should also have some fields that are not just dict keys because some fields are required or need special handling—see the apply_metadata code for those fields. |
I just wanted to add that this is also true for the artist_id. If an album is identified via discogs, it will be tagged with discogs' artist-id. I stumbled upon this because when I import my library into Ampache, it will frequently have the same artist twice - one with the Musicbrainz id, and one with Discogs', and I have to manually fix that. |
It's also worth noting that the Dicogs data source does not supply mb_trackid information, so (by default) the Duplicates plugin will flag anything that shares null entries for this field as duplicate. Meaning, all Discogs-tagged tracks will be flagged as a duplicate. The workaround is to additionally add a third parameter to the Duplicate plugin to lastly analyze Title. |
@sampsyo Asked me to leave my thoughts here. #2763 My suggestion is to create the following fields for Discogs (TXXX is customizable so that wouldn't be a problem).
|
Agreed with @nicolahinssen on adding special fields for Discogs. This is a feature I would love to see. More generally, it will be great to store metadata from other sources (Bandcamp, Beatport, etc.) in the same way. The plugins retrieving the metadata should be able to define special fields themselves. Probably there won't be a consensus on naming of the fields, therefore this naming could be configurable by a user. |
Should then all |
I would actually be in favor of abandoning all the hand-coded attributes and just moving over complete to an unstructured |
Hello, Maybe the simplest solution would be setting flexible attributes, as previously suggested
? |
Another use case that I'm running into is tagging an audiobook collection with metadata from Audible. Because of the hard-coded fields, I don't think its possible for me to store additional metadata that is not already defined in one of the existing fields. Wondering if there are any plans to fix this in the near / mid term? Edit: I realized my comment may not fit this issue, perhaps I should move it to #2866 instead. |
The discogs plugin sets
album_id
of theAlbumInfo
class to a discogs identifier, whichbeets.autotag.apply_metadata
assigns tomb_albumid
. The problem is that everywhere else it's assumed to be a MusicBrainz identifier.The text was updated successfully, but these errors were encountered: