Kodi Community Forum

I'm looking at changes to the music library to ensure that all songs, and albums, have at least one artist. The idea came up in the discussion of PR9081

At the moment if you scan a music file without an ARTIST/TPE1 tag into the library then a record is created in the song table but not a song_artist entry. The result is songs without any artist. Many users will not have this at all, but older and larger libraries do tend to have at least a few like it. This brings at least 2 issues:

1) All queries wanting song or album and their artist(s) have to be left joins. Unfortunately there is a weakness in the SQLite optimiser that means that left joins onto views are not optimised and run horribly slowly. One work around is to replace all the views in left joins with the explicit fields and tables, but it is not as eay to maintain or read.

2) Songs without artists are hidden in the UI. They do not get listed in a Genre -> Artist -> Album -> song approach. Only the songs node, listing all the songs, would show them.

From a data view point in makes a lot of sense for Kodi to collect all songs without an artist tag under a single "unknown" artist. This would mean that we can use more efficient inner joins in queries, but also that the "unknown" artist would appear in the artist node and reveal those previously lost songs to the user.

On music database update from older versions existing songs without artists will need to be updated (adding song_arist entries). In testing I have learned that this needs temp indices on the tables or it is unbelievably slow.

It also happens that Musicbrainz has an "[unknown]" musicbrainzartistid entry, so some user libraries could already have an "unknown" artist if their music files were tagged with that. It makes sense to me that Kodi treats both those untagged songs and those tagged as "unknown" in the same way internally.

That a song did not have an artist tag is recorded in the database by the song.strArtists field being empty. This also means that when the song is listed or played you do not see an unwanted "unknown" in the place of artist name but blank as currently. This is particularly important if the artist name has been included in the song title (a historic practice).

Unlike "various artists" where, because the entry is only based on name, you can end up with multiple artist entries in different languages, depending on your language settings when you scanned, I propose that we ensure there is only ever one "unknown" artist entry. This uniqueness can be provided internally by using musicbrainzid.

The internationalisation of "unknown" artist then becomes that same as that for all artist names. If you tag a music file with the "[unknown]" musicbrainzartistid and an artist/TPE1 tag of "onbekend" or "?" and that is the last scanned with that mbid then "onbekend" etc. is what appears in the artist node and becomes your unknown artist label.

The only question is what name is used for "unknown" initially?

So what have I overlooked?

(2016-02-17, 16:57)DaveBlake Wrote: [ -> ]It also happens that Musicbrainz has an "[unknown]" musicbrainzartistid entry, so some user libraries could already have an "unknown" artist if their music files were tagged with that. It makes sense to me that Kodi treats both those untagged songs and those tagged as "unknown" in the same way internally.

From a pure data point of view, a song tagged with an explicit unknown artist is different from a song without an artist tag.

In one case the user explicitly says I do not know the artist, the second says I have not yet set the TAG.

They may want to be able to differentiate them to add proper tagging, since in the end this is what you push for, users retagging correctly their collection.

(2016-02-17, 16:57)DaveBlake Wrote: [ -> ]The internationalisation of "unknown" artist then becomes that same as that for all artist names. If you tag a music file with the "[unknown]" musicbrainzartistid and an artist/TPE1 tag of "onbekend" or "?" and that is the last scanned with that mbid then "onbekend" etc. is what appears in the artist node and becomes your unknown artist label.

This needs proper handling and logging in database, because unfortunately for me when I tested your patch I had an artist in on song that had this unknown MBID and now all the songs / albums are related to this artist.

This is something that can happen easily for all users that do not really use MBID, you get some MP3 with tags with MBID that contains unknown because it's not on MB but then use a basic MP3 tag tool to set the artist name. And now unknown is a random artist.

(2016-02-17, 16:57)DaveBlake Wrote: [ -> ]Unlike "various artists" where, because the entry is only based on name, you can end up with multiple artist entries in different languages, depending on your language settings when you scanned, I propose that we ensure there is only ever one "unknown" artist entry. This uniqueness can be provided internally by using musicbrainzid.

The only question is what name is used for "unknown" initially?

As explained the problem is not the multiplication of the data, it's the translation that is hard coded in the database.

