[Tolriq]

Not knowing about the code, let me share from a "user perspective" on the two differences between video and music that were mentioned:

1) Two scrapers: fully understood. However, currently, this option is i music-settings. Could this functionality not be under "set content". There is one "row" in videos to set the scraper and it would just require a second row for the second scraper. From a user perspective, this would as easy as it currently is in the music-settings (and less hidden, so people do not need to hide).

2) Difference between scanning / scraping: I am using Kodi for more than 10 years (incl. music library) and was unaware that there is a different (for music only) between scraping and scanning. Let me guess that this is the same for 99% of all users (and what I saw on GIT even some of the developers). Why is this difference needed? Would not an option "local information only" (analogue to video library) give the same feature as "scanning"?

You confirm the major issue

The problem about local information is that for movie it links to NFOs only.

For music there's TAG in the files and NFOs that both means local information, and user should have control.

[steve1977]

I am still not sure whether I understand the issue.

For videos - even when a scraper is selected, it will start with NFO files followed by scraping if no NFO is available.

For music - why not set a scraping order if a scraper is selected (NFO->tag->scraper) and when "local only" selected (NFO->tag). If there are some people who do not want to use tags at all, this could either be a setting ("ignore tags" yes/no) or hidden away in advancedsettings.xml. There are some settings as well for tvshows content (prefer posters yes/no), so could all be done analogue.

What do you think?

[Razze]

Since, from the feedback I have, lot's of users just adds folder and never scan or scrape them, there's things to be done, and if done improperly this will increase the non library usage for music due to data not corresponding to user expectations.

Thanks for your data, this is always nice. But I think in this case, it's unfortunatly very misleading. I think most of these users are simply not aware, that there is a feature like this. And thats mostly our fault, as it is prominent in now way right now.


Here is a very basic mockup, nothing is set in stone here.

[Tolriq]

Well as I tried to explains in the PR, there's 2 cases :

- The user that are not aware of it because it's currently complicated and not intuitive.

- And the users that does not understand the relation between tags / nfos and the 2 different scrapers and complains that Kodi have bad information. (From Yatse support point of view this is the main reason they ask for features for the file mode over the library mode).

And if wrongly done fixing the case of users that are not aware without fixing the second case will just make the second case more visible.

The problem about the mockup is still the fact that most people will have problems to differentiate TAGs and NFOs for the notion of local information. And not sure this covers the needs I and blake have to have online for 1 part and offline for the other (with inverted cases between he and me).

Right now from feedback I have and my use case there's very few people using NFOs for music due to the lack of proper tools, but there was some new tools that surfaced on the forums, Ember talks about music, and in not so far future good tools to manage that have lot's of chance to exist.

Spiff was lockout discussion as all of us, but he said NFOs can not override TAGS, I'm doubtfully about genres / artists and so on for songs and albums generated as if true this will limit NFOs usefulness.
But this is also a point to take in account.

[da-anda]

I was going to post this on the PR, but it's better suited here to not track the PR in a off topic direction again:

While I appreciate the changes in the PR as a first step in the right direction, I think our content and scraper configuration needs a big change. IMO everything that applies to music section actually applies to 100% on video and vice versa, it's just that both libraries handle the same entities differently - one exposes additional info of related assets and the other isn't. So there are videos, like home videos that could be perfectly pre-tagged (MKV) and users might want to have these scanned in the library (tag only scanning just like for music, with fanart grabbed from tag or folder, along with probably additional related asset info via NFO, like "actors" = who of your family is on it).
Then for music we also have the possibility to show extra info about albums and artists which we partly also do on video, like scraping actor info/artwork, but we unfortunately don't have a dedicated actor view where you could read the biography of that actor like for artists - but technically it's the same type of asset and relation. So the artist info scraper could be compared to actor info scraping, album info would be movie set or TV-show scraper. So from a technical point regarding aggregating additional meta data both media types would actually share quite a lot.

For video we have combined scrapers, for music we don't atm. A comment on the PR mentioned that we could also create combined scrapers for music to simplify the "set content" dialogue, but this won't solve the general issue and only be a workaround to get along with current borked source and scraper setup. What we should have in future are free configurable content types (with base types like movie, tv-show, music preconfigured) AND configurable scanning configurations for each media type, with multiple scanning configurations possible per type. The scanning configurations would become some sort of scraping/scanning presets where basic information providers for each related asset (album, artist, actor, ...) are preconfigured. When adding new content you then only specify the type (movie, home movie, music) and along with it the scanning preset to use, which defaults to a "default scanning preset" configured by the media type. It might make sense to allow to override a few scanning configurations per source (items are in folders that match foo), but scrapers would be none of them. These configuration presets could be implemented independently from the desired global source management section in settings and would also work well with current way of setting up new sources. So maybe it would make sense to work on these first, then adjust "set content" dialogue for music, and after that focus on refactoring the entire source creating and management.

[steve1977]

