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

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

gcrk

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.

petitminion

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

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

petitminion

gcrk let's try without, if there is performance issues we will resolve them

petitminion

spec is updated, coding started

petitminion

Well it was easy, I suggest since we have funds for this that I add -

a cli command to clean the db from untagged files (from public librairies, optionnaly from private libraries too)
implement the private/public distinction and default this setting to true

This can be easily implemented, instead of checking if a lib has mbid taggeg content we could just check this in the upload process and don't touch the stuff that where already implemented. If the admin really want to clen its db, they will have to use the cli.

petitminion

Any pov on this ? If not I will at least implement the cli command next week and close this task.

« Previous Page