You scrape in English you have the value hard coded in English for ever, even if you change your Kodi language. Same in the opposite way.
Same for JSON API consumers, they might want to identify this special case to offer proper translations for their user. Or to move then in list to start or end to differentiate them.

Since this unknown value is a display value, it should not be stored as the displayed value in the database, but translated at the display level.

So hard coding the translation of this display value in database for consumers that may want this data in another language is not cool at all.

And since your solution is based on MBID the only way for API consumer to discover this special case is to get MBIDs and use 36 char strings for that is not quite efficient.

IMO a proper solution include differentiating missing artist from unknown artist, and offer translation at display level.

(2016-02-17, 17:38)Tolriq Wrote: [ -> ]From a pure data point of view, a song tagged with an explicit unknown artist is different from a song without an artist tag.
In one case the user explicitly says I do not know the artist, the second says I have not yet set the TAG.

What I propose preserves how the file was tagged, or not, in the strArtists field of the song table. This is available in JSON as "displayartist". Either remote app or smart playlist rule can find those songs if required, the "pure data" is available just as it always has been.

But unless searching specifically for those songs you have not tagged with an artist (is that something users ever do?), surely it is most convenient for users to generally have those they have not tagged and those they have tagged with the "unknown artist" MBID displayed together?

Quote:

(2016-02-17, 16:57)DaveBlake Wrote: [ -> ]The internationalisation of "unknown" artist then becomes that same as that for all artist names. If you tag a music file with the "[unknown]" musicbrainzartistid and an artist/TPE1 tag of "onbekend" or "?" and that is the last scanned with that mbid then "onbekend" etc. is what appears in the artist node and becomes your unknown artist label.

This needs proper handling and logging in database, because unfortunately for me when I tested your patch I had an artist in on song that had this unknown MBID and now all the songs / albums are related to this artist.

This is something that can happen easily for all users that do not really use MBID, you get some MP3 with tags with MBID that contains unknown because it's not on MB but then use a basic MP3 tag tool to set the artist name. And now unknown is a random artist.

Yeap you saw a WIP, while looking for a speed problem that turned out not to exist.

As I understand it "unknown artist" MBID is quite rare - if they have the song they have the artist. But I can see that is how such odd mis-tagging could occur. Changing artist tags oblivious of MBID is an issue for all artist data not just "unknown", and can produce odd results in the library. Not sure how we guard against such bad tagging?

It also happens to a lesser extent with names in different languages. I prefer anglised "Tchaikovsky, Peter", and accidentally end up with "Pyotr Ilyich Chaykovsky" if that is how the last thing scanned was tagged. But at least with MBIDs I don't end up with two or more entries for Tchaikovsky.

In this instance do we force "unknown artist" MBID to always to be displayed "unknown" (in your chosen language)? What about the other artists names? It seems more consistent to me to just treat "unknown" as another artist name.

Quote:As explained the problem is not the multiplication of the data, it's the translation that is hard coded in the database.

You scrape in English you have the value hard coded in English for everr, even if you change your Kodi language. Same in the opposite way.
Same for JSON API consumers, they might want to identify this special case to offer proper translations for their user. Or to move then in list to start or end to differentiate them.

Since this unknown value is a display value, it should not be stored as the displayed value in the database, but translated at the display level.

You are taking it as a display value, why not think of "unknown" as just another artist name? What is special about it? Scan "Pyotr Ilyich Chaykovsky" from a tag and that is what you get no matter what language setting Kodi has. In some sense all Kodi artist names are display values.

Currently in the API "displayartist" returns the artist tag as a string, empty if untagged, "artist" returns an array of artist names, and "artistid" and array of IDs each in the artist table. Although "displayartist" is often a union of the artist array they could be completely different. For example

"displayartist" = "Tchaikovsky, Peter"
"artist" = ["Pyotr Ilyich Chaykovsky"]
"artistid" = [4577]

"displayartist" = "Erick Morillo Feat The Audiobullys"
"artist" = ["Erick Morillo", "The Audiobullys"]
"artistid" = [187, 3488]

With what I propose we could similarly get
"displayartist" = ""
"artist" = ["[Unknown]"]
"artistid" = [302]

