[docwra]

I think this should probably be fixed before the release final release...

Could we get "show song and album artists" disabled by default and possibly renamed?

As far as I can tell, Kodi with out of the box install has this option ON.  It effects not just display but the metadata scanner scans ALL associated artists and takes a lot longer.

Some tests:

Setup: A new install with 1 test album "50 cent - Curtis"
With the setting "show song and album artists" off:  4 seconds scan
With the setting "show song and album artists" on:  15 seconds scan

Extrapolate this to large music collections and you get much longer scan times and huge increases in the hits on the metadata sites.



Scan results with setting off:


Scan results with setting on

[DaveBlake]

Could we get "show song and album artists" disabled by default and possibly renamed?

Why renamed? That option does what it says in the desc - controls if the artist node shows just album artists or both album and song artists.

One reason to have it enabled by default is that it makes any poor tagging much more obvious (you get mbids as names, or "A feat. B" as an individual artist etc.). I live in hope this could encourage at least some users to improive their tagging, and thus their entire music library experience

It also shows the user more of what Kodi has, actually it has even more with musicians, engineers etc. all hidden away in other nodes.
 

As far as I can tell, Kodi with out of the box install has this option ON.  It effects not just display but the metadata scanner scans ALL associated artists and takes a lot longer.

Yes default for a clean install has this enabled. It only effects the scraping, and of course requesting online info for more artists takes longer. But by default the "fetch additional data on lib update" setting is disabled, so by default scraping does not happen during scan. So the slowness you observe is a combination of having both options enabled.

Anyway why is that an issue? It is a background task, and scraping phase only ahppens once the scanning is complete and hence the library populated with artists and albums and usable. OK so pretty art and extra info will arrive a bit later, but it does not stop the lib being used.

EDIT: the request I was expecting under this title was for "fetch additional data on lib update"  to be enabled by default - making the pretty images appear by magic. Many of the old issues that stopped us doing this have now been fixed, but scraping anything (even limited to album artists) will makie that initial scan (+scrape) process run for longer. What is your view?

[docwra]

Hmm interesting... I hadn't thought about the 2nd option "fetch additional artist information" and how it obviously effects the show album artists option. So in summary, this option is not enabled "out of the box" so I don't need to worry too much

This came to my attention because I was testing artist artwork and seemed that it took a long time to scrape and had many additional artists that I was not expecting it to see as default. At the time I only wanted to see "50 Cent" in my library on a new install.

The reason I asked for it to be renamed is because it effects scraping, not just the data displayed in Kodi. Something like "Scan and Show Multiple Album Artists" may be better? @jjd-uk what do you think?

I totally understand your point of view and have no strong feelings about it, but in my humble opinion I think that quicker defaults are best. I can already imagine the user questions of "Why are there so many artists in my DB suddenly" after Leia upgrade.

The idea that users may fix their library if they see all these extra artists is certainly a hopeful one haha. I doubt most people even tag, they just download from anywhere and hope for the best

[jjd-uk]

Working late tonight so not 100% sure, but think that may have been disabled by default at some point in the past. I seem to remember a conversation with a decision to taken to enable it in order to show all artists, rather than have the situation of people scratching there heads as to why certain artists weren't appearing.

[jjd-uk]

Although it seems peculiar to me why that setting would have anything effect on scraping?

I'd have thought we would scrape all artists in database no matter whether or not they are currently shown under the Artists node due to whatever that setting is set to Does that mean if you scrape with only the album artists under the Artists node by disabling that setting and you were to later revert to having the settings enabled you would have to rescrape to get the data for all artists Surely that should be something under the control of the scraper `

I only ever use local artwork so it's not something I've ever noticed.

[docwra]

From my tests scanning is 3 x slower with the option turned on. Hence the default option change request.

[scott967]

IIRC before scanning was refactored when a new album was discovered during a scan, it would be scraped and also its album artists (if they didn't currently exist), but now all new additions are scanned first, and then the new albums and artists scraped.

scott s.
.

[DaveBlake]

I'd have thought we would scrape all artists in database no matter whether or not they are currently shown under the Artists node due to whatever that setting is set to

Scraping extra data for artists that the user isn't looking at seems very inefficient to me. It means extra server traffic, battering the remote sites for unnecessary data is just Kodi being a bad neighbour. It will also take time, which seems to bother @docwra (although I don't know why as a background task that is an issue). And if you truely mean all artists that would include the musicians, producers etc. that most users don't look at at all.
 

