[tkgafs]

going with the museum idea, i group some things by using the album artist tag
for example classical albums have artist tag set correctly but the album artist is set to "Classical - ArtistName"

I can see your reasoning, but abusing the album artist tag this way you lose all the nice things you could do with artist. Not an approach I would encourage.

Instead an "order by genre" option would be an easy and usefull addition?

Yes an order by genre with artist and album year as additional sub sorting fields would be useful. At the moment the genre tags in my albums are pretty haphazard but if they served a useful function I'd probably fix them, and as you say elsewhere the online ones are very arbitrary

[HomerJau]

An app is more likely to provide the kind of "move about" UI the OP wanted than the "10ft interface" with TV remote. An app could add such hash tag functionality now. But for poratbility and persistence it would better to have the data inside the music library, not just in the app copy.

Agreed Dave. But since Kodi presumably doesn't store all the tags then an app may have to store additional music attributes, at least in the short term until a future Kodi release supports something.

I will take a look at this next year and see if I can prototype an app to handle the requests in this thread since I'm a big user of Kodi for music.

[Uatschitchun]

For a better music experience, besides custom tags, it would be nice to have the possibility to get to items more straight and direct.
It would be nice to jump directly to the album or artist of currently playing song, to look at the album or other albums from this artist. Maybe even genre or custom tags could be included

Agreed. Bi-driectional navigation e.g. having selected a song link to the album (maybe even albums if you have compilations too and mbids to identify the recording), or artist(s) etc. or from album to artist etc.

Yes, some kind of 'jump to' or 'show artist, album, etc'. Right now, there's no connection between the actual playing song/playlist and the media collection/database

When playing a real CD or Vinyl, I'm not only viewing the front cover, but am able to turn the cover to see the track list.

Do you mean having more than one image per album? Or having a songs list in a panel when an album is selected on album node?

No, not more images, but a more stringent playlist integration. I don't get, why it is important to have visualization options in music OSD, but not an easy way (button)to show the playlist!? Kodis focus is on optic and playfulness but usability is behind that. A bunch of easy ways to show images, visualization and lyrics, but no way of fast switching between audio playing and the media.
I have configured a button on the remote to show the current playing playlist, but it's always a matter of where I am if it gets displayed.
In shorter words, yes, a simple and fast way to switch between media, playlist and music fullscreen/osd. I even can't find a way to disable the timeout of album cover showing with song info in fullscreen. Only way is when playback controls are displayed.

Picking up the museum idea, I would surely like to look left and right of the current item found. Maybe head for something I know and get inspired from there...

Up to now I haven't found a quick and intuitive way to get to 'relations' of what I'm currently playing. Examples are:
* show releases of same genre and year
* show albums of same artist
etc

I get the idea, but how would we define "related" items? Surely we need to let the user choose the criteria? But interesting.

A start would be to have media, playlist and current song/album connected in a navigational sense. Being able to fast switch between current and playlist would be a start.
A second step could be a fast way to switch between media and current song. When listening to music, I don't need the main menu. I only need my music collection, my playlist and the fullscreen info with cover.
From playlist one may have a jump to option, which switches to the related album. One step up then would be corresponding artist showing all albums.
Music isn't database friendly. It's nice to have the possibility, but the natural way is best reflected when using filemode, not database. Or, one would be able to design the database view like filemode :-)
It's nice for movies, but I guess no one has a movie collection as huge as an audio collection. Even if one does, 200 movies are 200 movies, whereas 200 CDs are appr 2000 tracks!

Sorting music in "hardware", I never would expect Jazz in the same space as Metal. Genres are nice, but the discussions on genres is well known (could be just 5-10 or 500-1000). So custom tags come in handy here, having some main genres within custom tags like 'Rock' (which sums up Hardrock, Postrock, Metal, Punk for me), Jazz (New Jazz, Experimental, Swing, etc)...

