Follow up to PR8069 - Adding music to the library
#1
As a result of PR8069 quite a few comments were made that were off topic to the desired purpose of that PR, however are perfectly valid in the wider context of the work flow needed to add music to the library. For those that don't know,we keep long discussions off github because every comment made generates a notification sent to every Team members.

The purpose of this thread is to allow for the discussion and exchange of ideas on how adding music to the library could be improved, including tag scanning and online data scraping (which was off topic to the PR).
Reply
#2
Thanks JJD for starting this thread especially since #8069 has been locked. I only hope that the contributors to that discussion spot it here, is there any way a final post could be made to the PR that alerts those watching the Github where the discussion is be continued?
[Edit: thanks for doing that Razzee]

I do remain more than a little confused by what can and can't be discussed and where. Design discussion is much more important than code syntax and layout comments, the Github seems the ideal place for it. If discussion is to result in change then it is best lead by the person intending to implement the change. Also in my view the posts to that PR seem mostly on topic given the nature of the change that was being proposed. On my part sorry if anyone felt spammed by what seemed to me to be constructive collaboration.

I hope to make time later today to summerize the content of the PR8069 debate, but I obviously have misunderstood the purpose of that PR so perhaps I am not the best person to do that.
Reply
#3
I think perhaps there been a general misunderstanding on all sides.

I've not personally had time to try out the proposed changes as it seems they only build on Windows at the moment, but my understanding is the purpose of the PR was to use a Set Content dialog to set the default scrapers instead of them being hidden in Settings -> Music -> Library then where the default scrapers didn't what to be used it would be possible to set different ones on a per folder basis using the Set Content dialog. The act of scanning tags (not sure if the Scan to Library context menu item is replaced by this) and then have to scrape online data separately by "Query info for all artists" and "Query info for all albums" remained completely unchanged hence why this part of the discussion was viewed off topic.

I will see if I can get a test build posted here so you can see for yourself.

On the Github thing, PR comments should remain focused on the details of specific change, anything outside of this should be discussed in this area of the forum, in this case I think it was a mistake not to post a "please take this discussion to the forum" type message on the PR instead of locking the comments. So please use this part of the forum for any general design discussion, expressing your ideas, what you think should be changed and how you think it could be done etc.
Reply
#4
(2015-09-19, 15:13)jjd-uk Wrote: I've not personally had time to try out the proposed changes as it seems they only build on Windows at the moment, but my understanding is the purpose of the PR was to use a Set Content dialog to set the default scrapers instead of them being hidden in Settings -> Music -> Library then where the default scrapers didn't what to be used it would be possible to set different ones on a per folder basis using the Set Content dialog. The act of scanning tags (not sure if the Scan to Library context menu item is replaced by this) and then have to scrape online data separately by "Query info for all artists" and "Query info for all albums" remained completely unchanged hence why this part of the discussion was viewed off topic.

I'm not changing any context menu items. I removed some of the cases that show change content in context menu, where it felt out of place.

You can actually achive the same as this PR does in our released versions.
Add a new source -> go to artist or album view -> select your just added album/artist -> press context on that source -> select "Change information provider" -> Scraper Config opens -> Click okay

This PR essentially removes the middle part.
Add a new source -> Scraper Config opens -> Click okay

There is one problem, that I see, and that is, that a user has to choose if this is an album or artist.
I don't think a user should care, it's music to her/him. Powerusers might, but we shouldn't be catering to them here.
Reply
#5
(2015-09-19, 15:13)jjd-uk Wrote: ...my understanding is the purpose of the PR was to use a Set Content dialog to set the default scrapers instead of them being hidden in Settings -> Music -> Library then where the default scrapers didn't what to be used it would be possible to set different ones on a per folder basis using the Set Content dialog. The act of scanning tags (not sure if the Scan to Library context menu item is replaced by this) and then have to scrape online data separately by "Query info for all artists" and "Query info for all albums" remained completely unchanged hence why this part of the discussion was viewed off topic.

There was agreement that making the choice of scraper nearer the file view, rather than hidden in Settings, was a good thing. Gaining the ability to set scrapers on a per folder basis was also seen as an improvement.

In the confusion between scanning and scraping, their improtance for music being different than video, it was not clear what was being proposed for the context menus especially the "Scan to Library" one.

Razzee Wrote:I'm not changing any context menu items. I removed some of the cases that show change content in context menu, where it felt out of place.

Thanks for the clarification.

At the moment when we add a new music source nothing happens unless you go to a context menu, is what you are proposing that a dialog will come up immediately? So at this point the user must set scrapers for both artist and albums? Then what happens?

You see currently when you "change information provider" you are then invited to scrape the information. This makes sense because the library has already been populated with tag data (otherwise you would not be in the artist/album view), and the scrapers use that previously scanned data to identify the music.

At that inital point of adding a music source the first thing that needs to happen is to scan (tag data) to library. But a user may want to just view the files, in which case creating a library has to be optional. When that is complete, if they have decided to have a library, the user may want to scrape extra information from external sources, for artists, albums, both or neither.

So we need to consider several things:
a) Is presenting the user immediately with scraper selection for both artists and albums is the best thing to do?
b) Would it be better to ask them if they want to scan and populate the library first?
c) Could the selection of scrapers be available from the file list, but not be displayed immediately?
d) Do we want an automatic option that on adding a source goes off and scans tags then scrapes artists and album info?
e) If we do then I am certain we also want to be able to turn that off and do things manually.

