[Razze]

If for example the settings for a scraper was not global but set on each place it was supposed to be used, a scraper could have settings for which data source to use for artist / album / song.

I think we do this already. Options you change on a scraper are saved to that scraper/path only. Check the 'content' table (referring from memory might be wrong) there should be a settings column storing xml or something along the lines. Thats actually in the PR, but we need the merged scrapers to move on if you ask me.

When adding a source do we really need to present the users with a lot of options they should preferably not need to change? What do you think about only being able to select music as a type when adding a source and to do more advanced settings you would need to do a set content? Or maybe only show the more advancedsettings if settings level has been set to advanced or expert under settings?

I would agree that we could hide the lower part (speaking of confluence) but changing the website/scraper source might be quiet hand. Or we should at least reevaluate the current defaults. It may just be my preference, but I think the Universal Scraper for videos is much better than the other ones. And there are also people that want to use anime scrapers on some folders.

[DaveBlake]

When scraping artists and/or albums, scraping is done based on information in the db and not the files themselves. So there is no guarantee that an artist and/or album only exist in one location, which could cause issues if the different locations are in places that have different scrapers set. Especially with musicbrainz tagged music, artists can be all over the place (since they are by default not placed in the title of the song but rather as separate artists in the artist field).

This is a very good point that has not been mentioned before. The idea of being able to set scrapers for a folder/source seems attractive, but you are right we are not scraping the music files we are scraping based on the database. We do need to think about this!!!!

Artist XXX is in my music library because I have scanned music files with them in the artist tags. But these song files could have been located in totally different folders, even on different drives etc. with different scraper settings. When I scrape this artist's data what setting do I use?

...There are some use-cases listed in this thread where different scrapers are being used, but I think we could solve those use cases while still merging the scrapers. If for example the settings for a scraper was not global but set on each place it was supposed to be used, a scraper could have settings for which data source to use for artist / album / song.

I agree separate settings within a scraper for artist/album/song could work as a merged scraper that could still meet diverse user needs.

When adding a source do we really need to present the users with a lot of options they should preferably not need to change?

I have been thinking about that on the journey home too. With Video we can not create a library unless the users specifies the content as one of none (don't scrape), TV Series, Season or Movie, we just can't scrape without knowing. But with music we can populate the library from the tag data in the files. If we wanted we could go on and scrape additional info too, and many users aren't interested in where this comes from.

If at some point we extend "music" to include talking books, or other audio sourecs then there may be a "content" to set, but at the moment the music case for many users is even simpler than that. Yet we want to encourage users to use the libary rather than just files, for an enriched experience.

What do people think about on adding a new source a simple dialog comes up with 3 buttons:
1) Populate library now - warning could take time with many songs
2) Settings (for more experienced users to set scraper options for album/artist/song, or say none if not want to scrape)
3) Just create source (make library later)

On 1) we scan the tags and then use the scrapers depending on configuation

On 2) we show our scraper choices and options, then go back to the above 3 button dialog when closed.

On 3) we just add the source to the list as a path. There are reasons users may want to do that, and only that.

Simple for novices, powerful for experts, moves settings nearer the file list, makes scanning and libary obvious. What do you think?

[Razze]

I think while this could work out might be very confusing. Especially case 2, with sending some one back in the loop. It's unlikely that you want to set the settings and not scrap after that.

Other problems are that we should use dialogs that are already there so that skinners don't have to do extra work. That pretty much leaves us with the dialogSelect which just lists items to select. I'm really not sure about settings on the same list with two actions.

Also how do we align video to this? Our goal should be that I can show my grand parents how to add videos and they can figure it out for music on their own after that. And vice versa.

Why shouldn't we think about music's future and have the content choose able?

[Tolriq]

The real question should not be how to make Video looks like Music or how to have Music looks like Video as it's a non sense after reading all the comments about both different ways to handle things

The question should be what would be the new process that could cover both ....