How do JSON API consumers currently identify songs without artists? Do they need to?

But as a JSON API consumer if you say you have a need to get the artistid of certain artists quickly and easily then let's see how that can best be done. With the unknown artist it will be easy, there will be only one regardless of how many language setting changes you have had between scans. Would be trivial if GetArtists or GetArtistDetails allowed MBID as a filter, of course name string won't work as you don't know what that will be (for sure). How about a new explicit API call GetUnknownArtistID?

If we modified "various artists" to have only a single record too, then a similar routine would be possible.

Quote:So hard coding the translation of this display value in database for consumers that may want this data in another language is not cool at all.

The facility to translate all artist names into localised preferences, that would be cool.
Just because in my WIP I took the initial "unknown" artist string from the localised strings does not mean it is a display value per se.

Quote:And since your solution is based on MBID the only way for API consumer to discover this special case is to get MBIDs and use 36 char strings for that is not quite efficient.

Since all that was changing for API consumers was that a few songs would get an artistid rather than blank, and as far as I know they don't attempt to do anything with those where it had been blank, it did not cross my mind there was a need to know the artistid. You say there is, so we add to the API for it. Nothing about using MBIDs for this in Kodi has to change.

Quote:IMO a proper solution include differentiating missing artist from unknown artist, and offer translation at display level.

OK, so here is the nubb of it. Perhaps others could comment?

As a user I would want to see missing artist tag and tagged as "unknown" combined, multiple artist entries for these would just confuse. For an API consumer that wants to separate them they will be able to use "displayartist". Do we really need separate artist IDs for missing and unknown?

I look forward to my remote translating artist names for me, meanwhile I will translate that requirement to be for both unknown/missing artist and VA to each have a single artistid, and for a routine to return what that value is.

Or does someone want a "magic number" approach whereby 1 is always VA and 2 is "unknown/missing"? I don't fancy the id updates required if these id are already in use in a large library.

Or we could have a "special artist" table that gives the ID of VA, unknown and missing....?

Tolriq Wrote:They may want to be able to differentiate them to add proper tagging, since in the end this is what you push for, users retagging correctly their collection.

Tolriq Wrote:Same for JSON API consumers, they might want to identify this special case to offer proper translations for their user. Or to move then in list to start or end to differentiate them.

Both related to Artist table not the song level.

GetUnknownArtistID could fill the gap but it's one more step that should not be necessary.

And what change is that you add a ... new artist that is not an artist, so it needs to be easily identifiable from the API / user point of view, to hide it from artist list for example or show it at a special place like said before.

This is the same for roles, you add new artists that are only contributors they need to be identifiable to be usable from API.

Quote:Do we really need separate artist IDs for missing and unknown?

They are not the same, your solution is to filter later on displayartist is empty to differentiate. But then what's the purpose of having the artist id first ? This means that an unique artist represent 2 different things ...

From API point of view we query artist we get unknown we query songs from this artist, the fact that we need to filter on display artist if we want to differentiate artist that are different but the same from the API is an hack.

You want both to be displayed from the same artist then merge them, API should be agnostic of what user want, the data is "different artist", not same artist with an hack on another field to find different artist.

Quote:You are taking it as a display value, why not think of "unknown" as just another artist name? What is special about it? Scan "Pyotr Ilyich Chaykovsky" from a tag and that is what you get no matter what language setting Kodi has. In some sense all Kodi artist names are display values.

Because in one case this is the data the user decided to put, in the other case this is data that Kodi invent. Since this invented data represent something that does not exist it's a display value to indicate the absence of this data... So it should be translated in user language whatever display language or API he use.

If the user have tagged unknown in whatever language then it's his choice, and since he decided this it's normal that it's treated as normal artist unlike the missing artist that is more missing than unknown in the end from a data point of view.

We could debate also about MBID that lot's of users would like disabled to avoid full re tag of their library but this discussion seemed to be lost, so will not try to argue again.

No worries, I will abandon any attempt to improve this area, it is just too hard. It can stay with slower left joins, and songs that Kodi hardly ever shows.

If anyone else wants to work on this then my WIP is here https://github.com/DaveTBlake/xbmc/tree/...HaveArtist

