[DaveBlake]

The problem both you guys have is that the guy doing the implementing, in this case me, needs to believe in what he implements. And I don't believe in what you now both want. So I still choose to give up.

But of course someone else can always do this for you, or maybe do it yourselves.

[Powerhouse]

I don't want you to give up, I just believe it needs to be called something other than "Unknown".

Plus by calling it something other than "Unknown" it would make it easier for people to see which TAGS they have that are messed up (so they can fix them).

[Tolriq]

The problem both you guys have is that the guy doing the implementing, in this case me, needs to believe in what he implements. And I don't believe in what you now both want. So I still choose to give up.

But of course someone else can always do this for you, or maybe do it yourselves.

Then this is masquerade and not discussion You asked what you overlooked you have answer. Sorry you do not like it, but you are asking how to manage a problem that you do not have to people that had the problem of those missing tags.

About doing it ourselves the funny part is that if I even try you just have to get to the PR and say I do not like it and have it refused I will certainly not play that game it's a lost cause since a lot of years

Anyway on a more global thinking toward helping users getting better tags (and messing with theirs automatically to hide problem is not a way I still think) I really think that in reality the solution may be just to return to joins and for users that do not find their missing songs they will have to tag them. As you said yourself this is a very rare case and you are not even impacted so I wonder why you fight for a solution that does not help users to solve this issue. (This is in the case that we assume artist tags are mandatory tag of course)

The other solution is to keep it as it, as it's how it works for other things like movies, if your movie have no genre then you won't be able to find it when browsing by genre only by the global movie view. There's no unknown or missing genre created. It's more or less the same here.

[black_eagle]

I don't want you to give up, I just believe it needs to be called something other than "Unknown".

Plus by calling it something other than "Unknown" it would make it easier for people to see which TAGS they have that are messed up (so they can fix them).

For what it's worth, I have to agree with this.

I have some tracks in my kodi library where I really cannot identify the artist, so I have intentionally tagged them as 'Unknown'. Although I believe that my library is tagged correctly, there is always a chance that the odd track has 'sneaked' in without having an artist tag. Showing such tracks under a 'missing-artist' would clearly allow users to identify such tracks and correct them, should they wish to.

[DaveBlake]

@Tolriq no marquerade here, and I would not block any PRs by you or anyone else. You are too quick to think the worst of me and it is very wearing. Pehaps I had best add that I have been unwell, so incapacitated I have not been online at all until now hence the silence, least you see that as some ploy.

@Powerhouse and @black_eagle thanking for joining our debate even if you don't agree with me. No real way to know how representative anyone's views are, all I can say it that the desire for missing artist tags to be separated from everything else was not the way I wanted to go.

I guess it comes down to how you see missing artists. If they are a mistake that the user wants to be made aware of, then I will concede that having them separated from those actualy tagged as "unknown" makes some sense. With that I presume the display of "missing artist" in all places - song and album nodes as the artist name, as well as the artists node - is desirable.

But I'm just not sure users want to fix their tags, present company excepted, many just want Kodi to magically repair any messes. I read the distress that Kodi behaving accurately but inflexibly causes users. I really just want to lead to a happy Kodi user experience.

Another view is that no artist tag could be deliberate, and that the artist has perhaps been included in the song title (silly but historically possible). In that case display of "missing artist", in all but the artists node, would just be obtrusive. That there would be people saying they left artist blank and did not want some other extra text being displayed when the song was listed or playing.

Now adding an invented artist is one thing, but having to hide is from users sometimes would be fiddly and something I wanted to avoid. Can we say no artists are mandatory, and if the artist tag is missing Kodi will show "missing artist" as if that was the name provided?

Oh yes "missing artist" could be any text, from language setting or advanced setting xml (use configurable). Written to and retrieved from the artist table to save silly juggling getting the artist name to display on the UI etc.

Then the API...
@Tolriq you have said much, and I have read it, but I still can not tell how you actually want the API to provide info on invented artists. I made a number of suggestions, but never got related feedback. If one of the artists in the database is actually an invented "missing artist", what does the API do? Even if I am not implementing it someone else might like to know.

[DaveBlake]

OK, going to raise PR, adopting the approach that "missing tag" artist is unique and separate from any other tagged artist value, and gets displayed like every other artist. I would rather do that than just leave things as they are with left joins and lost songs.

I get that API consumers may want to know which of the many artists, if any, is the invented missing tag one, but I still don't know which way is best to expose this to the API.

[Tolriq]

Hum I was persuaded to have pressed the submit button I guess I have pressed preview and forget

Too bad for long post

Resuming the discussion there's 5 ways :

