• 1
  • 5
  • 6
  • 7
  • 8(current)
  • 9
Export/Import and local artist art improvements
Hate to chime in here and sidetrack your current focus, but I just thought that, IMHO, it would be nice in the end (via nfo's???) for the scrapping of artwork to have "exclude capabilities" for specific images that we know we don't want.

Pkscout's Artist Slideshow add-on supposedly at one point successfully used exclusion.nfo files in order to keep unwanted images from being shown, but apparently that feature isn't working anymore:
https://forum.kodi.tv/showthread.php?tid...pid2635246

Just thought keeping them from getting downloaded in the first place might be nice. ;-)
Pardon the interruption, carry on.
Reply
(2017-10-17, 15:32)DaveBlake Wrote: to see what Kodi thought was the folder for an artist. The voyage of Kodi discovery never ends!
Therein lies madness. Kodi's thinking appears to be slightly psychotic. In Kodi 17, you can browse to the artist folder (using item folder), select the artist folder that you KNOW is correct, and it'll still give you Ella Fitzgerald.
I haven't noticed that things are different from different builds, things are different within the same build. For example, if I look at "Mozart" who comes up as an artist, and then manually look at "information", there's no *item folder, and there's also several options of "remote thumb" (presumably from the multiple albums? It isn't the internet "remote thumbs" because there's no internet.....) Another artist has "current thumb" (Ella Fitzgerald, who is not the correct artist) and Local Thumb, but no *item folder. (These examples both come up as "album artists", "show song and album artists" is turned off).

It might all make sense to you because you already have some insight into Kodi's "tortured mind".
Reply
Consistency between default skins(confluence and estuary) has been an issue as well, but nothing that can't be fixed with a few pull requests by a skilled Skinner.
Reply
(2017-10-17, 15:32)DaveBlake Wrote: 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).

Quote: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.

Quote: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.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
(2017-10-18, 23:14)scott967 Wrote: It could be unique to my situation, don't know how universal it is. ...
I think that it is unusual, most users seem to avoid multiple album artists if they can. If I understand it (to handle alias names for non-latin named artists) you have in effect tagged albums as if they are collaborations. Unlike the usual multiple album artist situation, because both artists are one person or band it is easy to have all the music by "both" all under one folder and only that folder. So I can see how v17 behaviour would work for you.

I can also see why what I have done in build 1013 will behave differently. I have stopped Kodi returning a folder as the "artist folder" (where art and nfo could be found) if that folder is not unique to just one artist. It is a good way to avoid the many mistakes that happen when, for whatever reason, the way the music files are organised results in the same folder being found for different artists. I am reluctant to reverse that. If I can get things working better automatically then I hope you see that as a fair trade off.

(2017-10-18, 23:14)scott967 Wrote: 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).
Yes I think that is a good way forwards.

(2017-10-18, 23:14)scott967 Wrote:
DaveBlake Wrote: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.
For selection of remote art to be unchanged, when the path found by a) is not unique to one artist you would still like it offered when browsing for art. I am wondering if this could be modified in some way to avoid dropping you in root the way v17 does.

(2017-10-18, 23:14)scott967 Wrote: 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.  
Good. Yes embedded album art still gets found during tag scan phase when files are being processed.

(2017-10-18, 23:14)scott967 Wrote: 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?  
Actually yes it should. Moreover where you used to have to still manually visit each artist after import to "activate" the art, it now it should be fully set just as the current art by import. Please test that out.

(2017-10-18, 23:14)scott967 Wrote: 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?
Yes.
Reply
I still need to digest your reply, but in the mean time I tried out my workflow for adding new music in the test build.  Using the artist info folder tree worked out very well (better than expected).  I have to do some work migrating my local art since I effectively need duplicates of everything for the aliased album artists.  I found that the exported art is not identical to the original jpegs (even if the dimensions are identical) so it isn't as easy as just exporting all the artist art (since I don't really want a derivative art).

I also found a couple bugged artist tags by looking at the exported artist info tree.

What I really like is exporting contributors makes it easy to work on these.  Prior to this I pretty much ignored the contributors as "too hard".

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
Scott you are unusual in wanting the 2nd album artist to have the same art as the first, generally such allocation is a bug. Maybe we get alias names impemented properly evetually eh?

(2017-10-20, 10:25)scott967 Wrote: I found that the exported art is not identical to the original jpegs (even if the dimensions are identical) so it isn't as easy as just exporting all the artist art (since I don't really want a derivative art).
Useful to know. I knew that there could be compression, but somehow expected a match if dimensions were the same. Perhaps change is to be expected in the manouvre into cache and back.
Reply
(2017-10-20, 10:55)DaveBlake Wrote: Scott you are unusual in wanting the 2nd album artist to have the same art as the first, generally such allocation is a bug. Maybe we get alias names impemented properly evetually eh?