Not sure to understand why you asked me to give my point of view in that case. Could have used my time on something else.

There's place and need for improvement and finding a correct solution could also fix Various Artist. But fixing one problem by going the same way as another known problem (VA) does not sound optimal that's all.

Tolriq it was not my intention to waste your time or mine, but I suddenly realised late last night that was what we were doing.

We agree that all songs having an artist would be an improvement, but not on how to implement it. If I don't implement it in the way that you want then you will complain, and keep complaining on every other work I do, so I choose on this ocassion to give up.

Musicbrainzartistids are useful within Kodi, artist name alone is not enough to uniquely identify artists e.g. "John Williams" classical guitarist from "John Williams" composer/conductor, or recognise variations on the same name e.g. "Tchaikovsky, Peter" is same artist as "Pyotr Ilyich Chaykovsky". It is up to API consumers if they use MBID or not, Kodi exposes them if they want that data, but I guess they can just rely on Kodi to identify artists correctly. It is up to users if they tag with MBID or not, all Kodi can ask is that if they do use MBID they do so correctly. The negative user view of MBID, yes some do express that, is mostly because of the messy results that initially came from mis-matched tags. That has been improved in Jarvis, which is more tollerant of inconsistent tagging, so maybe user predudice will change. Turning off MBID would solve little, just lessen Kodi functionality. But I digress.

Quote:There's place and need for improvement and finding a correct solution could also fix Various Artist. But fixing one problem by going the same way as another known problem (VA) does not sound optimal that's all.

For the record I had no intention of going the same way as VA, and I was happy to give API consumers whatever it was they wanted in whatever form they want it.

What I didn't want to do is create a special dummy artist and treat it differently from all the other artists, and differently from where the songs happen to be tagged with the same artist as the display value for the dummy. Having two "John Williams" in my artist list makes some sense (and would have different fan art helping me spot the one I wanted), while having two "Unknown" one for those tagged "Unknown" and the other for the missing artist tags would just be clutter.

BTW Tolriq do you want to separate those albums with album artist = VA that have songs tagged with ALBUMARTIST/TPE2 = "Various Artists" (in whatever language), from those that Kodi has determined has album artist = VA because the songs have different artist tags? In pure data terms they are different, one is invented by Kodi the other is in tags, but what use would this be for the user? Instead as a user I wish Kodi could collect all the variations on "various", that come from scanning in different language settings and from inconsistent tagging, all together for me automatically.

But work on this is futile if the only other person interested in it fundamentally disagrees on both requirements and implementation. Input from third party could be useful, if anyone cares to read our verbose posts!

(2016-02-18, 15:29)DaveBlake Wrote: [ -> ]We agree that all songs having an artist would be an improvement, but not on how to implement it. If I don't implement it in the way that you want then you will complain, and keep complaining on every other work I do, so I choose on this ocassion to give up.

This is false and you know it The other problem was a real problem that you are fixing, you can implement all you want as you want, I just give opinion on the fact it's usable from API consumer point of view or not. And will or will not use the API.

You asked me my opinions I give them.

The other "problem" is that you break JSON conventions and introduced problems that needs API change to fix, that I will always complains and fight as I care about Kodi stability and have fought for it since 2009 ..... Do not mix the 2 cases, this is complete different story.

You asked me to test a Kodi build that I did, I did get some problems that I reported, and I'm sure my case about an existing artist with MBID of unknown is not that rare and should be managed.

Does it sounds crazy that I ask that my songs without an artist are not tagged with a random artist because of 1 false TAG somewhere ? This is what lot's of users of MBID without managing them will have problem with I'm sure.

In my case I was lucky I only have 12 songs from that artist so can be fixed (easy when reading the db, more complicated from Kodi interface), but without logs and way to manage this, this cause big problems with little solution for users to fix.

About VA this is complicated because Wiki says to TAG Various Artist, but yes since the data is different, API should show this difference.

As previously you mix what is displayed from what API should do. The fact that the API differentiate the 2 things, have only benefits, it allows to see the difference while still allowing any consumer (including Kodi so) to merge the data if this is what you want.

But having no way to differentiate the 2 cases from the API make that for the users that do want the separation it's not possible.

