[DaveBlake]

When users scan their music files into the library, I would like to get Kodi to give users feedback on the quality of tagging. Poorly or inconsistently tagged files quietly either fail completely or make a mess, or sometimes the library results are just unexpected. For the user it just makes Kodi look bad. Much better if we could at least give the user a hint where they have messed up. The same thing could apply to video if tagging takes off there too.

The sort of tag integrity we can check and report back is things like:
a) mis-match of number of artist names to number of musicbrainz ID
b) Having artist musicbrainz ID but not track or album

In a perfect world the file tags would be perfect, but of course they aren't even after using tools that lookup external databases. Even expert users can get in a mess on occassions.

So where can this feedback go?

1) The debug log. This seems obvious as we are reporting "glitches" in the tagging, and it is already available. But downsides:

• Have to have debug on during scan, not default use.
  
• Report mixed in with lots of other debug output meaningless to many users.
  
• Not readily visible from Kodi (viewing log from RPi etc. is a right faff)
  
• It is tempoary, content replaced next time you restart, so eariler scanning incidents are lost
  

At the moment we do log here when files have tags that Kodi doesn't recognise, but not sure how helpful that is or if anyone ever looks at it. Mostly it is just standard tags that Kodi doesn't process and hasn't got code to skip.

2) The event log. Not really sure what this is for, but Razze suggested in another thread that it could be used for this. It is visible from within Kodi, and so far uncluttered (mine only has one entry). But can you save it, to share with support or check later?

3) Something else? I don't really want to create another logging facility with all that entails, or is it trivial? Pausing the scan with a warning message just isnt Kodi. Alternatives?

Really like some design input here from the rest of the team or interested users.

[DaveBlake]

Just had a series of users all with tagging mis-match issues. When you explain and tell users to fix their tags, the response is often "can't I just turn the use of musicbrainz ids off somehow?". That would be a retrograde step, mb ids offer benefits for the user experience (if their tagging is consistent). Instead I think we urgently need to make the process of scanning and populating the music library more robust and flexible. By that I mean:

1) Kodi needs to be ready to cope with the kind of tagging that Picard produces.
Picard is the major (but not only) tool that will tag files with mb ids. It by default doesn't use space-slash-space as an item separator. It now supports an ARTISTS tag (but not ALBUMARTISTS) to help resolve the mix of what Kodi sees as a single artist name of "AAA feat. BBB" and 2 mb ids, but not all files have that. Classical music files the composer name is separated from other artists by a semi-colon etc. Asking users to ensure every thing has space-slash-space as a sepatator isn't working.

2)When Kodi encounters a mis-match, it needs to try and cope, but log that it is fixing a mis-match. If it can't do that it should reject that file but again log what happened in a way the user can easily see. That means in the event log rather than the debug log, but either way these logs are transitory.

Could it be logged in a more lasting way?

I know I am talking to myself in the music corner (slightly better than being on the naughty step!), and I will just get on and implement something, but any comments before that would be welcome.

[zag]

Logging would be wanted yes, especially when Kodi does something clever (like guess an artist from musicbrainz api).

As we chatted already I still think we should recommend Musicbrainz id3v2 2.4 tagging to any users who has issues. Its virtually impossible to support all tagging apps out there so we need something to recomend when we say "fix your tags". Musicbrainz ID's are really useful for looking up metadata these days so should be the standard we set.

[pbureau]

This is maybe a separate issue, but I believe the music experience is also bad because of the way things are implemented in the UI.

When a music library scan is done, the default behavior is to fetch meta data from files only, the scraper to fetch Album info from the web is not used. The scraper is triggered with a context menu item which is, for the least, not easy to find, and moreover I believe it will only scan the currently visible directory.

For me there should be an easy way to scrap information for the entire library, and it should be started by default after a library update.

Moreover, the scan has a different behavior when it is started from the "Refresh" button inside the DialogAlbumInfo. In this case it will have a much "smarter" process, prompting the user for more information to fix the meta data. This is quite confusing, and I also believe there should be a way to scan the entire library using this "smarter" process, it could be called "interactive scan".