There was a lot of debate about merging album and artist scrapers. But the valid point was made the there are reasons why a user may want to scrape info for one and not the other. Given the global use of Kodi this is not just a niche use issue.

This makes the music user interface different from video, where having chosen the nature of the folder (TV, Movie etc.) off you go. But there is no reason why it need be difficult for the user to grasp.

Seems to me that even the selection of music scrapers is something that a general user isn't interested in. Once we are talking scrapers etc. then we are in the realms of the more engaged user anyway.

I believe that Kodi should cater for both novice/infrequent users and power users without inconveniencing either. Good design can do that.

Good to be allowed to talk.
Reply
#6
Windows test build for PR8069

http://mirrors.kodi.tv/test-builds/win32...-music.exe

Note this is no where near a final state in terms of gui layout but should convey the principle of what is intended.
Reply
#7
Read through all the posts. Just wanted to leave a message that the intent to align the logic for videos and music (or even integrate them) is a great objective and hugely beneficial for the broad user base of Kodi. I actually never thought that it was intentional to have a separate logic (which is the same as the "video logic" from a few years ago), but thought that nobody had time to work on this before.

Anyhow, big thanks to all of you looking into this. I am a heavy music user and am sure that many more will use Kodi for music once changes like the one in PR8069 will be implemented.
Server: Asus Sabertooth Z77 | Intel Core i5 3.4 GHz | 16 GB DDR3 | 128 GB SSD, 82 TB (9 x 6 TB, 7 x 4 TB)
HTPC 1: Raspberry Pi 2 | HTPC 2: Raspberry Pi 2 | HTPC 3: Raspberry Pi
Reply
#8
Exactly, when the video section was updated many many years ago to have only a library view with files a node within it, the intent was always that music should follow suit and operate but simply no one had the desire to work on. We've now got a foundation to build on since the work creating only a library view for music got merged, so no more toggling between files and library.
Reply
#9
(2015-09-20, 10:14)jjd-uk Wrote: Exactly, when the video section was updated many many years ago to have only a library view with files a node within it, the intent was always that music should follow suit and operate but simply no one had the desire to work on. We've now got a foundation to build on since the work creating only a library view for music got merged, so no more toggling between files and library.
JJD, it must be early because I don't understand what you are saying here, and I really want to. So could you clarify, what is the intended view? Seems to me the video only has a files node with no library? Eh?
Reply
#10
If I understood right from the PR you have no movies/tv videos scanned into the Library database hence the Library view only presents the file node, if you were to scan something in then all the other nodes that rely on the database would automagically appear.

Music should now be working in the same so you don't have to go to the side blade menu to enable/disable Library mode to switch between your library and files.
Reply
#11
If still not clear then I'll post some screensots later.
Reply
#12
Thanks for explaining JJD. Music has file and library nodes, (and artists, albums etc.) and we don't have to use the side blade to switch between them.

I do seem to be having trouble with video though. I have a number of TV series each as avi or mp4 files in a folder per season and series. I have now scraped them (Set Content to TV) as a test although I was quite happy using the file view. I don't have a library node appear, in fact I haven't noticed any thing different. Must be missing something? I'll have a poke in the videoDB see if it has something in it now. Sorry if I am being dense, maybe I need those screen shots!!

[Edit: Thanks JJD, sorry for cluttering thread to others. Don't need the screen shots. Finally pointed at my entire video collection and the it rip, and got a library. It turns out that more than 50% (and all the ones I tested with previously) is not identified by the scraper. Unlike music where you get the albums/songs in the lib from the tag data even if the scrapers can't subsequently find them, with video it silently does nothing. Another practical difference between the material types]
Reply
#13
To resume my point over the PR :

Refactor is needed and welcome, but currently music is different from video because of 2 things : tags and Album / Artist different scrapers.

Since ((from my point of view and DaveBlake too and surely tons of others,) a merge of the 2 scrapers may not be wanted and the fact that there's the TAG to handle in the data priority when integrating music, this just needs careful thinking about how to make things easier for end user and not increase complexity more.

A proper approach can not mimic video way, because it needs a differentiation between scanning / scraping and handle 2 scrapers.

This change should also occurs in the context menu (Add new content vs Get new meta data)

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.


Tons of cools idea or things where never possible in Kodi because it was not perfect even if there's no other solution.

Current proposal have major flows and IMO could have negative impact on library usage, despite the needs that some Team member have, this does not reflect the majority of users.
Reply
#14
When you enter Videos with nothing scanned you are taken to Files view as this is where sources are managed, as nothing is in database the other nodes are suppressed. If you scan something in the other nodes should become available, however note that you remain within Files node, to see the other nodes you need to go up a level.

1. Level 1 Home menu - Videos
2. Level 2 Library Nodes - TV / Movies / Playlists / Files (with nothing in database this level is suppressed)
3. Level 3 - Node contents - Sources (if in Files & If nothing added you are taken direct here from Videos on Home bypassing 2.
Reply
#15
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"?
Server: Asus Sabertooth Z77 | Intel Core i5 3.4 GHz | 16 GB DDR3 | 128 GB SSD, 82 TB (9 x 6 TB, 7 x 4 TB)
HTPC 1: Raspberry Pi 2 | HTPC 2: Raspberry Pi 2 | HTPC 3: Raspberry Pi
Reply

Logout Mark Read Team Forum Stats Members Help
Follow up to PR8069 - Adding music to the library0