This is the core of our point of view divergence since 9 months and I can't agree with you on that. An API is user desire agnostic, an API should return the data, then it's API consumer job to use the data in a way that fit user needs.

I perfectly agree with all your explanations and your needs, and I also agree that your needs may represent the majority of the need. But I certainly do not agree that the API should be limited by the majority of the need for in fine no valid reason.

Having an API that can do more will fit all your needs, and all the needs you do not think about. Having an API that is limited to what you think is majority of usage, forbid all other possible usage.

So as I tried to explained since 9 month, API should be data related, API consumers then apply whatever they want to the data to fit user needs. Not the other way around.

As examples I can talk about the fact that the API should not be limited to what is set in Kodi settings, it would be a total non sense if the Kodi API offers no way to get compilation artist because the user have hidden them in Kodi. Or to not offer sorting different that the one the user have chosen in Kodi.

This is the exact same, the data is different there's no logical reason to hide this fact from the API point of view, but the fact that the API does not hide it, does not force the API consumer (Kodi for example) to hide it.

(2016-02-18, 15:58)Tolriq Wrote: [ -> ]

(2016-02-18, 15:29)DaveBlake Wrote: [ -> ]We agree that all songs having an artist would be an improvement, but not on how to implement it. If I don't implement it in the way that you want then you will complain, and keep complaining on every other work I do, so I choose on this ocassion to give up.

This is false and you know it

No honestly it is how I experience it. If you for whatever reason don't want to implement things yourself, but do want to encourage others to do so then you need to change your approach. It is not my nature to quit, but I don't see any way forward.

Quote:You asked me to test a Kodi build that I did, I did get some problems that I reported, and I'm sure my case about an existing artist with MBID of unknown is not that rare and should be managed.

Yes I asked you to do some speed test again because I was chasing a speed problem you reported and I could not reproduce it. It turns out there was never a speed problem with GetArtists, or at least it magically fixed itself, which is good. But I used my WIP build, mostly because I didn't want to have to rebuild my dev environment at the time if I needed to debug. I got some useful feedback on that too, thanks, but I was not asking for feedback on my WIP at that time. Anyway then we started debating and I hoped something positive could come from it.

Quote:Does it sounds crazy that I ask that my songs without an artist are not tagged with a random artist because of 1 false TAG somewhere ? This is what lot's of users of MBID without managing them will have problem with I'm sure.

Not crazy no, but what you demonstrated is a general issue about poor tagging and MBID, nothing specific to "unknown" artist. I don't know what we do if users have altered the ARTIST tag and left a non matching MBID. They will get a mess in the library for sure. Do you have a general fix we can apply to all artists and MBID?

Please note my questions are genuine questions not rhetorical. All those "?" in previous posts are things I would like replies about (from anyone).

Quote:About VA this is complicated because Wiki says to TAG Various Artist, but yes since the data is different, API should show this difference.

So you think that the API should expose which albums have album artist = VA because they have songs tagged with ALBUMARTIST/TPE2 = "Various Artists" (in whatever language), separately from those that Kodi has determined has album artist = VA because the songs have different artist tags. I disagree (of course)

The data is not different, it is derrived differently, and the way the data was derrived is not currently stored by Kodi because it has no use for it. I can see the API should expose the data it stores, but not why it should collect additional data just for the API consumers. I guess if there was a pressing use, is there one?

Quote: An API is user desire agnostic, an API should return the data, then it's API consumer job to use the data in a way that fit user needs.

I agree. API should expose all the data that Kodi stores. I would also say it should do so in as helpful a way as it can, which means that API consumers may come up with changes they need e.g. returning a union of all genres of all the songs by an artist with the artist data rather than have to query every song. Not sure what the issue here is?

Quote:But I certainly do not agree that the API should be limited by the majority of the need for in fine no valid reason.

The only limit I can see has come up is questioning if Kodi should store how some data is derrived, even if it doesn't need or use that, just for the API. Even there I am open minded if there is a valid reason.

Just like Kodi has no need to separate VA because in tags from VA by processing, Kodi has no need to separate "unknown" in tags from missing tags. The API gets to know everything Kodi stores. But Kodi does not store how that data is derrived, so the API doesn't know that.

