Kodi Community Forum

Full Version: Export/Import and local artist art improvements
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9
Quote:But just need to have a way to handle the non-unique artist names, and also names that don't make acceptable folder names. MusicbrainzID is unique, but does not make a human friendly folder name.
Could you concatenate the artist and musicbrainz id?

PHP Code:
-Music
---U2704acdbb-1415-4782-b0b6-0596b8c55e46
------Album 1
---U2a3cb23fc-acd3-4ce0-8f36-1e5aa6a18432
------Album 1 

Although, what then happens if a library is not tagged with musicbrainz? Could you use an AudioDB identifier instead?

Quote:So Kodi needs to be a "good neighbour", scrape once and only repeat for new music, or fetching new/changd info.
Agree. Last week I performed a Fresh Start on my 4 year old install. The main reason was that I had just tagged my 300 odd albums with MusicBrainz Picard. It was amazingly simple to do. I ended up having to add about 40 albums to their database, which I found quite time intensive. Added lots of artwork as well.

I already had nfo and local artwork for the Video section. All I did there was perform another export to separate files, and said no to all artwork, as the artwork was already there. I didn't want it being overwritten with the inferior cached copies. I scraped into my new library... and it all just worked perfectly. All resume points, last played, play counts all were there.

Came to the music library. The scan was flawless. But I ended up with very little artwork showing as most of my albums are Various Artists. Haven't performed the online scrape yet... probably overnight tonight if I remember
(2017-08-05, 23:32)Karellen Wrote: [ -> ]
Quote:But just need to have a way to handle the non-unique artist names, and also names that don't make acceptable folder names. MusicbrainzID is unique, but does not make a human friendly folder name.
Could you concatenate the artist and musicbrainz id?
I guess that could be an option, so artist folder is either
<nominated artist additional data path>/<artist name>
or
<nominated artist additional data path>/<artist name>-<MusicbrainzArtistId>

or could have subfolders
<nominated artist additional data path>/<artist name>/<MusicbrainzArtistId>

But I do wonder if we could hit folder name length limits with a long <nominated artist additional data path> path and artists like "The Bulgarian State Radio and Television Female Vocal Choir" - although I'm pretty sure that is a unique name that would not need the mbid appended!

But the key idea is to normally have the music files elsewhere, this avoid the "collaborations issue" of having albums by artist1, albums by artist2 and an album by artist1 and artist2. Hence maybe

PHP Code:
-<nominated artist additional data path>
---
U2
----------artist.nfo
----------extrafanart(folder)
----------
banner.jpg
----------fanart.jpg
----------folder.jpg (artist thumb)
----------
logo.png
---John Williams
----------53b106e7-0cc6-42cc-ac95-ed8d30a3a98e (folder)
--------------------
extrafanart(folder)
--------------------
artist.nfo
--------------------banner.jpg
--------------------fanart.jpg
--------------------folder.jpg (artist thumb)
--------------------
logo.png
----------8b8a38a9-a290-4560-84f6-3d4466e8d791 (folder)
--------------------
extrafanart(folder)
--------------------
artist.nfo
--------------------banner.jpg
--------------------fanart.jpg
--------------------folder.jpg (artist thumb)
--------------------
logo.png 

But the <mbid> part is still not nice for the user to know which artist is which at a glance. Humans would be better with some disambiguation text e.g. "Classical guitarist", or "Film Music", or perhaps nationality or date of birth. For Kodi any appended disambiguation would need a clear separator that is never part of a name, otherwise when does the name stop and the disambiguation text start?

Quote:Although, what then happens if a library is not tagged with musicbrainz? Could you use an AudioDB identifier instead?
Kodi's ability to handle artists with the same name is based on having Musicbrainzid, and TADB contains a subset of MB data e.g. every entry in TADB has a Musicbrainz ID. So no mbid, artist name has to be unique with your collection.

And of course, if an artist name is unique within your collection (across all musicians, producers, mixers, song artists etc.) there is no need to worry about any of this.

If you want to mix art, nfo and music, using the same <artist name> folder hierarchy for all of it then that is fine too, it just won't be madatory.
Some design thinking outloud...

