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.

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

                              Indeed... I wouldn't bother to have this setting for all kind of libraries. If somebody is against this plz feel free to comment.

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

                              Interesting idea. But considering this might might be used for the quality filter I think this would be a lost of processing time. Because if a filter is set we would need to do this query each time we request a tracks or a library information and this happens a lot.

                              • gcrk replied to this.

                                    petitminion Indeed… I wouldn’t bother to have this setting for all kind of libraries. If somebody is against this plz feel free to comment.

                                    Well, we can at first build a setting that just checks all uploads and implement differentiation by library or later collection in a later stage.

                                    petitminion Interesting idea. But considering this might might be used for the quality filter I think this would be a lost of processing time. Because if a filter is set we would need to do this query each time we request a tracks or a library information and this happens a lot.

                                    You need to run a query anyways, and I don't think running a COUNT on a table is much slower then querying a field. Considering the field might be outdated all the time, I really prefer my proposition.

                                    Some theory: Storing a derived value is basically a violation of database normalization. Of course there are always scenarios where such violations are valid. However, this needs to be well thought about and I'd prefer to test the sane way, in case its super slow we can always consider a workaround. For a discussion, check this StackExchange