I do think users need to get control of genre, certainly in what they tag. Scraping online genres for artists and albums can resuklt in a mess too - do any of us agree on genre? I want to get Kodi to propagate song genre into artist genre, and allow the user to refuse the scraped values that come with other nice things like biogs. I also wonder about having a genre / sub genre relationship, sort out the Hardrock, Postrock, Soft-rock etc.

What I am saying is that we tackle the genre mess independantly of having a hash-tag or custom tag facility.

I guess the main cause of confusion, feature requests and wishes for music in kodi is the misconception of 'what works for one kind of media, works for all kind of media'. Some similar discussion is about unscrapeable movies not being added by filename...
The golden way to listen to music (and I'm talking about larger collections here) is to have a stringent way of organizing the music in hardware (filemode). Therefore a consistent naming scheme and a hierarchical ordering is necessary. To get that, one needs proper tagging for the mass renaming. Once that is done, one adds music to kodi and all work of hierarchical ordering and naming is lost, as the database neglects all this and throws it over board...
Some kind of mixed mode comes to mind. For smaller collections, a pure database mode could be sufficient. For larger collections, a pure filemode is far too less.
A possible way to go would be to add the folder structure/hierarchy into database. I know it's possible with smart playlists, but that's too static!
When we have folder structure in db and being able to navigate along that structure even in database mode...!? Yes!

I have a folder called unsorted, where I put new music for to get to know the music prior to adding it into media structure, as I like knowing what I've got prior to just having :-)
How would I be able to just focus on this music with database mode? No way!
Only way would be to loose maybe genre and tag my unsorted/unlistend music with genre 'unlistend' or, use filemode loosing advantages of database...

My main problem with music in Kodi (and with all tag based players like Ipod fi) is that there's no way of 'own ordering' my music. Databases are a nice to have, like catalogs in museums are, but the art displayed in a museum isn't unordered.

It is the database that makes ordering possible, although Kodi only offering a limited variety at the moment (and has some odd bugs). But what do you mean by "own ordering"?

Explained above, I guess :-)

Widgets are nice, too. But even there I haven't found a way to 'jump' to a random album displayed in a random albums widget, but only am able to play that album. If I like to draw a path from there, I start listening to a random album, I have to be able to get to wherever I'm inspired from by that album in a quick and intuitive manner. It even takes "millions" of buttons to get to the current playlist...

In a museum I'm able to start and go on from there. Head left for photography or right for paintings. Head for the upper floor to see more experimental or contemporary art or downstairs to see Mona Lisa :-)

Agreed. From any item, any where (nodes, widgets etc.) you want to be able to play, but also go to related items and chose that relationship e.g. other items by artist, other songs on that album etc., other items that genre, other items that year, other items that genre and year, other items with same hash-tag or combination of tags.

Keep the ideas comming.

Yes, nice sum up, Thx :-)

