New feature : only allow musicbrainz tagged file to be uploaded ?

petitminion

gcrk Its probably a totally different feature and should be done independently, I just don't think its good to start dozens of feature drafts now, instead we should carry follow-ups with them. I think our spec draft template has a section for this already.

I don't remember anything about limits of features or enhancement request in the forum. And I don't think we should put one because it will be strange and hard to manage and I don't think it's useful : If we don't have time we can wait before responding don't you think ?

gcrk For me this feels like a logic first step. Lets say you have an album which has well aligned tags but no mbid. But the mbid is available and lets assume there is a perfect match for now. Now the instance admin decides to only accept tracks with mbid. This album wouldn't be allowed, but its frustrating for the user, maybe even hard to understand why it was blocked and if we have a flow in place which automatically fetched the mbid, it would be a much better experience.

I would understand the frustration but even a well tagged song can generate duplicates or not have an acoustid. So even well tagged file could not be uploaded and it would still be frustrating...could even be confusing why some song are uploaded and other not, which is even more frustrating

gcrk

petitminion I don't remember anything about limits of features or enhancement request in the forum. And I don't think we should put one because it will be strange and hard to manage and I don't think it's useful : If we don't have time we can wait before responding don't you think ?

Okay, to be clear here: I don't want to limit anything, I just think if we identify a dependency between two features, we should put the depending one on pause until the previous one is finished.

I could absolutely live with "we just reply later", but my experience is that old threads here in the forum are never touched again - so I am in fear of loosing great ideas.

petitminion I would understand the frustration but even a well tagged song can generate duplicates or not have an acoustid. So even well tagged file could not be uploaded and it would still be frustrating...could even be confusing why some song are uploaded and other not, which is even more frustrating

The first step in any case is to properly communicate WHY a upload was rejected, before we add more reasons to reject. Thats true. But even if 5% of the tracks get properly tagged, I'd say its a win already. Just grab the low hanging fruits 🙂

petitminion

gcrk Okay, to be clear here: I don't want to limit anything, I just think if we identify a dependency between two features, we should put the depending one on pause until the previous one is finished.

Oh yes ofc ! I could create an epic "content curation" about all thing related to music recommendation, mbid, acoustid and linked issues and forum posts to each issue ? But this means we should first define clearly this epic..

gcrk The first step in any case is to properly communicate WHY a upload was rejected, before we add more reasons to reject. Thats true. But even if 5% of the tracks get properly tagged, I'd say its a win already. Just grab the low hanging fruits 🙂

Actually explain upload rejection is done quit well don't you think ?
And yeah I agree acoustid is a win but I don't think it need to be done before this enhancement

petitminion

For now I have :

two settings opt-in (1 and 2 from first post)
New upload refuse log (to explain why the upload have been refused)
Add theses setting to instance nodeinfo
future step : implement acoustid, and speak about allowing to created mbid from song publishing into fw

so is it okey if I write a spec for this ? Or does someone think we need to speak more about this ?

tallship

petitminion

I see no reason not to continue with work and implementation. Choices are a good thing! 🙂

The notion of a requirement that such data is included before audio tracks can be uploaded in certainly not in favor of.

In my particular case, I often strip out all the fields in the fields of the .mp3 file, or decide on what metadata i want in there.

Musicbrainz is a publicly editable database where control over the works by the artists themselves is seemingly wrested from them and their publishers.

I just don't know enough as of yet I guess, but to make it mandatory is quite a stretch, and it sounds someonedictatorial.

So yes, I think much more discussion is in order.

[deleted]

tallship The notion of a requirement that such data is included before audio tracks can be uploaded in certainly not in favor of.

The title is not quite right for this topic because the whole point is to make this feature available but opt-in.

petitminion

The notion of a requirement that such data is included before audio tracks can be uploaded in certainly not in favor of.

this feature is about giving admin the right to have this approach because it has a lots of benefits in a context of federation (no duplicates, hability to match date from one pod to another, music recomentation etc). But I understand you don't want to tag your files with mb. And if you are in a pod with your approach you will not have to because this will be optional.

Do you have any drawbacks or recommendations ?

petitminion

Ok so any other drawbacks ?

petitminion

I started writing the spec but I have a question : what about federated content ?

It should be possible to add another setting that prevent federation with content that is not tagged with mbid. Do we want this ?
I'm not sure how this should be implemented in the frontend. Would a general warning display one time enough ? Or should we warn the users each time they try to follow a remote library ?

Sporiff

petitminion This is a good question. My expectation as an admin would be that: if I set my instance to only accept MBID-tagged files I would also want federated content to be filtered the same way. The whole point is that you want well-curated content to appear on your pod.

This could be made configurable, I suppose. The admin could restrict file uploads to requiring an MBID, but then have the remote fetches allow non-tagged files if they want more content. Alternatively, they could restrict the remote content as well to have a neater collection.

petitminion

Sporiff I totally agree, and what do you think about the frontend implementation ? How to make clear to the user that not every content will be federated ?

Sporiff

petitminion I'm trying to think of where the user would see this information. I guess we could have a dismissible warning on federated content pages (e.g. album pages, track pages, artist pages), but that could get quite annoying. There's not really much the user can do about the missing content, so I'm inclined to say we shouldn't draw attention to it. The whole point here is to improve the quality of the library and reduce visual clutter.

It might be more useful to have a warning appear for users who upload content on a pod where you can upload without an MBID. It could convey that "to make sure everyone can see your content across federation, you should tag it with MusicBrainz" or something to that effect.

petitminion

Sporiff It might be more useful to have a warning appear for users who upload content on a pod where you can upload without an MBID. It could convey that "to make sure everyone can see your content across federation, you should tag it with MusicBrainz" or something to that effect.

Indeed seems like a good idea !

petitminion

Technical point : what do you think to update the library model to add an attribute allowing us to know if the content is following mb tagging system or not. Attribute name proposition : mbid_tagged_content. Create a task that will set the mbid_tagged_content attribute to its correct value. Run this task each time a track is added to a library (the task would be very fast, because it will only check if the settings did not changed)

draft spec ! https://pad.funkwhale.audio/v5vPleb7SyK28B-4SjI7Hw

petitminion

more complex technical points : can be found in the spec. I didn't look precisely the upload process yet, but if the general logic sounds good I will update the spec as I code

petitminion

any news on this ? If not can I start coding this ?

gcrk

@petitminion Its still on my to-read list. Since it has funding I need to raise the priority, sorry for the delay. Maybe @Sporiff has some time for the spec after their holidays 🙂

Sporiff

@petitminion @gcrk I plan to work on this one this week

tallship

How is this initiative coming along? Has development work started on this yet?

gcrk

@petitminion I've gone through the spec and I have the following points:

I wouldn't add the federated stuff here. Lets focus on uploading first, touching the federation is a totally different part of the code and if we display content thats not properly tagged is more in the scope of the quality filters we are discussing.
I'd expect the setting to allow uploads with or without mbids to be an instance level setting made by the admins, but thats not explicitly specified. Is this an instance setting?
I think the first iteration should be to add the setting and update the upload process to check if a mbid is given or not. Everything else is nice, but can be added later to clean up the database.

petitminion

gcrk

I agree about the federation, this bothered me to
Yes it's an instance level setting
Okey, let's do it this way.

Spec is update, I will start working on this in 2 weeks unless someone has something to add