- A Special MBID : IMO a bad way as it require the gathering of a big string for all artists, and it's a lot of data for big libraries + indexes + ....
- A new flag / value : As you said it's bad to add a new value for all data since it's only for 1, and I agree.
- GetUnknownArtistID : As I answered () it can work but it's an additional call that could be avoided.
- A well known ArtistID : Simple solution from API consumer, but as you said can complexify a lot the migration.
- A well known Artist name : Either empty string or something else that will be then translated at display time.


I'd have preference for well known ArtistID and Artist name as second choice. GetUnknownArtistID as a third choice, and against 1 and 2 solution.

[DaveBlake]

Perhaps loss of long post was a good thing given our predelictions

By well known artistid do you mean a kind of magic number, that id = NNNN is always the missing tag artist? Or something else?

[Tolriq]

Yes a documented magic number, but more like 1 than 35249

[DaveBlake]

A known artistid/magic number approach does present some difficulties:

- The missing tag artist only needs to exist if the library has songs with artist tag missing. Keeping a spare artistid and/or skipping that artist when it has no songs is all additional complexity I would like to avoid.

- Updating existing libraries also becomes more complicated if the chosen artistid is already in use

These could be overcome, but since it is just for a possible API consumer use I have to wonder if the complexity in core is justified rather than option 3) GetUnknownArtistID.

Would another option be a new filter parameter on GetArtists that causes just the missing tag artist to be returned, not quite the same as 2). It would mean filtering on a field value not actually returned in the results, but that is already true of the other filter parameters

[Tolriq]

Well filtering on non returned value should die in hell And I hope your WIP on music will go in that direction

Non accessible value are bad for remotes that works offline and need to sync data.

I prefer GetUnknownArtistID than a filter on get artist as for offline remotes the filter solution on non returned value is not really usable.

But maybe both are needed, for skins to easily filter out this unknown artist as I'm not sure they can easily mix 2 queries to achieve that. (That's another advantages of well known id)

About missing artist when library does not miss an artist it's like composer and conductor for roles, they might not exist but yet their are created to ensure proper future

I still think well known id is coherent with the rest and a proper solution but won't oppose to having only GetUnknownArtistID as global gain should compensate the need for this call.

But please do not wait too long if you go with GetUnknownArtistID and do not include in PR as users may want to be able to hide the unknown artist from list specially if it's named with [] as it will be first in list by default.

[DaveBlake]

Well filtering on non returned value should die in hell And I hope your WIP on music will go in that direction

It is up to @Montellese really. My WIP does attempt to return song genre in GetArtists but I have forgotton what else as it has been sitting waiting so long.

It always sounds like you want to remove all filter parameters that do match returned fields. But really surely what you want is to return more fields and derrived/denormalised data to match the filter parameters? That is "failure to return values that filters are based on should die in Hell". But since filters can be smart playlist rules, and some artist list rules are applied to song data, it can get complicated.

I prefer GetUnknownArtistID than a filter on get artist as for offline remotes the filter solution on non returned value is not really usable.

But maybe both are needed, for skins to easily filter out this unknown artist as I'm not sure they can easily mix 2 queries to achieve that. (That's another advantages of well known id)

My thinking is that if the "missing tag" artistid is not a fixed value, and you want to know it then a single call (when sync) of either a specific routine like GetUnknownArtistID, or filter GetArtists to give just the one artist would do that job. Not sure why mixing of queries would be needed?

About missing artist when library does not miss an artist it's like composer and conductor for roles, they might not exist but yet their are created to ensure proper future

Sorry I don't get what you are saying.

I still think well known id is coherent with the rest and a proper solution but won't oppose to having only GetUnknownArtistID as global gain should compensate the need for this call.

The update of existing libraries is what really makes fixed artistid hardest. It is coherent sure, and we could fix cleanup not to remove the special record etc. The query behind artist node already checks song_artist and album_artists tables so showing "[missing]" as an artist when all your songs have artist tags won't happen.

But please do not wait too long if you go with GetUnknownArtistID and do not include in PR as users may want to be able to hide the unknown artist from list specially if it's named with [] as it will be first in list by default.

I am happy to include API change in the PR if it can be agreed with mimimum fuss, I don't want it left out. But I also know how slow it can be to get approveal.

The [] pushing the artist to the top of the list is a deliberate choice, rather than is getting lost amongst the rest. The idea is to get those songs tagged better, that is why I was finally pursuaded to go this way. But if this turns into a dummy value we want to hide, not only in artists list but in song details, then it all becomes far less attractive and messy.

See if we get any input on Git. All I need is someone to tell me that no artist tag is sometimes deliberate, they don't want to see the invented artist displayed because they have it in the title, and it is back to the drawing board anyway.

[Tolriq]

It always sounds like you want to remove all filter parameters that do match returned fields. But really surely what you want is to return more fields and derrived/denormalised data to match the filter parameters? That is "failure to return values that filters are based on should die in Hell". But since filters can be smart playlist rules, and some artist list rules are applied to song data, it can get complicated.