My suggestions would be:
* reflect folder structure within database (gives, what nodes or SPL do, but dynamically
* a consistent and not destructive 'current' playlist (only cleared by user's request)
* an intuitive way to switch between media, playlist and fullscreen
* add a way to directly switch between fullscreen (current playing song) or some song from playlist to the corresponding album
* the hierarchical structure, we now have in database, makes it possible to just get "upstairs" from song, to albums, to artists and what is coming above that
* cause of having the database in handy, a switch to similar genre, year, composer, etc would be quite easy

So far from my side, thx for reading :-)
R

[Uatschitchun]

Hope my wall of text isn't annoying!

[DaveBlake]

Hope my wall of text isn't annoying!

Not at all, I enjoy the creative discussion. A bit distracted with family stuff at the moment, but will be back with a (possibly annoying to others) wall of my own.

[DaveBlake]

But since Kodi presumably doesn't store all the tags then an app may have to store additional music attributes, at least in the short term until a future Kodi release supports something.

I will take a look at this next year and see if I can prototype an app to handle the requests in this thread since I'm a big user of Kodi for music.

I suggest we work together, so even if the app gets there first then switching to a subsequent Kodi data implementation is simple. Krypton has taken longer to get out than expected, but v18 could be quick, no one knows. I could potentially get work merged quicker if I had a team of testers supporting me.

[DaveBlake]

No, not more images, but a more stringent playlist integration. I don't get, why it is important to have visualization options in music OSD, but not an easy way (button)to show the playlist!? Kodis focus is on optic and playfulness but usability is behind that. A bunch of easy ways to show images, visualization and lyrics, but no way of fast switching between audio playing and the media.
I have configured a button on the remote to show the current playing playlist, but it's always a matter of where I am if it gets displayed.
In shorter words, yes, a simple and fast way to switch between media, playlist and music fullscreen/osd. I even can't find a way to disable the timeout of album cover showing with song info in fullscreen. Only way is when playback controls are displayed.

Very valid point. Estuary seems to be worse than Confluence in this area, I start something playing, then can't find a (quick) way to stop it! I know the UI guys are very keen on clearing clutter e.g. as few controls as possible on the side blade, minimal items on context menu, but we seem to have lost (or maybe never had) something vital. How much of that I can address without UI members support I don't know, fundamentally I am the music database guy (and my taste is for far more "clutter" on the UI than the team will allow).

Music isn't database friendly.

Oh yes it is!!!

It's nice to have the possibility, but the natural way is best reflected when using filemode, not database. Or, one would be able to design the database view like filemode :-)
It's nice for movies, but I guess no one has a movie collection as huge as an audio collection. Even if one does, 200 movies are 200 movies, whereas 200 CDs are appr 2000 tracks!

I see the absolute opposite. My video colllection is easy to navigate as a list of files in folder, no need for a library (especially when the scrapers can't recognise most of it). But music, having a database made from the tag data means I can find my way around a very diverse collection in amazing ways that a simple folder structure can not produce.

What I want to know is what isn't the library doing for you that makes you think it is "unnatural" or not as good as just a folder hierarchy?
(Maybe you explain more further down the "wall"?).

I guess the main cause of confusion, feature requests and wishes for music in kodi is the misconception of 'what works for one kind of media, works for all kind of media'. Some similar discussion is about unscrapeable movies not being added by filename...
The golden way to listen to music (and I'm talking about larger collections here) is to have a stringent way of organizing the music in hardware (filemode). Therefore a consistent naming scheme and a hierarchical ordering is necessary. To get that, one needs proper tagging for the mass renaming. Once that is done, one adds music to kodi and all work of hierarchical ordering and naming is lost, as the database neglects all this and throws it over board...

Kodi uses the tags, that you happen to have also used to create coded filenames, to create the library. It will definitely contain more of the tag information than you could have managed to encode into the filename. The db does not neglect nor throw anything overboard. Maybe there are tags doesn't process yet, that is where I can extend things, but I don't see why not using the filenames (which may be anything) is an issue.

As for those that mysteriously have well organised files, but no tags, well tagging from such filenames is easy.

I do know there will be people with disorganised and untagged music that would like Kodi to magically sort out the mess. One day some kind of musical fingerprint lookup may fix that, but I would argue it is not the job of Kodi to do that. (Anyone thinking hey I have the time and expertise to make that happen, please come and help with some of the more pressing areas of Kodi first).

Some kind of mixed mode comes to mind. For smaller collections, a pure database mode could be sufficient. For larger collections, a pure filemode is far too less.
A possible way to go would be to add the folder structure/hierarchy into database. I know it's possible with smart playlists, but that's too static!
When we have folder structure in db and being able to navigate along that structure even in database mode...!? Yes!

What? Sorry you have lost me.
I get there is something you want the library to do that it isn't doing, but not what that is.

I have a folder called unsorted, where I put new music for to get to know the music prior to adding it into media structure, as I like knowing what I've got prior to just having :-)
How would I be able to just focus on this music with database mode? No way!
Only way would be to loose maybe genre and tag my unsorted/unlistend music with genre 'unlistend' or, use filemode loosing advantages of database...

Ah, Ok.
I think that kind of thing could be solved by custom tagging (the original theme of this thread). You want a way to say flag all the music in this folder as "unsorted", and then be able to view that stuff.

Use of "tagging" for both the tags internal to music files, the xml tags in NFO files and for flagging artists, albums or songs in some way via Kodi is going to get confusing. How about we call the latter "flagging" just for now.

An organised person like you will have all the music like that in a folder, but what if it was in sevaral places? Flagging would be able to apply the flag to any combination of folders, or other way of choosing music.

My suggestions would be:
* reflect folder structure within database (gives, what nodes or SPL do, but dynamically
* a consistent and not destructive 'current' playlist (only cleared by user's request)
* an intuitive way to switch between media, playlist and fullscreen
* add a way to directly switch between fullscreen (current playing song) or some song from playlist to the corresponding album
* the hierarchical structure, we now have in database, makes it possible to just get "upstairs" from song, to albums, to artists and what is coming above that
* cause of having the database in handy, a switch to similar genre, year, composer, etc would be quite easy

I always love it when people tell me things are easy :p

I can agree with most that you want, where I want to haggle is how much "folder structure" is presented in the library by default. Music does not always fit easily in folders e.g. artists collaborate on albums so which artist folder does that go in? Artists that cross genres. Music shared with family members, and then some isn't. Yes sometimes the easilest way to categorise something is to say - the stuff in that folder, but often it isn't.

I'll give it some thought though. Maybe you can give more examples of what a folder navigation from library would do?

[Uatschitchun]

Nothing is as easy as writing a wall of text and do some wishes, especially on Christmas :-)

Thx for reading and giving me a thought!

I'll surely come up with more :-)

[tkgafs]

No, not more images, but a more stringent playlist integration. I don't get, why it is important to have visualization options in music OSD, but not an easy way (button)to show the playlist!? Kodis focus is on optic and playfulness but usability is behind that. A bunch of easy ways to show images, visualization and lyrics, but no way of fast switching between audio playing and the media.
I have configured a button on the remote to show the current playing playlist, but it's always a matter of where I am if it gets displayed.
In shorter words, yes, a simple and fast way to switch between media, playlist and music fullscreen/osd. I even can't find a way to disable the timeout of album cover showing with song info in fullscreen. Only way is when playback controls are displayed.

Very valid point. Estuary seems to be worse than Confluence in this area, I start something playing, then can't find a (quick) way to stop it! I know the UI guys are very keen on clearing clutter e.g. as few controls as possible on the side blade, minimal items on context menu, but we seem to have lost (or maybe never had) something vital. How much of that I can address without UI members support I don't know, fundamentally I am the music database guy (and my taste is for far more "clutter" on the UI than the team will allow).

I think one of the reasons for this is probably kodi's movie background where you start a movie and play it, maybe skip forward etc, also people tend to have far less movies than they have music tracks contained in albums.

Music seems to have been very much an after thought, I'd like many more controls on the screen, I find estuary almost unusable for music playing, I can never work out where any of the controls are and the touch screen version seems even worse.

I would be happy to be a tester of any new ideas

And please please try and fathom out how to make a playlist display the artwork of the currently playing track by default

[HomerJau]

Good idea Dave. I'll ping you a PM with some thoughts on custom tagging.

I'm happy to become one of the testers for anything that can be implemented for v18 too.

I suggest we work together, so even if the app gets there first then switching to a subsequent Kodi data implementation is simple. Krypton has taken longer to get out than expected, but v18 could be quick, no one knows. I could potentially get work merged quicker if I had a team of testers supporting me.

[Uatschitchun]

Hi there, sorry my answer has taken that long!

Music isn't database friendly

.
Oh yes it is!!!

Coming back to this...

First of all, yes, music is database friendly, agreed, but...

Music, first of all is art and a release, album, concert, whatsoever is the piece of art the focus has to be on. No one would ever dearrange the Mona Lisa into background, foreground, colors, paint thickness, etc. A catalog may do this, to find art using same color or paint thickness or show all paintings showing women, but the main focus has to stay on the piece of art.
There's a reason why Vinyl is up on the rise again... people don't like the "cluttered" way but prefer the piece of art as to what it is, a piece of art. (For instance taken the Beastie Boys "Paul's boutique"... it's an artwork altogether, not a collection of single artworks)

A must, in my way of thinking is to put the piece of art back into focus. That's mainly the artist, it's releases/albums and the tracks being presented on it.
For movies it is done this way. The piece of art is the movie and Kodi shows piece by piece, while additionally being able to use the catalog for 'relations' (actors, regisseur, studio, etc...)

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

Is music database friendly? Yes, it is, but within kodi it's cluttered from the very beginning. Why would I want to have a list of all my albums (not talking about a list of albums by a specific artist, but the all-albums list? Only 2 reasons I can think of: a) search for a specific album I know the title or b) get inspired.
Why a list with all artists? 2 reasons, same as above.
But both get the user distracted from the piece of art itself. If I want to look at the Mona Lisa, I don't want to reach it via a huge list of painters...
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.

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).

So, what to do? How to make use of the massive infos and tags available within the database without losing orientation or loose focus on the art itself?

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'. 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 (one tune but multiple artists, Sean Paul's "Get Busy" is a good example here as it is quite popular. It's the Diwali Riddim voiced by many others). So it's a matter of filling up the database correctly and being able to create views. Classical music maybe has its view created as Orchestra->Composer->Title or Maestro->Year->Composer whereas Riddims need Albuminterpret being the Riddim (Diwali) creating a view like Albuminterpret->Artist->Title or Artist->Albuminterpret (to see what Riddims the artist has voiced)
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.

A design concept which puts the artwork itself in the main focus (a standard view so to speak kodi starts with). This main view is adjustable as how the user like it to be (be it a replica of the filesystem structure or a only random albums or or or)
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.
One could also define as many predefined Views as one likes (Nodes, but dynamically)

So we have the standard view (needs to be discussed hows that defined as a default, but I would suggest simply using the filesystem replica as a new user directly recognizes his music... nevertheless, it's customizable), the on-the-fly views and predefined Views (schemes?).
Flagging could be done quite easily then! Just create a View (or a filter as to speak) and give ability to flag multiple results at once or only a few or only one, as the view is hierarchical and the filter could be set finer or broader (the best place to store this flag is within the Tags)

That's my suggestion for Media browsing part of Music within Kodi

The other suggestions regarding relations between music still keeps valid. Why can't I, even when using my tablet, use yatse and am able to open the song or album infos and jump directly to artist, album, year, genre, etc?
A non destructive playlist, things like play music, view movie, continue music once movie is finished...

Lastly, I've some remarks regarding database. I've got a huge collection speaking of a 125MB database file within mysql. It's slow, although connected with gigabit lan. I make use of 'similar tracks' for last.fm a lot having the possibility to find similar music to the one that is playing just now within my own collection. It takes quite a time with local db but with mysql it's slow. Is there a way to fasten db queries by doing some indexing? Even adding huge genres (3k files) into a playlist is not what I call performance. I would expect a speed bonus for db in comparison to filesystem. Adding 3K lines of text into a playlist is a simple copy paste. Could having the playlist be a db file or a table itself enhance this in regards to performance as it's only a query? I don't have to fear missing tracks within a playlist as I keep the db up2date.
Is there a db query for kodis musicdb that's able to measure system's performance and make it comparable? A benchmark?

I've used Kodi a lot the last week in regards to music as I wanted to have some more background :-)

I'm missing (kodi's 10ft concept) a way to have track infos when listening to music show up in a size, I'm able to read from 10ft away. I always feel like compared to movies, it like watching the movie only in a preview window instead of fullscreen.
When using artist slideshow, etc, the Infos in a corner are sufficient as I focus on the slideshow, but it could also be the opposite way, having the infos large enough to read from afar and the slideshow somewhere aside.
(I know that's skinning!)

So far for first day in 2017 :-)

[DaveBlake]

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

Music, first of all is art and a release, album, concert, whatsoever is the piece of art the focus has to be on. ...

A must, in my way of thinking is to put the piece of art back into focus. That's mainly the artist, it's releases/albums and the tracks being presented on it. For movies it is done this way. The piece of art is the movie and Kodi shows piece by piece, while additionally being able to use the catalog for 'relations' (actors, regisseur, studio, etc...)

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.

Is music database friendly? Yes, it is, but within kodi it's cluttered from the very beginning. Why would I want to have a list of all my albums (not talking about a list of albums by a specific artist, but the all-albums list? Only 2 reasons I can think of: a) search for a specific album I know the title or b) get inspired.
Why a list with all artists? 2 reasons, same as above.
But both get the user distracted from the piece of art itself. If I want to look at the Mona Lisa, I don't want to reach it via a huge list of painters...
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.

In this instance you arrive at the gallery entrace wanting to view the Mona Lisa, and want to go directly to that item. If you know what album or song (disc set?) you want to play by title (and artist if title was not unique e.g. "Greatest Hits") it is just about being about to type that title in and go there. 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?

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.

So, what to do? How to make use of the massive infos and tags available within the database without losing orientation or loose focus on the art itself?

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.

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)

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.

A design concept which puts the artwork itself in the main focus (a standard view so to speak kodi starts with). This main view is adjustable as how the user like it to be (be it a replica of the filesystem structure or a only random albums or or or)

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 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".

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

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.

One could also define as many predefined Views as one likes (Nodes, but dynamically).

So we have the standard view (needs to be discussed hows that defined as a default, but I would suggest simply using the filesystem replica as a new user directly recognizes his music... nevertheless, it's customizable), the on-the-fly views and predefined Views (schemes?).
Flagging could be done quite easily then! Just create a View (or a filter as to speak) and give ability to flag multiple results at once or only a few or only one, as the view is hierarchical and the filter could be set finer or broader (the best place to store this flag is within the Tags)

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?

That's my suggestion for Media browsing part of Music within Kodi

Thank you.

The other suggestions all noted in the thread clearly, you don't need to repeat.

Having track info show in a size, you are able to read from 10ft away is a skin issue, raising it here on music forum isn't going to get anywhere. Personally I find most of it too big :p But I did think that Estuary v2 (as in v17 RC1) had addressed the text size issues some people had.

I have split off your speed issue comment into a separate thread - http://forum.kodi.tv/showthread.php?tid=302811
I don't think it is a database problem but something else, but best talked about secifically (this tread topic is cumbersome enough!).

[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

[DaveBlake]

Going to try and avoid a "super wall" of nested quotes in case we scare everyone away, but I have taken on board the rest of what was said @Rusendusen.

Q: How can Kodi (or a remote app interface to Kodi) be flexible enough to provide the music in a way that corresponds to the user's taste, given these tastes are different from user to user, vary from day to day and with the kind music you are currently listening to.

The idea @Rusendusen and I are homing in on is of supplimenting the current user configurable but static node UI approach with a more dynamic filtering facility that lets the user choose:
a) the current filter criteria including mix of artist, album and song rules and IDs, and custom properties.
b) the content type being viewed e.g. artists, albums, songs or property sets e.g genres, years, custom property values etc.
and I think also more skin options under user control
c) what fields are shown, e.g. if genre = classical then display composer. Flexible multiple field ordering including use of custom properties (not a hard coded limited list of sort orders).

*A way to save any set of filter criteria for reuse.
*The option for the music main screen to be a user chosen/designed node rather than the music library node menu.
*A music serach option for when you know what you want to play, of course.

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).

Still not sure about the "chains" thing (I know there was more explanation later), it will help me to rephrase. Do you mean let the user define and then save what the default nagivation action is when an item is selected? What "chains" brings to my mind is navigation choices.

The often hidden navigation choice I what to expose and discuss is this:
Say I list those artists that have composed songs with "guitar" in the song file path. When I navigate off that list for a selected artist do I keep the other criteria and what content type do I show?

Keeping criteria -
1) albums that has songs composed by that artist with "guitar" in the song file path
2) songs composed by that artist with "guitar" in the song file path
3) genres (or other custom song properties) of songs composed by that artist with "guitar" in the song file path
4) custom album property values of albums that have songs composed by that artist with "guitar" in the song file path
5) custom artist property values of artists that have composed songs with "guitar" in the song file path

