[Uatschitchun]

Long post @Rusendusen, since you have taken time to write it I will take the time to understand it, but at first pass I have to say I'm not sure what you are getting at. So now the dialectic begins

Up for it :-)

So, what to do with this way of view on music? :-)

Sounds to me that you are an albums guy like I am. I tend to listen to a whole album at a time, not a "mixed track" playlist, I like to experience the artist's concept of an album created at that phase in their career etc. For me personally improving browsing is all about making choosing what album(s) I want to play now (in the next few hours) easier and more natural. Do we agree?

But to get to an album (I have ~2000, and I know there are users with even more) I often go via artist. I may have a clue about who I want to hear, or I may need to reduce the choices of artist or album using filtering of some kind. Currently I use genre (having tagged with my own categories as genre), but more widely it could be some custom properties of the "art" that I want to filter by.

We absolutely agree on both topics! The way we like to listen to music and the way how we choose. I see no sense in having Madonna next to Manowar next to Madness or Mad Professor (just examples :-)

So (mis-)using the genre tag as category would be a solution. But, one loose the finer sub genres MB provides.

So one of my main topics is: how can kodi be able to provide the user's music in a way the user wants it without loosing data. In the example of genre as category, how can one have categories without using the genre tag (that was the origin of this thread in regards to custom tags).

Second topic is: how can kodi be flexible enough, to provide the music in a way, it corresponds to the user's taste, as these tastes are different from user to user. One likes categories as the main view, the next one likes to have all artists alphabetical, etc etc

Nodes solve the second topic in a static way. No problem with that.

So all in all it's nice, handy and useful to have a database containing all kind of infos and more, as long as it is centered around the artwork itself.

So for you the default nodes of unfiltered artists and albums (and by inference songs), that appear on both Kodi UI and the remote apps, are clutter. At least they are not what you want to see first.

Yes and no :-)
Yes because of what we talked about above (categories) and no because sometimes I like to browse through artists or albums.
When visiting a friend with a collection of ~2000 Vinyls, I like to simply browse through without having a knowledge or have to make up my mind about his ordering

But it's not about me and my taste, it's about the user in general and his specific taste. So I'm aiming at flexibility and openness when it comes to how the user wants to see his music.

Again, I know about nodes and how to use them. But they are static and need xml files to provide them.

My thinking is this:
I have music containing data and I have an ordering I like to replicate using the data. This order is different from user to user, from day to day and from occasion to occasion. A party needs a different way to represent the data than when one is listening alone...
So kodi has the data, more thanx to your work in the matter of the DB and what data is read and processed!
And Kodi has it's main nodes.
So it needs simply 1 thing (and I don't talk about easy here :-):
A way to make query chain creation dynamic (filtering) with being able to save chains created as nodes (for to add to menu) or schemes/views (for to have them lying handy and easy accessible).

I can think of more views/nodes than any main menu is able to hold and I can think of always a user wanting it (the representation of his own music) being different :-)

Are you just saying that the music home page needs a search (or "Goto") facility for when you already know what you want to play?

Not bad, would definitely use it and give it a huge voting, but no :-)

I want to enter the record store and discover. I am presented with an ordering, the vendor has created. If I'm looking for a specific release, I have 2 choices: discover the order and search or ask the vendor. What the vendor does, when asked is tell or use his computer to use the database (earlier we called it catalogue and it weighted nearly the same as New York's phone book). His online catalogue is able to provide him with all ways of searching, ordering and filtering. He's able to limit the output to just labels by year or artist by label etc etc...

That's what kodi needs and already provides, but, as well known, static. Loosing what DBs provide (flexibility) or data, the user has "collected" (even if it is using MB) by using tags that already are filled, like genre.

As I've sorted my music on file level I'm able, like poster in OP is, to find the music I'm looking for by location (it's like a donkey bridge to find the path).

When you do this you aren't really using location, you are using some custom properties that you have implemented using file location. I'm suggesting that there are better ways to implement it, but would also hope to make it easy for those that have used path to encode properties to tell Kodi what they mean.

