[scott967]

Scott that is not a feature I have ever used, so my lack of awareness may have led to undesireable results (accident as opposite of design). In fact if I had known about it the *item functionality could even have been useful when debugging random art issues to see what Kodi thought was the folder for an artist. The voyage of Kodi discovery never ends!

EDIT: Had some trouble reproducing, it seems to behave like v17... Then I found that the behaviour you report happens only when no local art was in the folder during scanning. If there is a folder.jpg then you still get a *item when browsing.

It could be unique to my situation, don't know how universal it is.  Firstly, it is very rare that scrapers find art for my artists.  BITD, the Last.FM scraper was about the best, until Last.FM pulled artwork from their query API.

My organization typically uses string <artist> as song artist and <artist> / <artist-alias> as song album artist tags, files within artist;artist-alias folders and album subfolders.  The album thumb is in each album subfolder as folder.jpg, and the artist thumb and fanart are in the artist folder as folder.jpg and fanart.jpg.  When scanning albums with new album artists, Kodi always finds the artist art and assigns it to the first of the two album artists.  After scanning is completed I manually enter the music/artist node to assign the existing local art to the artist-alias via the musicinfo dialog.  For the unassigned album artist, Kodi always finds the correct source folder (with my organization) and "pre-selects" the art file as "Local thumb" or "Local fanart".

My second case is when there are actually two (or more) different album artists.  It might be my bastardization where I don't like MB -- for example, MB might credit "artist and his orchestra" as a single artist with MBID, but I will use album artists facility to add both "artist" and "artist and his orchestra".  In this instance I have both "folder.jpg" and "aritst and his orchestra-poster.jpg" in the parent album artist folder.  In this case "*Item folder" takes me to the right place to gt the local art for the second album artist.

But this just works for album artists.  Does nothing for song or contributing artists.

If it were possible that using a local artist info folder source tree "browse" could  find the folder that matches the current item artist as the first option that would I think pretty much do the same thing as the current art finding process for album artists (with the obvious benefit for song / contributors).

a) For backwards compatibility do we provide a way to get to the folder Kodi v17 and below would have taken as the artist folder (the folder above all the folders containing music by that album artist)? It will still pick up art from there if such a folder is unique for the album artist, but prefers art from the approriate folder within the Artist Info Folder if it exists.
b) Do we provide a quick route to the approriate folder within the Artist Info Folder?

Perhaps both, or maybe b) with fall back to a)?
I find that *item in v17 only goes somewhere useful for album artists, when on song artists (no album) or other contributing artists (producers, lyricist etc.) it just opens on my root directory.

If user settings has set artist info folder, then (b), if empty then (a).   Selecting of remote art would be unchanged.

My focus so far has been that the art initially comes for online scraping. So one approach: fetch art from online sources (using scraper or other addons such as cdArt or Skin Helper Service); save to Artist Info Folder via export to separate files in library folder. Not the art is there in the Artist Info Folder, and should you do a clean install then scraping (not just scan of tags which does pick up art next to the music files) will pick it up.

For art found manually if you create a folder in the Artist Info Folder with the artist name Kodi will use, and put art in there, then scraping using "Query Info for all" with that artist present in the node (so you could be looking at producers and have art for them) will pick up that art. The nice thing is that is can be automated, you don't have to visit every artist and look at Artist Info dialogand pick art by hand etc. The hard thing is putting the art in the correctly named folder. Then again if in doubt export unscraped artists to separate files, and  folders will be created for every artist that you can then manually populate with the art files.

What may catch people out is that pick up of art from Artist Info Folder is part of the scraping process, not the tag scanning one. The reason is technical, as I described in my brain fart a couple of posts above https://forum.kodi.tv/showthread.php?tid...pid2655747. I hope that users can get used to their local art being collected by scraping rather than the scanning phase. But the up side is that they can have automated art for any artist, not just album artists with limits.

Getting art during the scrape phase (except embedded album art?) makes sense.  Normally on my production Kodi my album scrape finds all the album.nfo  and I don't go on-line for it.  I don't bother with artists due to the current artist.nfo limitations, and just do a library import to get them.  But I guess that won't get any art in the new method?  But I just moved the MyMusic60.db from my production Kodi into the tester and let it build MyMusic67.db then did an export to export folder of artists and art so now I have no reason to import the artists, I can just scrape that export folder?

scott s.
.