Dropping all criteria except artist selection
6) albums by that artist, or with songs by that artist, or with songs they contribute to in some way e.g. backgroud vocals etc.
7) songs by that artist or album artist, or that they contribute to in some way.
8) genres (or other custom song properties) of songs by that artist or album artist, or that they contribute to in some way.
9) custom album property values of albums by that artist, or with songs by that artist, or with songs they contribute to in some way
10) custom artist property values of that artist

Changing criteria (role = album artist, no path rule)
11) albums by that artist (there may be none if they are just a composer of songs performed by others).
12) songs by that artist (again there may be none or they may be different from 2)
13) genres (or other custom song properties) of songs by that artist
14) custom album property values of albums by that artist

If artists, albums and songs can all have different values of the same property, for example mood, do we optionally combine those too e.g.
show custom common properties of songs composed by that artist with "guitar" in the song file path or
of albums that have songs composed by that artist with "guitar" in the song file path or
of artists that have composed songs with "guitar" in the song file path

I took from the "artist-genre-title" chain example given by @Rusendusen the wish to be able to select an artist, navigate to artist filtered genres 3), 8) or 13), and from there to the songs or albums (title of what?) for that genre and artist and optionally the other criteria.

How do we offer the user that rich flexibilty in an accessible and configurable way?
Again maybe the "10ft interface" driven by TV remote isn't up to it?

