[gibxxi]

Using Kodi 19 with the default  "Generic Music Scrapers" (Album / Artist) and having Artwork Dump enabled to sync cover artwork and disc artwork to the album folders, I was somewhat surprised to see a whole host of "discart.jpg" files in the folders with the music.

This type of artwork seems to be of wildly varying resolutions, and in all instances contains backgrounds (i.e: not transparent). Any way to customize which sources artwork is sourced from? Kodi should never be downloading discart images in anything other than .png format, and only from the fanart.tv site exclusively, because in as far as I'm aware, they are the only site that impose consistency in terms of size, quality, and transparency for submitted disc artwork. Some .png format discart has also been downloaded, but it's far from exclusive in this regard, so far as I can see.

I've also seen it download 2-disc art files (discart1.png & discart2.png) in addition to the standard discart.png, when the release I have is the single disk version (only). The tagging is correct, including MBIDs for the release I have.

To clarify, I do not have any other app downloading disc image artwork, aside from the odd one or two I have added manually, so this must be something Kodi (or the Generic Music scraper) is doing. I've deleted the discart.jpg files for the affected albums, of which there were over 300 at the last count, some of the affected albums were already in possession of the correct discart.png images anyway.

Dan / Gib.

[Uatschitchun]

Can't you see in the logs what source the artwork came from?

[jjd-uk]

You can do that using the older Universal Album Scraper



Not sure why there are no artwork options for the Genreric Scrapers, my guess is that the new artwork whitelist settings were probably thought to be enough, but maybe it wasn't taken into account the quality from the different available providers may vary so you might want to restrict to one provider only.

[gibxxi]

You can do that using the older Universal Album Scraper



Not sure why there are no artwork options for the Genreric Scrapers, my guess is that the new artwork whitelist settings were probably thought to be enough, but maybe it wasn't taken into account the quality from the different available providers may vary so you might want to restrict to one provider only.

Thanks for the tip jjd-uk. May I ask if there are plans for this functionality to be ported into the Generic scrapers, as I'm assuming at some point these will replace the universal ones? If not then i'll go back to the universal scrapers as that's what I used in prior versions of Kodi anyway.

Dan / Gib.

[DaveBlake]

AFAIK the design principles of the generic music scrapers was to fetch everything (data and art) from everywhere (it access more site than the old scraper can), and to simplify user options. I have always felt that some users need more control over what data is fetched from where (e.g to avoid a load of junk genre data being picked up from Allmusic), perhaps art also need some user control too.

Kodi artwork settings are only there to provde control over a) how local artwork is handled, and b) use of scraper results to fill gaps in artwork. What art scrapers gets and where it gets it from is up to the scraper, and so no the whitelist settings were never intended to control that.

I don't think that the artwork source settings the Universal Music Scraper has are the best approach. Mostly it avoids the art issues you have with the generic scraper just because, even with all sources enabled, it gets less art from fewer places. There is also room for user confusion by having art options in both scraper and Kodi (even though they do different things). Another, perhaps better, approach would be for the scrapers to be more deciminating of discart by default, but we would need to workout what kind of improved artwork filtering it could do.

May I ask if there are plans for this functionality to be ported into the Generic scrapers, as I'm assuming at some point these will replace the universal ones?

There are no plans for anything
The Generic scrapers have already replaced the Universal as the default scrapers, but the older ones are still availlable. If further enhancements to the core scraper design are made it could be the end of all the XML scrapers, but lack of active team members means that no one is currently working on such redesign. Changes to the API of remote sites could also impact the old scrapers. The old XML scrapers currently have a single person that valliently keeps them working, but overall they are vulnerable.

To be clear, there is no functionality in the old Universal scrapers that is per-se "missing" from the new Generic scrapers. But we do need to take onboard your experience Dan, and tune the generic scraper in some way. The good news is that addons can be updated at any point, they are not locked to the Kodi development cycle.

[gibxxi]