Nice, the dialectical approach has brought us back on topic :-)
Custom properties maybe already are there, but need to be added into DB. Be it with using custom tags...
2 possible entry points here: the user has no custom properties but likes to have them and the one who has them, but wants to have them being read into db.
So why not have paths (and folder names with that) being a custom property worthy to take into account?
I read users wanting to be able to filter by having "Vinyl" being present within path (or folder name). As long as there's no easy way to have custom tagging within kodi (and that's not what kodi is made for, being a tagger), let the user be able to provide his data (tag custom tags outside of kodi, make kodi read custom tags and let kodi be able to take the user's customization into account, which quite often is how the music is sorted on filesystem level.

I only want both, the record store and the vendor's catalogue. I want to create views as I need them and I want my custom properties, being it tags or paths, accessible. No one I know of would store his music the way Apple does, hashtags within a hashtag hierarchy. Mankind needs order :-)

If I get the use of databases correctly, it's advantage lies in the ability to create 'views' and to be able to manage 'relations'.

Partly, more broadly it facilitates a powerful and flexible way to query the information you store. In RDBMS terms "views" tend to be predefined, as are "relationships", all the flexibility lies in getting the information in a variety of ways. But I may just be gettiing fussy with words.

Full ack regarding our understanding here

There's definitely not that one single 'view' working for all users or for all kind of musical art. A view working for Classic music isn't working for Riddims...
A lot more 'views' come to mind when cluttering the piece of art itself into a collection of data being able to be put together again by the user... fast, fluid and on the fly.

That is the design idea behind smart playlists and custom nodes, but maybe the end result isn't as "on the fly" as would be liked. Like the default nodes they have to be predefined (editing xml either manually ot using an addon, but setup before use)

Jepp! We need it 'on the fly'. A spotified own collection. With search, filter, relations and queries. Clicking an artist has to always lead to this artists albums. Clicking on the album has to show the album. Having defined my node for parties has to not make me unable, to define another query chain, if there's this one guest, who's a Jazzer, wanting him to lead me through my collection of Jazz or composers by year...

I wonder if a better filter approach could provide a more "on the fly" facility - what you see (as a list, wall or whatever) is determined by criteria that are rapidly adjusted on a separate dialog. I have a vision for something like this, but no sketches to help explain it yet.

I somewhere read something you mentioned that wasn't far from what I've got in mind.

Sounds like you want the music main screen to be a user chosen/designed node rather than the music library node menu.
Plus a serach option for when you know what you want to play, of course.

But also want to be able to adjust that node dynamically while it is on display

Exactly

e.g. change it from a list of artists beginning with M with songs of genre = "Baroque" etc. to a wall of albums with songs of mood = "happy".

Nearly...
I want to be able to on the fly create that hierarchical chain that allows looking for artists with M and genre Baroque with defining my ad hoc chain 'artists-genre' providing a list of artists and the corresponding genres when clicking the artist. Kodi has a filter option already, so filtering for M or Baroque within that chain is possible already.
A chain artists-genre-title would allow browsing artists, enter the artist, view the different title genres and the corresponding titles by entering these genres.
That way provided data isn't lost, as MB provides title genre, with only using first title's genre within kodi atm, and the user is able to add hierarchy to his collection like he needs it.

A query chain would be the äquivalent to folder structure then but with the advantage of ad hoc reordering. The length of the query chain would be the äquivalent to depth within folder structure

Or even switch it to file view (but of course loose any tag based data filter criteria because the two don't mix).

Nope, the two do mix as, like said before, the path may contain custom properties. If folder names would be part of db they would be additional data. The db doesn't differentiate between the kind of data. Be it a tag or a folder name. I can't see the difference.
Problem could be to determine the depth or folder count as how many entries have to be created within db.

A library has its books ordered, a music store is the same. I'm able to pick up a book or an album and look it up in the catalogue, the db. A "show title in query chain" could be another way to mix up file view and db. Switch around the hierarchy for a specific item. Making it possible to use file view to find a song (because I maybe know where to find what I'm looking for, but not how it's called) and once I found it, switch hierarchy to query chain genre-year-title showing all titles of the specific year and genre. Or within chain albumartist-album-title switch chain around albumartist to artist-title for to see all titles this artist is listed in.
That's where predefined chains come in handy. Like 'open with' for movies.

Together with this main view one could offer the possibility to click together views by providing the available infos/tags
It could use lists of available tags, the user can choose of. Every choice could offer another list with remaining Tags or a 'end here' making it easy to create a view like Albuminterpret->year or Year or TagG-TagZ-TagE-TagF
Navigation within the views itself could be hierarchical following the given Tag-Chain created.

Sorry lost me a bit here.

It's the way query chains are created, I'm talking about here.
Think of it like the views we have now, but instead of providing the data itself, it provides the tags themselves. A list or wall view containing the tag names in a readable way. With that I'm able to define the chain/hierarchy I want. First view would offer all available tags. Choosing artist delivers the next view showing all tags but artist. Choosing role as second link in chain delivers the next view showing all tags but artist and role... once my chain/hierarchy is complete, I'm able to view my library's data following my chain/hierarchy.

Maybe it's simply nonsense I'm talking here and maybe it's overdose for just listening to music. :-)
But being able to switch around hierarchies around items on the fly... being able to view track info, click on John Deacon with role drummer and view all tracks he's drumming, but also the tracks he's singing (I'm in love with my car)... start a shuffle from my folder "smooth" for to read a book or chill and jump to the playing title's artist, switch hierarchy around and listen to more he has composed, played guitar, is singer or just producer as I have chosen the chain artist-role-title as new hierarchy...

Just dreaming of possibilities :-)

It is actually possible we have similar thimngs in mind, or maybe not, I'm not sure.

The exception being trying to mix file view and library views together. I don't think the library is about seeing folder structure, much like a gallery isn't the an itinery that lists where in the basement the paintings will be kept when not on display. File path might be used in filter criteria e.g. show me the artists or albums that have songs with path starting "F:/Music/KidsMusic" or path containing "Guitar" etc.. When you enter the criteria you could be allowed to navigate your folders, of course.

But I don't see switching between a folder hierarchy view and say artists in the way you could switch between related albums and artists. The relationship between an artist and folders may not be simple (Kodi scraping and art already makes that mistake). Folder - > artists possblle, but how do you show artist -> folders as a hierarchical folder view if the artist has connection with files on many diverse branches of the tree?

I've stumbled upon that, too. Maybe the concept of switching the hierarchy around an item solves it? Have to think about it again.
In a library the shelf and code of a book is accessible via the catalogue, too, else no one would find the book :-)

But it seems we're on the same boat regarding the worth of custom properties being present like 'path containing 'guitar '!

R