I think it would be nice to never have to try and determine an "artist folder" from the location of the related music files, but what about backwards compatibility?

Think of all those users with an <artist >/<album> music folder layout with (artist level) folder.jpg and artist.nfo files mixed into it. Does the artist folder name always match the artist tags of the music files below it? So I guess Kodi will have to continue to try and find artist folder that way, even if it can export separate folders and files to a nominated location (that does not conatin music files).

But I do worry about the possible mess - some users will end up with artist images and nfo in 2 places, both mixed with music and in the nominated place, and get confused what to edit. Many unable to delete/move on mass without help. Also which takes prriority?

The other design question bothering me at the moment is: when to fetch any local artist artwork?
Current implementation is a bit yuky (even the author said so in a code comment, it was never intended to stay as it is). Some art from the parent folder of the albums get picked up, right or not, during tag scanning. So some local album artist art can appear "by magic" before you scrape. I think it would be more consistent if this was part of the scraping (looking at remote sources and NFO files) phase. But is there any argument for having fetching local thumbs as part of scanning embedded tags?
Yo ho! I just realised that as part of the scanning process when music is added to the library, even when "fetch online info on update" is disabled, is to look in 3 levels of folder up from the album for a "folder.jpg" and then use the first that it finds as the (first) album artist thumb image.

This sure explains those users that have experienced the appearence of a mystery image for mutiple artists, and been unable to see where it comes form. An over enthusiastic algorithm for sure! It could find all kinds of silly images, inadvertently left in an unfortunate location.

I am suffering a little from "mission creep" here, from export/import into artist art but it is closely connected.
(2017-08-07, 19:30)DaveBlake Wrote: [ -> ]This sure explains those users that have experienced the appearence of a mystery image for mutiple artists, and been unable to see where it comes form.
So that's why everyone was Aretha Franklin..... Interesting.
That explains my Madonna picture on numerous non related artists. I used it as the Source Folder artwork. I knew where the pic was coming from, just did not understand why some artists had it inserted, while other artists just remained without artwork, and why Kodi was searching outside the folder of the artist.
How about just creating a 2nd artist folder such as

John Williams
John Williams-2

since we are only exporting importing here I can't see it's a huge issue. I have 2 Alice coopers in my collection but that's the only clash.

How does the movie export work? There are lots of movie remakes... does it use the year? If so then maybe the artist formed year could be used on any dupes only.

When I use musicbrainz to import I always choose the correct artist from their stored disambiguation.

Basically loads of ways to solve but I'm not sure it's the biggest problem, a user can always fix a few files kodi imports manually.
Agreed keep it simple for the folder names since I imagine not many people will have more than 10 artists that match exactly the name of a different artist, then put any detail such as the disambiguation from Musicbrainz into the artist.nfo file. While try to make it easy for a user to see at a glance is admirable, to me however it's done would just end up complicating folder names too much, we generate nfo's so users to use them.
I like a combination of power and simplicity Smile
I take the points made, thanks. It is no effort to manually correct the art for one of the John William's etc., or sort out the Alice Coopers. However Kodi will need to allow for name duplicates when exporting so not to overwrite one artist with the other.

Of course the issue is not NFO files. Basically if Kodi can cope with it all in one xml file, then it can deal with lots of separate files in the same way. Match the contents to what it wants to be added to by mbid or name, the file can be located anywhere.

The slightly trickier issue is artist images - what artist does "folder.jpg" belong to?

The strategy has been that if it is somewhere above an album then it is an image of the (frist) album artist, which makes some sense. But then it tried to be clever and allow for diverse folder layouts, looking where related music files were and extrapolating above that too.

It would help to switch to an artist name based approach - the art all in a <artistname> folder - as the cdArt addon already uses. Make it core Kodi behaviour, after all lots of users already think it is.

