[scott967]

I think cdart.png was the naming used by cdART Manager, but AB prefers discart.png to be consistent with what AD was doing for movies.  At least that's how AB put it into my library from local discart.png files.

scott s.
.

[Dumyat]

@DaveBlake
No, in that case I don't think I have any collaboration albums, certainly in the way you have described. Yeah, probably tagging in the way that I have previously used for guest artists is maybe not good practice or etiquette, so will revisit those particular artists and make some changes.

Yes, I have tried manually selecting Cdart from the info dialog, but still does not display anything. I also changed the code and tried using $INFO[Player.Art(discart)] as suggested by @scott967, but still nothing. I was about to give up and put on my list of things to fix, but I took a look at Guilouz's Estuary skin Mod, where he has a download button for AB on his info dialog. So added this functionality to my own skin, along with the variable he uses and I can now get Cdart appearing.
However, this does not work in the way I thought it would. If I manually select Cdart from the info dialog after making these changes, still nothing shows, but if I manually select the Cdart from the info dialog, then select the AB download button, it does appear. I probably need to look at it a bit more, as getting Cdart to work using this method with hundreds of albums would be quite a lengthy process I would imagine.
Thanks

[DaveBlake]

...so will revisit those particular artists and make some changes.

Good

Yes, I have tried manually selecting Cdart from the info dialog, but still does not display anything. I also changed the code and tried using $INFO[Player.Art(discart)] as suggested by @scott967, but still nothing. I was about to give up and put on my list of things to fix, but I took a look at Guilouz's Estuary skin Mod, where he has a download button for AB on his info dialog. So added this functionality to my own skin, along with the variable he uses and I can now get Cdart appearing.
However, this does not work in the way I thought it would. If I manually select Cdart from the info dialog after making these changes, still nothing shows, but if I manually select the Cdart from the info dialog, then select the AB download button, it does appear. I probably need to look at it a bit more, as getting Cdart to work using this method with hundreds of albums would be quite a lengthy process I would imagine.

I think you need some help on using AB, sorry I can't help there.

Meanwhile there should be a manual approach that works. I'm not saying that is the solution for hundreds of albums, but I would like to get you to that point just for my own satisfaction.

Which "info dialog" - song or album - did you use to manually select Cdart? In the skin $INFO[Player.Art(discart)] or $INFO[Player.Art(Cdart)] is looking at the art of the song for an art type of "discart" or "Cdart" respectively. Try $INFO[Player.Art(album.cdart)], where via the album info dialog you have an art type for albums called "cdart" and have manually selected an image.

I hope to be able to add the core facility to automatically pick up local art (in an appropriate place and with a sensible name) for any type of art. So maybe just wait a bit.

[Dumyat]