(2017-10-20, 10:25)scott967 Wrote: I found that the exported art is not identical to the original jpegs (even if the dimensions are identical) so it isn't as easy as just exporting all the artist art (since I don't really want a derivative art).
Useful to know. I knew that there could be compression, but somehow expected a match if dimensions were the same. Perhaps change is to be expected in the manouvre into cache and back.

OK.  Spent a few hours playing around with the test build and my full music source.  What I find is the "artist info" folder tree is so useful, I have no reason to screw around with the "art-in-music-foiders" v17 process.  Here is what I did, and I think is good for any user with extensive local info and art.

1.  I installed 18 test build as portable (not required of course) and copied my v17.4 userdata for music (mymusic60.db, textures13.db and entire thumbnails).  Obviously just installing over 17.4 does the same thing.

2.  I set my artist info folder in settings.

3.  I exported (separate file) all contributors artist.nfo including unscraped with overwrite ON.  I did this to populate the artist info tree.

4.  With help of a couple utilities, I was able to copy all artist art from my music file library to the artist info folders, necessarily duplicating the art for the alias artists (which now have their own folders in artist info).

5.  Then export (separate files) all contributors art to artist info with overwrite OFF (this way I pick up anything I added manually or from scrape).

6.  Then deleted all the artist.nfo files from my artist info tree (mainly, so I could scrape the non-album artist contributors).  I think I could just export the "scraped" artist.nfos, but haven't tried that yet.   Then I could I think just "scrape all artists" rather than doing it one-at-a-time to pick up the contributors (mainly I have been getting conductors and orchestras this way, and in some cases soloists).  (As an aside, if you follow MB style, classical album artist should use album artists containing composer, conductor, and primary performer.  Composer is also tagged as artist and composer -- so need to watch out for name string consistency between these two.  Same with ensemble or performer/TMCL.)

7.  Export (separate files) contributor artist.nfo and art with overwrite OFF including unscraped.  The result is a fully populated artist info folder tree.  I can then search on <biography></biography> in nfo files to find any to manually add info to.

So this way I don't need to edit my db manually to set artist/album scraped dates, nor export single file except as a backup.  I just scan new music, scrape it, export the new info (deltas), and manually complete the empty artist.nfo and album.nfo and add local art as desired.  I think I can then just refresh all artists/albums to pick up my manual edits rather than doing a library import.

Also for other users, just doing scrapes and then exporting to artist info should be simple, easy, and allows integration with cdArt manager, SHS, AS, and skins.  I have tons of AS artist extrafanart and bio data that I could incorporate into the artist info.

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
Thanks for the positive feedback Scott Smile

BTW have you checked your PMs? You should also have received some emails from the team.
Reply
Note to myself and any addon dev wanting to use the same location for artist art that folder name can be retrived using JSON API Settings.GetSettingValue
Code:
{"jsonrpc":"2.0","method":"Settings.GetSettingValue", "params":{"setting":"musiclibrary.artistsfolder"},"id":1}

The folder name for specifc artists is simply the name with reserved chars removed. However it also adds mbid chars if the artist name is not unique. I think some way for addons to get this from Kodi is needed too, but not sure the best approach.
Reply
Export of album.nfo to library folders:

I have some multi-disc albums where each disc is in its own folder. It seems like in Kodi 17 album.nfo was written to the first cd folder, but in the Kodi 18 1013 test it's written to the common parent folder. Is that by design?

scott s.
.
maintainer of skin  Aeon MQ5 mods for post-Gotham Kodi releases:
Matrix see: Aeon MQ5 Mod Matrix release thread
Nexus see: Aeon MQ5 Mod Nexus release thread
Aeon MQ 5 skin and addon repo 11.1.0
Reply
(2017-10-26, 02:32)scott967 Wrote: Export of album.nfo to library folders:
I have some multi-disc albums where each disc is in its own folder.  It seems like in Kodi 17 album.nfo was written to the first cd folder, but in the Kodi 18 1013 test it's written to the common parent folder.  Is that by design?
Yes. I think that makes much more sense since it applies to the album not to the individual disc.

Not meaning to nag, but did you get my PM? I am just concerned that communication is not reaching you, no worries if it is but you don't want to respond but do let me know that.
Reply
PR12891 has now been merged so this functionality is now in the nightly builds.
Reply
So, while I haven't read every single post in this thread, from what I did read I got the impression that idiots where welcome to join in on the testing........so here I am. I've spent the last few days playing around with version 1025.

