Tidal "providers" are distributors, not release labels

[kellnerd]

As it was recently discussed on the forums, the release property which Tidal calls the "provider" always seems to be the distributor, and not the release label / imprint.

This probably wasn't reported for a long time, because Harmony usually prefers the release label from one of the other sources and only introduces bad data on MB for Tidal exclusives.
Exposing the distributor is quite useful (as no other provider currently provides this information), so we should have a separate HarmonyRelease property for it instead of just letting the Tidal provider return no labels at all.

The open question is whether we should have a dedicated HarmonyRelease.distributors property or whether we should implement this as part of a more flexible, structured relationship system.
Each relationship would have a target (ResolvableEntity?), a target type and a rel type at least.
We will display these relationships alongside the text-based HarmonyRelease.credits for now.
In the future there might be a way to seed the MB release relationship editor with this data.

P.S. At the time the provider for the v1 API was implemented, it has already been noted that the provider/label was often empty, which explains how the current logic came to be.

[UltimateRiff]

wanted to add a note that YouTube Music #31 often provides the distributor in the video description, so if that gets done before this, that could be a good double-check for releases on both platforms

[arsinclair]

I'd say it makes sense to model it closer to how MB implements it. So it's a relationship between two entities, that has a type and direction.

By the way, I always wondered why it is not possible to seed releae relationships? I've spent countless hours populating copyrights, componsers, etc (maybe I should ask it elsewhere actually).

[UltimateRiff]

I don't think it's been intentionally excluded, just not yet implemented (see MBS-13616), at least not on the new relationship editor

[arsinclair]

Right, thanks for the link. I don't know the magnitude of the task, but if it's a task for 4-5 hours, I might take a stab at this. The amount of time saved by this feature could easily overweigh the amount of time spent on the implementation.

I understand from Jira that no one is working on the task yet?

[UltimateRiff]

I understand from Jira that no one is working on the task yet?

that's how I read it, yeah. thanks for taking a look at this one~