Hi Dave,
Using $INFO[Player.Art(album.cdart)] did not do anything, but I tried using $INFO[Player.Art(album.discart) and that works when choosing artwork from the info dialog.....Hooray! 

I've checked my artwork settings for music in AB and I have discart enabled, so not sure why it's not downloading discart.png's when I select the option to add missing artwork from all music (new, old and all in between). In fact, it would seem I'm not getting other music artwork types downloading either (artist banner, clearart and landscape). 
Hmmm, must be another setting I'm not seeing or activated. I'll take another look and see what I'm missing....
Thanks again

[rmrector]

With the Artwork Beef documentation I do suggest that album artwork also be stored in the artist information folder, but it should be able to find most artwork mixed with the music files as well. It only finds artist artwork from here, though. Many of the reasons for putting artist information and artwork in a separate place also apply to albums (and movie sets and every other media type to some extent), and I initially thought Kodi would load album info from here since it let me export album info along with artist info.

The artwork types that I have been using for artwork added from web services in Artwork Beef are mostly inherited from the video library (as it is stored in the Kodi database and skins and JSON-RPC access it).

artists: thumb, fanart, banner, clearlogo, clearart, landscape
albums: thumb (album cover), discart, back, spine
songs: thumb (single cover)

[DaveBlake]

With the Artwork Beef documentation I do suggest that album artwork also be stored in the artist information folder,
...and I initially thought Kodi would load album info from here since it let me export album info along with artist info.

@rmrector thanks for sharing what AB does (and why).
Yes export will put artist and album stuff together, mostly for those that want to test it out without dumping a pile of stuff into their music folder and avoiding overwriting existing NFO and art. I have had debates elsewhere about the naming used by this feature, and how to make using it more obvious to the user. Still to be resolved.

But it was never my plan to move the issues with having a unique artist folder cotaining all the albums by an artist from music to elsewhere. As I see it while there are good reasons for having not having all music under an artist folder, while having a folder per album is reasonable. Do users really want a completely separate structure for all art and NFOs?

I guess Kodi could look in the Artist Info Folder for album stuff too, rather than in the music files, but at the moment as you noted it does not. It only looks for album art in with the music.
 

The artwork types that I have been using for artwork added from web services in Artwork Beef are mostly inherited from the video library (as it is stored in the Kodi database and skins and JSON-RPC access it).

artists: thumb, fanart, banner, clearlogo, clearart, landscape
albums: thumb (album cover), discart, back, spine
songs: thumb (single cover)

 What does it do with disc sets?
I recently added/corrected core Kodi to fetch thumbs per subfolder within the album folder. That adds "thumb1", "thumb2" etc. to the album art for each (disc) subfolder. That make sense?

Now looking at fetching any other art type for boxed disc sets e.g. the (round) disc art images that I guess are most common. But it could be anything, such as art from the case inserts and sleves - whatever people want to have and can persuade skinners to add to the skin. Core does not need to know, just make it configurable.

My thought is to again make that album art, named <type><disc number>, so for example "discart1", "discart2" etc. Is that reasonable?

I want to support configurable art types, but keep it simple by having the filename always match the type. That means picking a name for the cd/disc art (round image), and users and skins sticking to it. Kodi won't care which, it will just need to be told.

[Sorry for thread hijack]

[gibxxi]

Just want to add my take here...

I'm quite happy with the way cdART Manager handles music artwork. It places the folder.jpg and cdart.png WITH the music. Since these two items relate directly to the "album" itself, I don't consider that an unwanted method and/or clutter. As for everything else (fanart, logos, etc.) which are NOT directly related to the album itself, cdART Manager places those files in the folder set by the end user (Path to music library), which despite the setting name, can be any folder, in any location accessible by Kodi. The music folders are then clean of anything not relating exactly to that release, and that's how I'd like to see AB continue to work.

TBH I don't see a need to "conform" to what the video library does, since the way that library is handled and scraped already differs significantly from that of the music library anyway. Also, it'd be nice for add-ons to recognize what previous addons have done and remain consistent to that instead, and that's not just with respect to AB, but also SHS and AS too. re-inventing the wheel only leads to more confusion (and more support posts in the forum) on the part of the end user IMHO.

[DaveBlake]

Your thoughts are welcome @gibxxi

The changes to core Kodi I have implemented and am currently finishing off (please let me leave art soon) look for local art to be in the locations you describe, and will fetch it automatically as part of scanning. Users will still need something to source that art, and put it in those folders, and skin changes to make it appear on the screen, but core Kodi will do more.
 

TBH I don't see a need to "conform" to what the video library does, since the way that library is handled and scraped already differs significantly from that of the music library anyway.

Yes music is different to video, and I will do my utmost to ensure that any silly attempts to reduce functionality just to make them comform will be blocked. However I am also enthusiastic for any good features lacking in one to be extended to the other wherever possible. The motivation for the music art improvements came from the fact video could do more (but since has exceeded it - I just got carried away!).
 

Also, it'd be nice for add-ons to recognize what previous addons have done and remain consistent to that instead, and that's not just with respect to AB, but also SHS and AS too. re-inventing the wheel only leads to more confusion (and more support posts in the forum) on the part of the end user IMHO.

Well I can promise that the work I do on core will consider what has been done before, but it will not be limited by it. My aim will also be for Kodi to be flexible, in this case that means art types will be configurable rather than hard coded. Then it is just a matter of users, addon authors (to fetch and manage the art) and skinners to come to a consensus on naming etc. I can arbitrate if necessary, but not going to get stuck over it, Kodi can be all things to all men.

The only divergence I see so far is the question of what file name/art type name (I would like that to be same) to use for the round CD images - "discart" or "cdart"?

[Powerhouse]

The only divergence I see so far is the question of what file name/art type name (I would like that to be same) to use for the round CD images - "discart" or "cdart"? 

 CDart.png is what was used by the CDArt manager Addon. For Movies and TV Shows, it is just called disc.png (also used in Artwork Downloader as seen here https://kodi.wiki/view/Add-on:Artwork_Downloader).

Moving forward, I guess support for CDArt.png would be nice, but disc.png should be the default going forward, as it will mesh with Movies and TV Shows, and is the same used by the Artwork Downloader addon in the past (and now replaced with ArtworkBeef addon, but I am unsure what ArtworkBeef calls it).

[DaveBlake]

So to recap (in historical order?), and please correct me if I err so I can update this post:

• The defunct Artwork Downloader addon downloaded to  disc.png files and added them as "discart"
  
• CDArt  addon downloads to cdart.png files and adds them as art called "cdart"
  
• Skin helper Service downloads  cdart.png or disc.png files and adds them in a way that skins can see as  "discart" or "cdart"
  
• Artwork Beef downloads discart.jpg files and adds them as "discart"
  

I propose that image file name, without extension, matches art type case insensitively of course.
Hence cdart.png <-> "cdart", discart.jpg <-> "discart" and "disc.png" <-> "disc"

We could get into long lists of configurable mapping of name to type, in the way that thumbs are done, but what is really gained by that other than yet more complexity? <- Discuss!

For sure skins, and addons that manage the art possibly using JSON to change db entries, need to agree on a type name (and by my arguement that would drive the file name). Is that "discart"  <-> discart.jpg or discart.png etc.? No disrespect to the author of the of CDart addon intended, cdart.png <-> "cdart" makes sense. Have to say what old AD did, "disc.png" <-> "discart" is unattractive.

I suggest we pick one file name = type name for the round images of CDs, it could even be none of the above, and tell users how to bulk rename files if necessary for art they have.  Is that too shocking? It would be so much better to get the pain over with and sort it now, than muddle on.

You can all shout at me, but please remember I have done a lot for art recently, and it is a feature I hardly use myself.

[Powerhouse]

I myself, have already gone through my massive Music collection, and have CDArt.png and disc.png files (both the same file of course). The reason they are .png files, is for image transparency (something a standard jpg can't do). So I don't need to see a spinning square CD, I can have a round spinning CD with the corners made invisible.

[Dumyat]

Hi Dave,
Anything that is going to simplify and automate the process of scraping music artwork into a user's library is going to be a huge benefit to everybody. Thank-you so much for implementing this feature.
Yes, I would certainly support the idea of a single name for round images of CDs, as it gives addon creators, skinners and users clear guidelines on how this particular artwork type should be named. It would also be good to have clear guidelines on where this type of artwork should be placed as well. I personally think CD artwork should remain in the album folder along with the album cover artwork, as that seems the most logical place for them to be. Other music artwork (Artist thumb, fanart, banner, logo) all seem to relate directly to the artist name, so should probably be placed in the artist info folder, as suggested previously above.
Cheers

[rmrector]

@DaveBlake Some users do want to be able to keep NFO and images in a separate folder structure for all media types. I do, and I've gotten a couple of requests to implement it in Artwork Beef. It can be kind of awkward to match up exactly right (is that a 'minus-hypen' or a 'hypen' character in the artist name?), but I do dislike having all the artwork mixed in with the media so I've been playing with the idea. With provisions for artist info built into Kodi, it seemed like it might be useful to expand it to other media types (in the video library, movie sets also don't have any clearly obvious place for their extra info to live). Just an idea, though.

Artwork Beef does the same thing with disc set artwork, attaching it to the album with a disc number. This does make sense to me, but it can be awkward for skins to access them. $INFO blocks can't be nested inside each other, so the simple solution like $INFO[ListItem.Art(album.discart$INFO[ListItem.DiscNumber])] doesn't work. The best solution I've come up with is at the bottom of this page of the Artwork Beef docs. I also like this strategy because artwork files saved in the main album folder with names like "discart1.png" will also be assigned as expected (edit: err, or could be, if it makes it through the advancedsettings config). The other solution that attached them to each song was easier for skins to use, but a bit ookier data-wise. Ideally we would have discs as a separate media type that artwork can be assigned to, but that's a whole other project already on your radar so just mentioning to cover all the bases.

I definitely agree that filenames should just always match the name assigned in the library (except 'folder.jpg' to 'thumb' which is used in many other applications outside of Kodi). AD was originally designed in the pre-history before extended artwork was supported in the video library (implemented in Frodo, released stable 5 years ago), and the file name is its old convention that it never fully phased out, while the library name that skins use is its newer convention. This means that when/if this feature makes it into the video library, the one and only name that will end up where skins expect it is "discart.png" (or other file extension that Kodi recognizes as art).

I also agree that bulk rename is the way to go for true consistency going forward, rather than satisfying users of one of the several bolt-on options currently in use. As far as the round image name goes, I prefer 'discart' and 'discart.png' over 'cdart' as cdart can easily be a bit of a misnomer - music is also distributed on other discs like SACD, DVD, Blu-ray, and vinyl that could be used here. 'discart' is nicely ambiguous but still says "Hey, I can spin!".

[Mr. V]

@DaveBlake @rmrector  

Regarding separate folder for artwork.

Thought i would share how i have my music artwork setup.

watch gallery

watch gallery

My preference is to keep all the Music artwork in a separate folder., so it would be great if there was an option for this.
If this is not done i end up with extra folders for Song and Album Artists with my mp3's. Same applies for skin helper service when playing spotify or internet radio. The script will create new folders and fetch artwork for what is playing(if the skin supports it). It is not so nice navigating the folder structure of my mp3's if i have 100's of extra folders that don't contain any music.

[Powerhouse]

While I have all the artwork stored with my Music, I can see the Main benefit of having the Artwork in a separate location (and have seen several posts over the years that support this).

1. To keep my Music folders clean of junk, and just pure music. Makes sense, as many people use other devices to play music to, and having all that extra artwork is pointless (and takes up space, that a thumb drive might not have available - for example taking music on said thumb drive, in a car).

2. Having external artwork, I  believe, would help with Hard Drives spinning up when browsing through Kodi looking for something to play. So if you have your files located on a NAS, yet the artwork was stored on the local device (taking up way less room than the Music), allows devices like the Shield TV, or Fire Stick to have local access to the artwork (both devices have low internal storage), while not having the hard drives on the NAS spin up until something is actually played. Nice to save some wear and tear on your NAS and save a little more electricity.

3. Perhaps having external artwork for Music would also benefit Music Videos, so they could use the same artwork as Music does (this might be just a dream of mine).