I think you bring up an important point. NFO files are basically irrelevant today and only the rather "advanced" users will use it. Do you have info through yatse about how many use NFO for music? My guess would be less than 1%. Also, those who use NFO files are advanced, so they will be able to use advancedsettings.xml and all kind of other more sophisticated things.

I think the mock-up can have some fine-tuning, but in general this looks great to me. I would not go into details of NFO / tags as this may confuse the average user. Would say local is either "NFO->tag" or "Tag->NFO" (I can live either way) and then push out further refinments of this to the advancedsettings.xml.

Right now, there are bigger fish to fry than worrying about music NFO :-)

[NEOhidra]

From my perspective (a user which doesnt use Kodi for music, at least for now) i would like to force Kodi just use the tags (i edited). I have no solution for the scanning vs scraping problem. My songs are mostly from indie artist (no albums just single songs) you wont find at all in any database so i want to avoid scraping.

I feel like: I am fine with the information in tags so please that information to populated the database (library) and do not try to reinvent the wheel by scraping new information because i already filled all the info in the tags. So an easy accesibly option like the one bellow would be perfect for my user case:

[Razze]

From my perspective (a user which doesnt use Kodi for music, at least for now) i would like to force Kodi just use the tags (i edited). I have no solution for the scanning vs scraping problem. My songs are mostly from indie artist (no albums just single songs) you wont find at all in any database so i want to avoid scraping.

I feel like: I am fine with the information in tags so please that information to populated the database (library) and do not try to reinvent the wheel by scraping new information because i already filled all the info in the tags. So an easy accesibly option like the one bellow would be perfect for my user case:

In that case you would choose the scraper "None" (I forgot to mention that or add it to the mockup)

[NEOhidra]

A button/option labeled "None - just tags" sounds great to me!

[jjd-uk]

From my perspective (a user which doesnt use Kodi for music, at least for now) i would like to force Kodi just use the tags (i edited). I have no solution for the scanning vs scraping problem. My songs are mostly from indie artist (no albums just single songs) you wont find at all in any database so i want to avoid scraping.

I feel like: I am fine with the information in tags so please that information to populated the database (library) and do not try to reinvent the wheel by scraping new information because i already filled all the info in the tags. So an easy accesibly option like the one bellow would be perfect for my user case:

In that case you would choose the scraper "None" (I forgot to mention that or add it to the mockup)

Or set to local information only in order for just tags to be scanned.

[DaveBlake]

@Razzee
a) Is this dialog to come up immediately on adding a new music source?

b) What happens when you click OK? Will it say "Refresh now" and then scan the tags and then scrape extra info as per the settings?

If we are going to scan tags and then user scrapers it could be slow (if you have a large amount of music thant you just added the folder for). Need to warn for this, but also allow the user to just add the source without any extra processing starting if they want. i.e "Refresh Now?" - no.

Can it also remember all those settings from last time?

[Martijn]

a) yes it should immediately after you add a new source
b) the "the refresh now" should only pop up when you changed a source and not on a new scan ("bug" in video set content)

Yes doing online scraping is sslllooooooooooooow so ideally it should be done async from scanning tags. So make sure it does scan tags before starting slow online process.

Yes it will remember settings for that source you set. We will make sure it has the most sane defaults. Remember this should only be done one for each source you have.
One option that i forgot to add in the screenshot was "exclude from scan" which videos does have as well. This way you could force exclude a subfolder.

note: remember this is a very quick mockup. Used text and option should be improved to make it more clear what does what.

[WelshPaul]

I think you bring up an important point. NFO files are basically irrelevant today and only the rather "advanced" users will use it. Do you have info through yatse about how many use NFO for music? My guess would be less than 1%. Also, those who use NFO files are advanced, so they will be able to use advancedsettings.xml and all kind of other more sophisticated things.

I think the mock-up can have some fine-tuning, but in general this looks great to me. I would not go into details of NFO / tags as this may confuse the average user. Would say local is either "NFO->tag" or "Tag->NFO" (I can live either way) and then push out further refinments of this to the advancedsettings.xml.

I agree pretty much with this. NFOs do have a purpose for storing artist descriptions and biographies if you're not using shared mySQL, and for music nerds like me to fine tune, but it ain't the biggest thing.

If the aim of this thread is to enable new users as quickly as possible to get their media into the library then keep it as simple as possible. I agree that questions like "Overrule information stored in tags by online info" may already be too confusing for that purpose. You'll be inundated with people saying "I said yes to that and it's changed all my information."

What are we actually looking to grab that won't be in the tags. Surely it's going to be primarily the artist biography and album review. Is there much more than that at the start? The artwork is generally coming from other skin add-ons. Discographies and things like that are great but I do wonder whether that is a bit of a niche market as well, and whether that could be solved by later selective update rather than scanning everything on first use.

Right now, there are bigger fish to fry than worrying about music NFO :-)

So, so, so, agree with this.

[Tolriq]

Or set to local information only in order for just tags to be scanned.

This would mean the same label would have 2 different usage between movie and music since this one is specially for NFOs only for movies.

[DarkHelmet]

Because tags are not read for videos. Tags and NFOs are still very much both local information.