It sounds horrible written out like I just did but it is how I would like to access my music collection sometimes. It could possibly be reduced to some basic choices maybe?

I think what @Rusendusen is saying is that he finds his way around his folder hierarchy easily enough (as do many other people), so couldn't the UI learn from that. Well maybe... :p

...If folder names would be part of db they would be additional data...

Just to clear that up: path is held as data, and can be queried. Path rules could be a filter criteria.

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.

Linking between fileview where you can navigate your folder structure, and library view (where you can navigate your library), at song level could work - evey song as a unique location. It would be a great tool for sorting out tagging mistakes too. Most albums have a unique location but kodi does not need that to be true, so a link from album to a meaningful folder is often possible but not always. Moving from arbitrary folder to somewhere in the library could be tricky too. What won't work is trying to do a simple link at artist level. The relationship between artist and path is many to many, an artist may have a relationship with many disparate folders e.g. no common folder other than the music source root level. I also believe that if we get the custom property facility right there is unlikely to be a need.

Dare I say some (not me) even doubt the need for fileview at all, I may have trouble selling the idea of a link to the team.

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 fine to have a vision

I know that what you dream is possible in data, and as a user myself the flexibilty is enticing. Creating the UI or API to support it, that's the challenge.

Others welcome to join this dialog (if they can penetrate the wall of words).

[WelshPaul]

Suggestions welcome, from anyone, about how to make multiple field sorting available to the user with a style of UI that matches.

Second that

I'm not trying to be awkward, but I simply couldn't make my way through the last few pages of conversation. I even considered watching Trump inaugurated instead. I really would like to be able to make a coherent comment, more to show some support to Dave who often seems to be ploughing a lone furrow than because it will be of any real insight, but I just don't really know what you're trying to achieve. If it's possible to condense the last few pages to a few simple questions, then perhaps the rest of us can offer some suggestions. Otherwise be assured that the lack of responses from the rest of us isn't because we don't care - it's just we don't understand the question.