Understood. Thanks for the info. The naming of the new Video Library scrapers looks a bit 'disjointed' to my 'OCD-ness' tendancies, but that's nowhere near as important as the efficiency of how they actually work, and the same thing applies to music. The reason for the question, was that the words "Generic" and "Universal" have very similar meanings, so I assumed one would eventually be replaced by the other, but couldn't be sure.

Thanks for the clarification.

Dan / Gib.

[DaveBlake]

Video scraper naming has become "difficult", not sure there are any good answers, thankfully not my creative problem.

The future is certainly Python based scrapers just because they could be more versatile, and more people could work on them. The old scrapers work by parsing of XML results using regexp, and is this very much a "black art" where the remote sites can make a small change in what they return and break the scraper. Thery have been really successful, and originally there was no other way to do it, but there are other approaches now.

The intention with the Generic music scrapers was to provide Python based music scrapers that could do at least what the xml parsing Universal scrapers could do and hopefully more. Seems at the moment the art is too much more and not descriminating enough, we can look to improve that. I will talk with ronie the author and see what can be done.

Can you provide some example albums where the art work returned is particularly bad. Just the names and Musicbrainz ID would be really usedful.

The multiple discart when your release has only one disc is something that we many have to handle Kodi side. Art is looked up at fanart.tv using Musicbrainz release ID so does not take account of the disc count etc., and some people may want all the variants I guess, or maybe Kodi should be more careful over what gaps in discart get filled from the scraper results. But getting jpg rather than png, and wrong sizes etc. is something the scraper could control. Need to think about it, and some real life practical examples will help.

[gibxxi]

Video scraper naming has become "difficult", not sure there are any good answers, thankfully not my creative problem.

The future is certainly Python based scrapers just because they could be more versatile, and more people could work on them. The old scrapers work by parsing of XML results using regexp, and is this very much a "black art" where the remote sites can make a small change in what they return and break the scraper. Thery have been really successful, and originally there was no other way to do it, but there are other approaches now.

The intention with the Generic music scrapers was to provide Python based music scrapers that could do at least what the xml parsing Universal scrapers could do and hopefully more. Seems at the moment the art is too much more and not descriminating enough, we can look to improve that. I will talk with ronie the author and see what can be done.

Can you provide some example albums where the art work returned is particularly bad. Just the names and Musicbrainz ID would be really usedful.

The multiple discart when your release has only one disc is something that we many have to handle Kodi side. Art is looked up at fanart.tv using Musicbrainz release ID so does not take account of the disc count etc., and some people may want all the variants I guess, or maybe Kodi should be more careful over what gaps in discart get filled from the scraper results. But getting jpg rather than png, and wrong sizes etc. is something the scraper could control. Need to think about it, and some real life practical examples will help.

I would be more than willing to assist you in providing info over what albums were affected David, but as I said above, I blanket deleted the offending files via an Windows Explorer search of the library folders for the term "discart.jpg", so at this immediate time, I can't help you, as I can't be sure which ones were affected. I've now reinstated the "Universal" scrapers, selecting Fanart.tv as the only artwork source (currently), so i'm not expecting this to occur again. However, should it do so, i'll PM you what I find, assuming you can receive PMs?

With regards the discart.png + discart1.png, discart2.png, etc, etc. (multi-disc albums) issue: A workaround at this stage would to be remove the "discart.png" label from the advancedsettings.xml and simply use something like "discart1.png" and upwards for all albums, single disk or otherwise, is my thinking. But I'm not in the mood to mess about with it at this time. I've just got through the arduous task or migrating my library from the old way of doing things, to the new Kodi naming standard (and thus getting rid of disc sub-folders), and renaming every discart.png for multi-disc albums in the library, not to mention re-creating my failsafe backup archive in case of NAS/HDD failure, so I need a break from it for a while. It's got to a point where I spend more time tweaking it, than actually listening to it of late!



Thanks for your efforts on the Kodi Music Library functionality of late though. It's been in need of a coat of looking at for a while, so kudos to you for shouldering the task.