But how much backward compatibility does it need to support? If Kodi stops looking way back up the folder tree for images, some images will stop appearing - for some users that will be a good thing, but for others it will be bad (all those "happy accidents").
(2017-08-08, 19:05)DaveBlake Wrote: [ -> ]If Kodi stops looking way back up the folder tree for images, some images will stop appearing - for some users that will be a good thing, but for others it will be bad (all those "happy accidents").
I don't think that'd be a huge drama to adapt to. Don't get a picture, people get told they have to put it in the same folder. Fixed.
(2017-08-08, 19:05)DaveBlake Wrote: [ -> ]I like a combination of power and simplicity Smile
I take the points made, thanks. It is no effort to manually correct the art for one of the John William's etc., or sort out the Alice Coopers. However Kodi will need to allow for name duplicates when exporting so not to overwrite one artist with the other.

Certainly there needs to be a method to create 2 separate folders for the 2 artists, so something like docwra suggested

John Williams
John Williams-2

I don't see how anything else could work consistently? but maybe I'm missing something. Not all music has MBID's so that can't be used for a folder name, and then what happens if we chose a particular field of scraped data, for example date of birth, and we don't have that as it's missing from the online source (goes for any field from a online source that could be chosen and is not populated).
Not all music has mbids, but duplicated artist names can only happen if Kodi has mbids for both artists. So we will have an mbid, but I'm not particularly enthusiastic about using in appended to a folder name, so human unfriendly. Your point about not using some other field because it could be missing is valid.

It could be something simple to differentiate the second artist/folder from the first, but it needs to be something that is never in an artist name. Stick "-2" into a Musicbrainz artist search and you will see what I mean.

I am also wondering about using a subfolder for the 2nd artist e.g.
PHP Code:
-<nominated artist additional data path>
---
John Williams
----------extrafanart(folder)
----------
artist.nfo
----------banner.jpg
----------fanart.jpg
----------folder.jpg (artist thumb)
----------
logo.png
----------artist02  (folder)
--------------------
extrafanart(folder)
--------------------
artist.nfo
--------------------banner.jpg
--------------------fanart.jpg
--------------------folder.jpg (artist thumb)
--------------------
logo.png 
Like "extrainfo", "folder.jpg" etc. have a specific meaning in this context so does "artist<nn>"

On reloading art from these Kodi will not know which is the alternative "John Williams" needing art from artist02, but at least the right art is easy to find manually. It could look for an accompanying NFO, and check inside to match mbid, but that starts to get complicated.
Ok so if an MBID will always be there then I'd say go with this:

(2017-08-06, 08:52)DaveBlake Wrote: [ -> ]Hence maybe

PHP Code:
-<nominated artist additional data path>
---
U2
----------artist.nfo
----------extrafanart(folder)
----------
banner.jpg
----------fanart.jpg
----------folder.jpg (artist thumb)
----------
logo.png
---John Williams
----------53b106e7-0cc6-42cc-ac95-ed8d30a3a98e (folder)
--------------------
extrafanart(folder)
--------------------
artist.nfo
--------------------banner.jpg
--------------------fanart.jpg
--------------------folder.jpg (artist thumb)
--------------------
logo.png
----------8b8a38a9-a290-4560-84f6-3d4466e8d791 (folder)
--------------------
extrafanart(folder)
--------------------
artist.nfo
--------------------banner.jpg
--------------------fanart.jpg
--------------------folder.jpg (artist thumb)
--------------------
logo.png 
(2017-08-09, 02:53)bilgepump Wrote: [ -> ]
(2017-08-08, 19:05)DaveBlake Wrote: [ -> ]If Kodi stops looking way back up the folder tree for images, some images will stop appearing - for some users that will be a good thing, but for others it will be bad (all those "happy accidents").
I don't think that'd be a huge drama to adapt to. Don't get a picture, people get told they have to put it in the same folder. Fixed.
I'm going to take you as speaking for all users @bilgepump Smile
(2017-08-10, 09:35)DaveBlake Wrote: [ -> ]I'm going to take you as speaking for all users @bilgepump Smile
ooh, no, I might get beaten up behind the bike shed.... Big Grin Seriously though, when I have trouble is when something "weird" is going on and the instructions are convoluted to try to stop the "weirdness". "Put it here and it'll then show up" seems very straightforward to me.
Pages: 1 2 3 4 5 6 7 8 9