Does that mean if you scrape with only the album artists under the Artists node by disabling that setting and you were to later revert to having the settings enabled you would have to rescrape to get the data for all artists

There would be gaps in artist images (and info) yes. To fill those gaps (if the user wants, and not all will) you can either use "query info for all" on a list of all or just those you want, or library update with "fetch additional info on update" enabled.
 

Surely that should be something under the control of the scraper

Absolutely not.  What artists or albums get scraped and when is under the control of the user via Kodi settings and menu options. The scraper settings should control the remote sites that are accessed - where the info and art links are requested from.

It is the scraper addons job to makes requests and format the results into something that Kodi can understand. My current thinking is that what is done with those results, how they are merged into what Kodi already has (something that needs to be more flexible), should be a Kodi setting.

[DaveBlake]

Well looking back as far as v15 "show song and album artists" was enabled by default in every version. The setting desc and title changed (to be more accurate) with v17. Yes it does indirectly impact what artists get scraped when scraping on update is enabled, but I don't think the title needs changing again because of it.

Scott is correct, when "Fetch additional info on update" is enabled scraping in v18 happens after all tag scanning is complete. Yes the more artists scraped the longer the background task takes to complete, but I don't understand why that is an issue. What matters is that the requests made to remote sites are for data that is wanted.

We have discussed replacing the default artists node with and 2 separate nodes - Album Artists and a Song Artists node. These nodes exist on the default node structure already, but hidden under the "Roles" submenu. However not sure that is what users want, but the demise of the artists node could mean having a separate option for what artists get scraped on update.

I am in two minds about enabling "Fetch additional info on update"  by default. It would make artist art appear by magic, but will also make that background task (scan + scrape) take longer than just scanning tags does. If the latter is bad, as @docwra  implies but I don't understand, then maybe the price for art by magic is too high?

[jjd-uk]

There are two separate process, what data gets into the DB and then display of the data from the DB.

The scraper controls what goes into the DB so to me seems the most logical place for deciding whether to scrape only Album artists or all Song artists. Then that setting would be a simply toggle governing display of the data.

Anyway no big deal, just personally it's not logical to me.

[docwra]

In my opinion 99% of users will "expect" to lookup only main artist information (not album artists). As we now regularly recommend using musicbrainz picard, a lot more users will presumably have this info in their tags and therefore the lookup process will be a lot longer for them.

My minor concern (as this is not a default 'out of the box' option, so has far less impact) is that if any user decides to set the download metadata "fetch additional info on update", they will automatically get album artists info, unless they specifically disable that option. During testing recently, this confused me, so I can only imagine what a new users thinks when they see 10,000 artists instead of 2,000 that they expected in their library, many with missing images and data.

2 different nodes would definitely be an improvement, as would features to browse large lists by first letter (A-Z) or split screen jukebox style views, but we don't really have any of those yet.

Certainly this is the way I use Kodi music, but I guess everyone is different My overriding view is that speedy defaults and simplicity should always trump advanced features, but this is of course just my opinion.

NOTE: I don't want to go off topic too much, but enabling "fetch additional info on update" by default is a no go, due to the huge effect this would have on the metadata sites sadly. As an example, TADB already gets 15 million hits a week from about 50,000 users. And that's with the option to use it disabled by default in Kodi! I'd love to see it one day though

[DaveBlake]

In my opinion 99% of users will "expect" to lookup only main artist information (not album artists). As we now regularly recommend using musicbrainz picard, a lot more users will presumably have this info in their tags and therefore the lookup process will be a lot longer for them.

Album artists are the main artists
Tagging with mbid tags (using Picard or Mp3tag with macro) makes scraping faster (and more accurate), without them the number of requests and hence time taken, doubles.

What you say here makes no sense to me.
 

My minor concern (as this is not a default 'out of the box' option, so has far less impact) is that if any user decides to set the download metadata "fetch additional info on update", they will automatically get album artists info, unless they specifically disable that option. During testing recently, this confused me, so I can only imagine what a new users thinks when they see 10,000 artists instead of 2,000 that they expected in their library, many with missing images and data.