Dan / Gib.

EDIT: Only stumbled across this issue by accident anyhow. I was editing tags as it seems somehow, MusicBrainz Picard is seemingly writing non-standard ASCII character codes for colons, and periods to tags and file names, which then fail to display properly (empty square box characters) within Kodi / Madnox 2.0, but as I've not nailed down whether this is Picard or an installed plugin, I've not reported it at this time.

[gibxxi]

Something I just thought of, that may be relevent (but I doubt it), is that I run a custom script/command in MB-Picard to remove the "DiskID" and "TotalDiscs" ID tags from anything that isn't a multi-disk album. Having those fields seems a bit redundant, and it also helps with tagging things that were never released on "Disc" in the first place cleanly, like Radio Shows, Podcasts and Audiobooks (of which I have quite a few).

Dan / Gib.

[DaveBlake]

Yes you can email or PM me, or just post Musicbrainz ID examples on the forum.

With regards the discart.png + discart1.png, discart2.png, etc, etc. (multi-disc albums) issue: A workaround at this stage would to be remove the "discart.png" label from the advancedsettings.xml and simply use something like "discart1.png" and upwards for all albums, single disk or otherwise, is my thinking.

That isn't going to work. The art settings in advancedsettings.xml are deprecated in v19, replaced by actual settings and the whitelist works on art "families" so rather than having to enter "discart1"... "discart10" etc. you just enter "discart".

I've just got through the arduous task or migrating my library from the old way of doing things, to the new Kodi naming standard (and thus getting rid of disc sub-folders)...

Confused what the new way is compared to old? Music processing doesn't use file or folder names, and having subfolders for discs is fine. Maybe there is some confusion and I can save you a load of work?

I was editing tags as it seems somehow, MusicBrainz Picard is seemingly writing non-standard ASCII character codes for colons, and periods to tags and file names, which then fail to display properly (empty square box characters) within Kodi / Madnox 2.0, but as I've not nailed down whether this is Picard or an installed plugin, I've not reported it at this time.

I have see the hyphon issue in the past (what "-" char used) but not colons and periods, so it may be a plugin problem or just the data some community member addded.

FWIW Kodi does not use "DiskID" and "TotalDiscs" tags.

[gibxxi]

I didn't know the advancedsettings.xml settings were deprecated. By the old way of doing things, I'm referring to the way I had to segregate tracks from different disks into "Disc-subfolders" under the global album folder in order to accomodate the old "cdART Manager" addon which would only save files as "cdart.png" with no variation or added disc numbering. I stopped using it a long time ago in favour of "Artwork Beef", but never got around to undoing the folder-structure changes (I'm lazy).

Dan / Gib.

[gibxxi]

I need to spend some time and read the wiki (properly) on the music library, evidently. Unfortunately time isn't something I have a lot of, but thank you for the clarification(s) anyhow. Looks like quite a few things I "assumed" were the case, are not so.



Dan / Gib.

[DaveBlake]

You no longer have to use separate subfodlers for discs in order to get local disc art, but you can if you want to. So if your music files are already like that then there is no need to change.

[gibxxi]

You no longer have to use separate subfodlers for discs in order to get local disc art, but you can if you want to. So if your music files are already like that then there is no need to change.

Unfortunately, that wasn't the experience I was seeing. Disc artwork was not being saved to the disc subfolders in Kodi 18 + Artwork Beef. It was being saved to the global album folder (one level up) which is not where I want it. I want it next to the tracks to which it is tied. I don't know why it did that, but that was certainly what it was doing, so I reverted to a flat folder structure, using MB-Picard to move / rename the files and update the tags at the same time. It's done now, and I don't plan on changing it again, but thanks for the clarification.

EDIT: Just to be clear: I anticipated this being the case going into Kodi 19, so made a pre-emptive change based on that assumption. "Path of least resistance" and all that.

Dan / Gib.