I think you are looking in the wrong place for API limits. It is limited to only sort criteria that are available in Kodi UI rather than every data field. It can not filter artists, albums or songs on MBID or combinations of id fields e.g. albums by genreid and artistid. Those are limits I would seek to remove.

Nothing in my WIP limited the API, or hid anything.

Finally I can only repeat that work on this is futile if the only other person interested in it fundamentally disagrees on both requirements and implementation. But after our verbose posts I doubt that anyone else is going to look at this.

I'm sure anyone actually reading all the above posts would just conclude we deserve each other

I did gave you 2 times 2 real use case of separation you never took time to quote and answer to them

1) You want user to fix their tags so that Kodi is fully used, so having a way to query properly songs without artist TAG is one (Querying on songs with unknown artist + filter on displayArtist is an hack and ugly for an API), specially since we first need to implement a way to identify this unknown artist first.

2) User may want to hide / translate or handle correctly / differently this new unknown artist, current WIP needs to get MBID to identify them. One solution would be to use your role thing and have a special role "missing". But those needs to be identifiable at artist level. Having another command to get a special id to then match is IMO not a good approach in a global vision for API, what for next case and the next ....

You say your API does not hide or limit, IMO it hide this new unknown user in the middle of all artists and limit possibilities to filter them out efficiently.

About MBID, the fact that users TAGs are wrong will always cause problem, but for this specific case you add an unknown artist that may already exist. So the name is not changed. Then all untagged songs / albums are now related to this artist. IMO if there's at least 2 ways, both ugly : rename the artist unknown to unknown since this you want to push MBID so this will force user to fix the wrong tag without adding wrong data. Or stop the update and put a big message in the middle of the screen.


This is right and wrong, the API does not allow the filtering but does give all necessary information for API consumer to do that if they want even if it's highly inefficient. There's nothing hidden, all those genreid artistsid and MBID are exposed.
MBID are exposed without usage other than linking artist during scrape no ? So why expose that since it's more or less currently a pure internal data. It's the same for unknown TAG vs missing TAG.

Kodi have this data and it can have purpose it should be exposed.

Edit :

(2016-02-18, 19:01)DaveBlake Wrote: [ -> ]I'm sure anyone actually reading all the above posts would just conclude we deserve each other

Well maybe but since JSON limitation and API are something I do care about to allow tons of things with Kodi I will of course try to defend my point of view
I and my users have tons of ideas for things that can be done around Kodi with a full proper API, and currently some are not possible, but one day maybe.

About why I do not code myself, well I did try, but there's tons of message from me here about why it's not possible for external coders to work without organization change.

(2016-02-18, 19:04)Tolriq Wrote: [ -> ]I did gave you 2 times 2 real use case of separation you never took time to quote and answer to them

Not sure I saw a question or anything new to reply to that I hadn't already said. Let's see...

Quote:As examples I can talk about the fact that the API should not be limited to what is set in Kodi settings, it would be a total non sense if the Kodi API offers no way to get compilation artist because the user have hidden them in Kodi. Or to not offer sorting different that the one the user have chosen in Kodi.

Yes.

Quote:This is the exact same, the data is different there's no logical reason to hide this fact from the API point of view, but the fact that the API does not hide it, does not force the API consumer (Kodi for example) to hide it.

No, not at all. In my WIP even Kodi does not know the difference between "unknown" artist and all others, it does not need to and there is no logical reason to store it. It just takes missing/blank artist name to be an alias of "unknown" artist, that is the simplicity of it.

Quote:1) You want user to fix their tags so that Kodi is fully used, so having a way to query properly songs without artist TAG is one

If users tag music properly then they will get the best Kodi experience, and so yes I want that for them. But Kodi is not a tagging tool, and the UI does not lend itself to reporting tag issues. Kodi can detect issues when scanning into library, but how does it tell the user? The debug log is transient and optional, restart after scan and it is gone. Scanning is a background task so dialog boxes not helpful either. I am beginning to think that a separate tag diagnostic tool would be more useful - check your files before loading and edit tags etc. Meanwhile we make Kodi as robust and flexible to poor tagging as possible.