Well there's different things Missing returned fields for basic things, like the genreid for artist, filter on things that are not the same as the returned thing, like genre for artist, and data that will always needs to be derivated.

Artist genre is a basic, the fact that internally in Kodi it's derived from songs, does not mean API consumers should need to do the same thing. (And when I see bad proposal like you can get the same data from albums it just shows how some people do not understand the impacts, since even you did expose this solution in another thread, just a simple reminder of the problem, you take an album best of 90's, with 20 songs from 20 different artist from 20 different genres, then this solutions tags all 20 artists with 20 different genre when they in real only have one, meaning 95% of bad data ....)

My thinking is that if the "missing tag" artistid is not a fixed value, and you want to know it then a single call (when sync) of either a specific routine like GetUnknownArtistID, or filter GetArtists to give just the one artist would do that job. Not sure why mixing of queries would be needed?

Well the filter was to allow skins to hide this empty artist entry easily if there's even the need. For remote api consumers this is not a problem. But for a skin I'm not sure they can call first GetUnknownArtistID then send the query with artistid is not the previously found id.

For offline remotes, having to call again getartists with a filter just to get the id, is a very bad approach of an API.

Sorry I don't get what you are saying.

I was referring to the fact that you said you do not want an empty artist present in the database if there's no empty artist in the user collection.
I just remind you that you create composer and conductor roles even if the user do not have them in their collection, it's the same.

[DaveBlake]

The artist, album, song genre conversation does not belong here, it has its own thread! From there you can discover that if I live long enough, and can have some hint of support rather than battering, I will try and extend Kodi to provide filtering of artists by artist genre as well as by song genre. Personally I would still use song genre because I tag that, rather than some value scrapped from an external database, but I support the idea of users having the choice. Then again it has not come up as a Kodi feature request that I have seen, so what priority should I give such work?

Back to matter in hand...

Is there any other reason for API consumers to know the missing tag artistid than to hide it? The desire to hide it feels a slippery slope.

I was referring to the fact that you said you do not want an empty artist present in the database if there's no empty artist in the user collection. I just remind you that you create composer and conductor roles even if the user do not have them in their collection, it's the same.

Oh yes, I did leave those like that in the end. It was something I deliberated on and ended up doing that, not essential really. Thank you for clarifying. Artist is a bit more central than role, but point taken.

From the beginning I have seen the missing artist tag issue as a low occurance aberation that we need to catch in order to avoid slower general processing. I wanted a simple implementation, no tag was no more special than having artist etc. But you have been pushing for a more complex solution, where missing artist tag is special. Ever thought of pulling instead?

If there is an outcry on Git for a fixed artistid and/or option for hiding the invented artist in Kodi UI or skins then I will rework everything.

[Tolriq]

The artist, album, song genre conversation does not belong here, it has its own thread! From there you can discover that if I live long enough, and can have some hint of support rather than battering, I will try and extend Kodi to provide filtering of artists by artist genre as well as by song genre. Personally I would still use song genre because I tag that, rather than some value scrapped from an external database, but I support the idea of users having the choice. Then again it has not come up as a Kodi feature request that I have seen, so what priority should I give such work?

You read something that I did not say I never said that there is obligation to manage scrapped artist genre.
I said that users might want that. (I have report about that)
And (the biggest point) I said that if there's a field name genre and you filter on genre it should filter on the genre field not on another hidden field song genre that you can not display.
Your WIP with songgenre (id+name) is ok as it allows remote to have all the data to be consistent (Meaning filtering and displaying on the same set of data).
This was a long discussion and maybe you forget the core of my point of view about that.

Do not see problems where there's not.

Is there any other reason for API consumers to know the missing tag artistid than to hide it? The desire to hide it feels a slippery slope.

Well the reasons are explained since day 1 (Event day -1 :p )

Proper translations independent of Kodi language, this is the main thing I find bad in this design where the translation of the field is forced in database based on Kodi current user language. (And the one I reported since even before you started working on the PR when talking about impact of adding artist, and avoiding the pitfall of VA translations)

IMO this is wrong and all the rest of the discussion are just work around that, a field where the display value change depending on the user language should not be stored as the translation in the DB.
Specially with Kodi supporting profiles with different languages and when there's access from API consumers that can be in any language.

Other use case is different sorting (putting this one at the end for my use case) the fact that you use [] does simplify this a little since it's forced at start and not hidden in the middle, but not sure all users want this one first. They need a way to access them and fix them when they have time, not a too prominent reminder that they have work to do.

And I'm sorry but hide them can be a request from some users to remain consistent with previous Kodi versions, this is not a reason to abandon this forced artist