For starters, I should say that I like the look/feel/flow of the new export screens....Big improvement Dave......much less confusing in addition to better output.

Second, I have to admit that most of my "playing" has actually been fixing mistakes in tags that were only noticed while analyzing my newly exported folder structure...... most errors being caused by the Performer/Musiciancredits field. With that said, so far I only have a couple of observations:

a.) A lot of album sub folder names were appended with partial MBID's (similar to the post where Dave wrote about  artists having the same name) but this is with albums that don't have the same name and it also doesn't seem to be consistent. - My album folder under Aretha Franklin is "Aretha Franklin_918d" but my album folder under Bob Dylan is just "Bob Dylan" - no MBID appended.
b.) Not sure I can clearly describe this one, but the bottom line is that if I do multiple exports to different directories, the newly generated "trees" don't get the same number of "folder.jpg's" and fanart.jpg's...... no scanning or scraping in between exports. I'll post back if I pick up on a pattern as to when a folder gets a jpg transferred and when it doesn't.


EDIT: It appears (probably no surprise to most) that the appended folders are the result of tagging errors. My initial export generated a sub folder for Bob Marley's album "Legend" to "Legend_edfd". Checking the "album" (actually only have 2 tracks from it) with mp3tag, I found that one track did not have a MB album id while the other did. Fixed it, updated/cleaned library, and did a fresh export and the album sub folder was not appended. Then checked the next artist with an "appended folder issue" and all of it's tracks have the same Album id but I'm sure there's some kind of tag issue involved. I'll try to take note of the various causes as I go thru the affected artist.
Reply
(2017-11-02, 23:35)Bryan_W Wrote: So, while I haven't read every single post in this thread, from what I did read I got the impression that idiots where welcome to join in on the testing........so here I am. I've spent the last few days playing around with version 1025.

For starters, I should say that I like the look/feel/flow of the new export screens....Big improvement Dave......much less confusing in addition to better output.

Second, I have to admit that most of my "playing" has actually been fixing mistakes in tags that were only noticed while analyzing my newly exported folder structure...... most errors being caused by the Performer/Musiciancredits field. With that said, so far I only have a couple of observations:

a.) A lot of album sub folder names were appended with partial MBID's (similar to the post where Dave wrote about  artists having the same name) but this is with albums that don't have the same name and it also doesn't seem to be consistent. - My album folder under Aretha Franklin is "Aretha Franklin_918d" but my album folder under Bob Dylan is just "Bob Dylan" - no MBID appended.
b.) Not sure I can clearly describe this one, but the bottom line is that if I do multiple exports to different directories, the newly generated "trees" don't get the same number of "folder.jpg's" and fanart.jpg's...... no scanning or scraping in between exports. I'll post back if I pick up on a pattern as to when a folder gets a jpg transferred and when it doesn't.


EDIT: It appears (probably no surprise to most) that the appended folders are the result of tagging errors. My initial export generated a sub folder for Bob Marley's album "Legend" to "Legend_edfd". Checking the "album" (actually only have 2 tracks from it) with mp3tag, I found that one track did not have a MB album id while the other did. Fixed it, updated/cleaned library, and did a fresh export and the album sub folder was not appended. Then checked the next artist with an "appended folder issue" and all of it's tracks have the same Album id but I'm sure there's some kind of tag issue involved. I'll try to take note of the various causes as I go thru the affected artist.

Just following up..... eliminated a number of problem folders by one of the following:
1) Removed "illegal" characters (ie colons and such) from MusicBrainz modified album tags that I hadn't anticipated being turned into a folder name so I hadn't worried about it.
2) Changed disc number from 1/1 to just 1......really couldn't believe that would work, but it did on some albums.
3) Similar to #1, renamed a "music folder" which wasn't exactly what the tags said the name of the album was.....apparently location matters nowHuh

That left me with nine albums that I could not find anything wrong with in the tags or location folder names. They are all self-titled albums (as in Dire Straits/Dire Straits, Fleetwood Mac/Fleetwood Mac etc)
All I could do there was to remove the MB album id from the tags completely and then verify that the "export folders" weren't appended with something else .......they were not, so I'm calling it "good for now".

As for inconsistent exporting of folder.jpg's,  no pattern found yet but since I already have them with my music files I'm not too worried about it.
Reply
  • 1
  • 5
  • 6
  • 7
  • 8(current)
  • 9

Logout Mark Read Team Forum Stats Members Help
Export/Import and local artist art improvements0