I am working on a patch proposal to provide this interactive scan, I will submit a pull request for this shortly.

[DaveBlake]

Nice to have some company in music corner

pbureau yes a sepate issue really, but what the heck.

When a music library scan is done, the default behavior is to fetch meta data from files only, the scraper to fetch Album info from the web is not used. The scraper is triggered with a context menu item which is, for the least, not easy to find, and moreover I believe it will only scan the currently visible directory.

It is true that scanning tags and scraping album and artist data from the web or NFO files are separate activities, and that uses find the context menu hard to find. But what is scanned is not the "currently visible directory". If you click on "Query info for all" then it scans all artists or albums (not both) that have the same source folder as the item you are on.

For me there should be an easy way to scrap information for the entire library, and it should be started by default after a library update.

Automatic scraping is something that was discussed before. This is desired by many, but while the quality of tagging and the consistency of the library produced by it is still an issue, it was decided that scraping automatically was not such a good idea. We need to improve how Kodi copes with poor tagging first. There is already a setting for fetch data on library update, but it defaults to disabled.

Moreover, the scan has a different behavior when it is started from the "Refresh" button inside the DialogAlbumInfo. In this case it will have a much "smarter" process, prompting the user for more information to fix the meta data. This is quite confusing, and I also believe there should be a way to scan the entire library using this "smarter" process, it could be called "interactive scan".

I am working on a patch proposal to provide this interactive scan, I will submit a pull request for this shortly.

Sounds good, ping me with the PR.

[pbureau]

Hi Dave,

I actually didn't know about the fetch data on library update setting, that is a shame because I spent quite some time trying to find a way to do this

However, do you happen to know this setting's tag in the code? I just spent a couple of hours inside the musicInfoScanner code and I didn't see it. Could it be CSettings::SETTING_MUSICLIBRARY_OVERRIDETAGS ??

For me this does not have the same result as starting a "Query info for all albums" in the context menu.

[DaveBlake]

I actually didn't know about the fetch data on library update setting, that is a shame because I spent quite some time trying to find a way to do this

However, do you happen to know this setting's tag in the code? I just spent a couple of hours inside the musicInfoScanner code and I didn't see it. Could it be CSettings::SETTING_MUSICLIBRARY_OVERRIDETAGS ??

It is CSettings::SETTING_MUSICLIBRARY_DOWNLOADINFO (I think). Overridetags is what I describe here http://forum.kodi.tv/showthread.php?tid=...pid2215464

A few thoughts to add:

Scraping a large library can be slow and the user does not want to hang about or interact. In that case we need scraping to be autonomous and asynchronous.

There are situations where scraping may not be wanted e.g. you are off line, or you have limited space that you don't want to clutter with fan art etc.

The original idea was for scraping to magically happen without the need for intervention. The use of musicbrainz ids makes it more likely that the album and artist will be accurately found. So if we tag accurately, do we need an interactive scrape?

Recently quite a few users have complained about the frustrating way scraping overwrites previous choices for artwork. You create a library, scrape, adjust art, then add more music, scrape again, and the adjustments are lost. I have not always been able to repeat their experiences, but clearly it is something that needs checking and improving.

For me this does not have the same result as starting a "Query info for all albums" in the context menu.

I am not a scraping expert, and from my last point above there are things happening I am not totally understanding. So if you want to investigate and summerize what get scraped and when that would be fine.

[tkgafs]

Recently quite a few users have complained about the frustrating way scraping overwrites previous choices for artwork. You create a library, scrape, adjust art, then add more music, scrape again, and the adjustments are lost. I have not always been able to repeat their experiences, but clearly it is something that needs checking and improving.

This action in particular really irritates me, as it often seems to change to an US or a re-issued album sleeve rather than the "proper" original UK sleeve

I would love to be able to use kodi to tag 20000 tracks but at the moment I dont trust it and have the auto update turned off