From end user point of view, there should not be files / add sources entries at multiple places with different purpose. Some users even sometimes add sources for the file manager mode and do not understand why they do not show. (I don't even know how they do that :p)

A global add a new media source (with eventually places like today a little everywhere that point to it), a dialog what kind of content is this with direct list of shows / movies / music ... and not a dialog with none by default and need to click on small arrows as users can miss that.
Then a question do you want to gather data online, then the scraper selection / configuration.

That would be adding function thought about how to make the process fit the user need, and not how to make process look like an existing process because it's easier to code or because if current process is here it's because it's good.

[jjd-uk]

That kind of Plex work flow is exactly what many of us on the Team are pushing for.

So there is central global media source management where you select the media type you wish to add (music, movies, tv etc) and then you are asked where this media type resides (local & network locations) and finally you get presented the scraping options (could be a modified version of the current Set Content).

[Razze]

The real question should not be how to make Video looks like Music or how to have Music looks like Video as it's a non sense after reading all the comments about both different ways to handle things

The question should be what would be the new process that could cover both ....

That was essentially what I was trying to say.

From end user point of view, there should not be files / add sources entries at multiple places with different purpose. Some users even sometimes add sources for the file manager mode and do not understand why they do not show. (I don't even know how they do that :p)

A global add a new media source (with eventually places like today a little everywhere that point to it), a dialog what kind of content is this with direct list of shows / movies / music ... and not a dialog with none by default and need to click on small arrows as users can miss that.
Then a question do you want to gather data online, then the scraper selection / configuration.

That would be adding function thought about how to make the process fit the user need, and not how to make process look like an existing process because it's easier to code or because if current process is here it's because it's good.

I think this is actually what most in the team are going/hoping/trying for. With one difference, there are some arguments, that choosing the content type (shows/movies/music) should be in the first window.
The PR we were talking here about is merely a first step in the right direction.(keep in mind this PR should only go in if we can merge the scrapers first)

[Tolriq]

Yes content type first is more or less what I was trying to say (Just not as a spinner hidden behind a default none).

The main concern about music are the numbers I have about people not happy with scrapping not giving correct result for them, so if pushing toward a solution not clear to users, those numbers will increase and defeat the purpose of the PR and needed changes.

Again from my numbers and experience (but who cares ) users remember a lot more things that does not work and time lost than things that works straight-fully, so just think that most users that will be disappointed by a not good temporary solution have very very few chance to try again later when a new solution is implemented.

Even with a big changelog with red texts forced on update 70% never read, so for Kodi that does not present a changelog on update but only publish on web site the numbers should be worse.

Sometimes it's better to wait for the correct solution than pushing something that could have the opposite effect for a large number and will be very hard to recover from.

[Razze]

Yes content type first is more or less what I was trying to say (Just not as a spinner hidden behind a default none).

The main concern about music are the numbers I have about people not happy with scrapping not giving correct result for them, so if pushing toward a solution not clear to users, those numbers will increase and defeat the purpose of the PR and needed changes.

Again from my numbers and experience (but who cares ) users remember a lot more things that does not work and time lost than things that works straight-fully, so just think that most users that will be disappointed by a not good temporary solution have very very few chance to try again later when a new solution is implemented.

Even with a big changelog with red texts forced on update 70% never read, so for Kodi that does not present a changelog on update but only publish on web site the numbers should be worse.

Sometimes it's better to wait for the correct solution than pushing something that could have the opposite effect for a large number and will be very hard to recover from.

Well I know that we're mostly trying to get rid of spinners? (not sure if this is written down somewhere, but I know martijn often talks about getting them out and removing them here and there)

Users remembering things that don't work is probably the most normal thing there is, shouldn't be different about Yatze?

Nobody is pushing for this, in fact, this PR can lie there until version 20 or whatever if you ask me. This can also be a problem, as we might never see music improve at all if nobody pushes for change.
But moving stuff around like we're pretty much talking about here all the time, shouldn't be a big problem. It's probably more a problem of finding a resolution, mocking it up and commiting on it.

[Tolriq]

Well I know that we're mostly trying to get rid of spinners? (not sure if this is written down somewhere, but I know martijn often talks about getting them out and removing them here and there)

Users remembering things that don't work is probably the most normal thing there is, shouldn't be different about Yatze?

Nobody is pushing for this, in fact, this PR can lie there until version 20 or whatever if you ask me. This can also be a problem, as we might never see music improve at all if nobody pushes for change.
But moving stuff around like we're pretty much talking about here all the time, shouldn't be a big problem. It's probably more a problem of finding a resolution, mocking it up and commiting on it.

Glad to see spinners away

And yes it's the same for Yatse, that why I talk about experience and feedback

About the changes, well IMO this rely also on the global way of handling coders, I know I repeat myself again and again and again, but how could someone propose a major change or refactor if there's no way to talk about it and get a validation ?
Who could possibly manage hundreds of hours of coding when anyone at the end can say, sorry no I do not like this idea and close the PR and discussions ?

Topfs have given up for headless this is sad. Montellese still have faith about the import stuff and is from the team and have enough knowledge about all part to push it far.

But who else can manage such big things? About music it's even worse not only no one would / could validate an idea but most people having no knowledge or no usage would not even bother discuss or help the side effects on other parts.

[zag]

They key is to PR one small change at a time

[Tolriq]

They key is to PR one small change at a time

You can not reach a target with multiple steps in multiple directions

A direction : Coherent API to support recursivity when handling directories

History : 80% of the API support it
10% step : https://github.com/xbmc/xbmc/pull/2559 (Merged)
10% step : https://github.com/xbmc/xbmc/pull/2773 (Not merged for bad reason, since the same reasons does apply to other PR and to all the other recursive params for JSON, and all cases for infinite loop are handled and not possible in this PR)

Result : API not coherent, 90% have recursive, one not, but yet the recursive support is still on the TODO list for JSON http://forum.kodi.tv/showthread.php?tid=163215

The current way does not work and can not work.

And this is a so simple example with near 0 impact, imagine for bigger things time loss and problems ....

[evilhamster]

Spinners? What are those?

If we are looking longterm, do we really want to keep content settings? It should be possible to only have the user add a media directory and then have kodi figuring out what kind of content is located there and use the appropriate scanner. Something like:
Directory with video files with similar names and similar length -> probably tv
Directory with video files with different names and most > 60 minutes in lenght -> probably movies
Directory with media without video -> probably music
Video files in directory structure with music files and/or length < 10 minutes -> probably music videos
.. and so on..

We could move that logic into something similar to an addon, to cater for different needs and get code out of the core. Basically, just call with all information kodi has about a item and a formated xml/json is returned with all the information that could be found about that item.

Just read http://forum.kodi.tv/showthread.php?tid=238307 doesn't that look like a really nice long term plan?

[evilhamster]

If for example the settings for a scraper was not global but set on each place it was supposed to be used, a scraper could have settings for which data source to use for artist / album / song.

I think we do this already. Options you change on a scraper are saved to that scraper/path only. Check the 'content' table (referring from memory might be wrong) there should be a settings column storing xml or something along the lines. Thats actually in the PR, but we need the merged scrapers to move on if you ask me.

You are correct, I missed this! Do you know if any work has been done on merging the scrapers?

When adding a source do we really need to present the users with a lot of options they should preferably not need to change? What do you think about only being able to select music as a type when adding a source and to do more advanced settings you would need to do a set content? Or maybe only show the more advancedsettings if settings level has been set to advanced or expert under settings?

I would agree that we could hide the lower part (speaking of confluence) but changing the website/scraper source might be quiet hand. Or we should at least reevaluate the current defaults. It may just be my preference, but I think the Universal Scraper for videos is much better than the other ones. And there are also people that want to use anime scrapers on some folders.

Would be interesting if we could get any data of the most used scrapers and their settings, Tolriq is this some data you have access to?

[jjd-uk]

Spinners? What are those?

Where a settings has a number of options but only the currently selected option is shownso the spinners are the up/down arrows to the side required to toggle through the options, those of us seeking to improve user experience don't like these as you can't see the complete list of options. Instead we are trying to move these spinners to be a select dialog where you get the complete list of options, can identify the one you want easily, and then select it.

[phil65]

Second reason is that we shouldnt have controls which eat left/right actions. Pressing left/right/up/down should a l w a y s move the focus to the next control. That´s why we also want to get rid of slider controls and edit controls. They all suck.