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

      9 days later

      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 ?

        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.

            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 ?

            • [deleted]

            • Post #14

            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.

              14 days later
              5 months later

              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 ?

                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.

                    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 ?

                        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.

                            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 !

                              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

                              8 days later

                              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

                              a month later

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

                              7 days later

                              @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 🙂

                              7 days later
                              21 days later

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

                              2 months later

                              @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.

                                gcrk

                                1. I agree about the federation, this bothered me to
                                2. Yes it's an instance level setting
                                3. 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

                                  The differentiation between public and private libraries includes a lot of complexity. I am wondering if its worth it.

                                  For the implementation details I don't think storing mbid_tagged_content in the database is a good idea. It can be quite easily calculated and might change often, if we ever forgot to update it, the entry is wrong. Its better to calculate it on the fly. We just need to query the database for tracks in a specific library without mbid and count them, this should be easy enough to do.