When "fetch additional info on update" is enabled then on lib update Kodi attempts to ensure that the artists shown on the default artists node all have art. If the artists node is set to show just album artists then that is the only artists scraped. If "show song and album artists" is enabled, and therefore more artists are shown in the artists node, then more artists are scraped.

What users would find confusing is to have song and album artists listed in the artists node, but Kodi always leaving some (the song artists) without art and info.
 

NOTE: I don't want to go off topic too much, but enabling "fetch additional info on update" by default is a no go, due to the huge effect this would have on the metadata sites sadly. As an example, TADB already gets 15 million hits a week from about 50,000 users. And that's with the option to use it disabled by default in Kodi! I'd love to see it one day though

Yes, I am well aware of the remote sites as a precious resource that we need to treat well and avoid abusing. One reason I have put effort into getting export and local art facilities improved is to take some of the unneccessry rescraping load away. Impact on these sites is certainly an issue to consider when setting the default behaviour.

What I think you are saying @docwra  is that enabling both "show song and album artists" and "fetch additional info on update" by default would be too hard on these resources. Would that also be true if we were scraping just album artists?

[scott967]

The only way to see the "10,000" artists, is by opening the roles > all contributors node.

In my experience, artists vs album artists isn't that different.  Mainly if you have compilation / VA albums and the odd "feat" artist.

Video has the option to set content to none and back to rescrape an entire source.  Music doesn't have that. 

scott s.
.

[docwra]

Album artists are the main artists
Tagging with mbid tags (using Picard or Mp3tag with macro) makes scraping faster (and more accurate), without them the number of requests and hence time taken, doubles.

What you say here makes no sense to me.

Yes apologies, I must get my terminology right, I am talking about song artists here and the default enabled status of that option, when the user decides to turn on extra fetching web data.

EDIT: random idea, how about calling the option "Show and Scan additional song artists"

when "fetch additional info on update" is enabled then on lib update Kodi attempts to ensure that the artists shown on the default artists node all have art. If the artists node is set to show just album artists then that is the only artists scraped. If "show song and album artists" is enabled, and therefore more artists are shown in the artists node, then more artists are scraped.

What users would find confusing is to have song and album artists listed in the artists node, but Kodi always leaving some (the song artists) without art and info.

Yep exactly, my only issue here is the lookups for all those additional song artists. It takes time, about 3 times as long in my limited tests and the majority have no artwork as the song artists are often obscure. I will try to do some more benchmarks to see if this really does make as much of a difference as I saw on a few albums. I suspect it actually doesn't, as my testing involved mostly hip-hop and electronic albums with many "feat." vocalist artists.

Yes, I am well aware of the remote sites as a precious resource that we need to treat well and avoid abusing. One reason I have put effort into getting export and local art facilities improved is to take some of the unneccessry rescraping load away. Impact on these sites is certainly an issue to consider when setting the default behaviour.I think you are saying @docwra  is that enabling both "show song and album artists" and "fetch additional info on update" by default would be too hard on these resources. Would that also be true if we were scraping just album artists? data.

Thats a separate issue, but yes I think this would indeed be too hard on resources at this point, but I encourage us all to work towards that aim, for that "out of the box" feel that other HTPC apps have. 'in my opinion, the user really shouldn't care about these options, just that it works and shows nice artwork and data for their music collections.

[DaveBlake]

Video has the option to set content to none and back to rescrape an entire source.  Music doesn't have that. 

Yes a facility to rescrape artists, or even better partially rescrape selected artists (or albums) is needed. It is not just about filling the gaps as we do now, what the remote sites hold for an artist changes all the time as the community adds art and infomation, and Kodi does not currently offer an easy way to retrieve and apply that fresh data.

Supporting bulk rescraping in a selective way will also protect the remote sites from being hit by too much traffic, something that a crude entire source approach could cause.

Such a bulk refresh also needs to be controllable at a field level, allowing users to say fetch new art but keep the bio or style values they have carefully applied. But that does move towards media management,  is that a Kodi/scraper function or should it just make it easier of other tools or addons to perfrom that task?

It has to be approached in a different way to video because music scraping is not "content" based. Video could also benefit from a more controllable approach than "every field of the entire source or nothing", but that is way off toipc!