I just don't see user tag fixing as a good reason for Kodi to go to elaborate efforts to separate the songs with missing artist tags from the other unknowns. Most users just want Kodi to browse and play their music (coping with their bad tagging). That is my view, and nothing you have said so far has been convincing otherwise.

Quote:2) User may want to hide / translate or handle correctly / differently this new unknown artist, current WIP needs to get MBID to identify them. One solution would be to use your role thing and have a special role "missing". But those needs to be identifiable at artist level. Having another command to get a special id to then match is IMO not a good approach in a global vision for API, what for next case and the next ....

Creative thinking, but I don't think applying the role concept in that way is a good idea. Role is "the way that an artist contributed to a recording", e.g. compose, play solo, mix, conduct, write the lyrics etc., they don't contribute by being missing.

One, and only one, artist will be the "unknown" artist. Kodi doesn't need to know or store which of all the artists that is, but you say that the API does need to expose it at artist level. I can think of a number of ways that could be done, a direct call does seem the easiest - give me the artistid. Another would be for GetArtists to return a flag for every artist, and it would be true for one out of them all. That seems less useful, have to get all to find one. Another way would be to have yet another non-rule filter parameter in GetArtists. Any of those suit?

Quote:You say your API does not hide or limit, IMO it hide this new unknown user in the middle of all artists and limit possibilities to filter them out efficiently.

My WIP had simply not got as far as looking to extend the API. API users could continue to do everything that they had before. I have learnt that attempting to add core facilities and update API at the same time was a bad idea, so core changes first, API to follow.

Quote:About MBID, the fact that users TAGs are wrong will always cause problem, but for this specific case you add an unknown artist that may already exist. So the name is not changed. Then all untagged songs / albums are now related to this artist. IMO if there's at least 2 ways, both ugly : rename the artist unknown to unknown since this you want to push MBID so this will force user to fix the wrong tag without adding wrong data. Or stop the update and put a big message in the middle of the screen.

Thanks for the first idea - taking measures on update of db version would work. Bad tagging can still screw things up later, but that will always be true while library is tag derrived.

Quote:About why I do not code myself, well I did try, but there's tons of message from me here about why it's not possible for external coders to work without organization change.

Yes I have read all that, and all the same here I am trying. Unfortunately I still do not see a way forward with this particular work.

Shame is that anyone seeing this thread will just think their time is better spent elsewhere. There are improvements to be made and worthwhile design ideas discussed, but it is lost in our excessive words.

Hmmm, I see two very similar issues, regarding TAG's. First the "Unknown" TAG, and then an "Artist" TAG which is blank.

So the solution, is NOT to name an "Artist" TAG which is blank to "Unknown", but to name it "No Artist" or "Blank Artist". This way, someone looking through their Music library in Kodi, will see this, and perhaps (if they care), to go back and Re-Tag this errant Music.

Since there is an "Unknown" TAG in MusicBrainz tagging, I don't think it wise to impose this on any Music you may add to Kodi without an "Artist" field in the TAG's.

Oh, and if there is a discussion on "Various Artists" I would love to read those posts, as I have a ton of compilations (Billboard Top 100, Top 40, Dance Hits, etc), that I would love to have tagged correctly. However, MusicBrainz has some of these types of compilations, but they aren't the same (usually refers to a CD with just some songs, instead of the full list of 100 that I have).

So for example:

I have the Billboard Top 100 for 1993 (all 100 songs), but in MusicBrainz, they only have a CD listing with just 10 Songs (https://musicbrainz.org/search?method=in...ease_group). They Do list it as "Various Artists", but Tagging all 100 songs with the MusicBrainz data wouldn't look correct in Kodi.

Quote:No, not at all. In my WIP even Kodi does not know the difference between "unknown" artist and all others, it does not need to and there is no logical reason to store it. It just takes missing/blank artist name to be an alias of "unknown" artist, that is the simplicity of it.

This is exactly what I think is wrong approach and what I try to explain since the beginning. This start to look like "a mute speaking to a deaf" The data is different, and a big thanks to @Powerhouse for confirming I'm not mad and there's a real useful need for the separation.

Let's hope other people comes here and explain better than me since I talk too much why this is important to not hide the TAG problem, there's enough possible TAG problem to not add more.