[jjd-uk]

I imagine navigation in that style to be hierarchical. We have in and out as possible navigation directions, like going from artists to albums to songs (in) and from songs to albums to artist (out). This in regard to the "query chain" artist-album-song. So, no matter what the sorting (query chain) is, there's always in and out possible.

The only way I imagine anything like that working on a 10ft GUI is to add an additional filter levels to the nodes.

A couple of examples for Albums & Artists:


[Albums]
|-> Artists -> select album artist - > select album by selected album artist -> songs in selected album
|-> Genre - -> select genre -> select album name from albums of selected genre -> songs in selected album
|-> Title -> select album name -> songs in selected album
|-> Year -> select year -> select album name from albums in that year -> songs in selected album

[Artists]
|-> Album -> select album artist -> select from album name from albums of the selected album artist -> all songs on selected album
|-> Genre -> select genre -> select from artists with songs of the selected genre -> all songs of selected genre & selected artist
|-> Song -> select song artist -> all songs by selected artist
|-> Year -> select year -> select from artists with songs in the selected year -> all song by selected artist in selected year

[Uatschitchun]

I'm not trying to be awkward, but... 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.

There's not really a question, but a suggestion. :-)

If it comes to questions, I would ask, what are the benefits of having a DB right now? For to be true, I'm not a fan of tag based navigation when it comes to music. But, if I have the possibility of having a DB, I would expect to be able to use it for what it is made for: querying, sorting, filtering and searching... but I can't...

I've got my music sorted on file level and I'm able to find what I want to listen to with just a few clicks without the need of a DB. The only advantage of a well tagged collection is, that it's not cluttered when viewing it tag based and that the software is able to find art, fanart, etc, cause of having MBIDs. That's all kodi is able to offer?

If I have my books sorted on a shelf, I don't need a DB to find the book I like to read.
If I have my tools sorted in a workbench, I don't need a DB to find the screwdriver

If I want to have a list of all books from one publisher, a calc sheet comes in handy
If I want to know, how many tools I have from 'Makita', a calc sheet comes in handy, too.

Only if I have multiple tables/sheets with additional information, like a publishers table with addresses, owner, etc or a manufacturer sheet with electrical and nonelectrical tools, product numbers, etc, I would benefit from a DB.

So here are my questions for to distract you from having to watch Trump (btw, there's one good reason to do: know your enemy :-):
What do you think DBs are made for?
What are the advantages of having a DB for music right now?
Do you think that's all a DB can offer and do you think kodi makes good use of it?

For to be honest, the hole discussion around artists and album artists could be solved by some intelligent sorting on file level. Why does MBs Picard has it's own scripting language for to save files after tagging? To fill DBs?

Why am I able to have an album, artist or song information screen, when not beeing able to use cross references (the strength of a DB, btw)?
Why do I need something dynamic as a DB, when I'm only able to define static nodes?

Give me a hint on how I'm able to listen to music I've copied from a friend with using a DB? (Ups, certainly no one does something like that!! I'm certain, all music kodi users are listening to are obtained in respect to DMCA!)

Tell me why kodi is awful slow when it comes to DB queries? (see my thread regarding similar artists)

I would come up with more questions as it's 4 years of distraction needed :-)

R

P.S. Aside, if a DB is the answer to all questions regarding music, why do all these audiophile people owning a huge collection of CDs or Vinyl sort them in a shelf? It would be far easier to give each album a number, have some piles of Vinyl or CDs and use a DB to find a piece of art by the corresponding number...
All this ordering in libraries, museums or supermarkets is a waste of space and time...
Make ordering great again :-)

[Uatschitchun]

The only way I imagine anything like that working on a 10ft GUI is to add an additional filter levels to the nodes.

A couple of examples for Albums & Artists:

Nice, thank you! :-)

As they are examples, there's a whole lot more imaginable...

[DaveBlake]

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.

LOL

Yeap, it is obtuse, sorry about that. Guilty of more than a little hijacking
As for my "lone furrow", no worries I know Kodi has lots of music library users. I just assume they are all off happily listening rather than spending time on the forum.

But let's see if I can be a little clearer about what has been discussed.

First part of this thread is all about support for user defined properties of songs, albums and artists - both from custom tags within music files or NFO files, and a user "hash tag" facility to mark items (songs, albums or artists) in some way. I have taken that idea onboard, just need to find time to flesh out the details and do it.

Another (clearish) part is sorting - letting the user have more control over multiple field sorts rather than the limited hard coded ones be have now .

The remaining discussion is about navigation - where can you get from here.
Current navigation is very prescribed. From genres you can see artists; from a selected artist you can see the albums; from a selected album you can see the songs. Back takes you back to the previous node level. In the node definition, or system settings, you fix if you are going to only see album artists, and only see the albums that they are the album artist on, or do you also see the other albums where they sang a duet on one track etc. Then you can get down to see just one song on an album. You can leave the library and look at a file view, but not connect them.

The database behind the library could support much more dynamic and flexible navigation. I want to move towards that, but do it in a way that other users will like and be able to use. I like to hear people's ideas, they inspire me (sometimes anyway), or at least show the gaps in my thinking.

Immediate examples of what could be added:

• You set to see song and album artists, navigate down artist -> album (not by that artist) -> song and see just song where the artist snag the duet. Then would be nice to be able to go to all the songs on that album, or maybe the other songs by that artist, or the other songs or that genre, or year etc.
  
• Likewise in party mode, or on some playlist, you hear a song and would like to go to the other songs on the same album, etc.
  
• From a songs smart playlist - all songs satisfying some rules - go to the albums they are on, or all the artists, or just the composers, or the genre(s)
  
• On song info you can see who composed it, from there go to all the other things they composed and or the albums they are on.
  
• From an album or song switch to file view of that item (songs have a file, and albums have an associated folder but artists don't always) - so helpful if trying to find where you have mucked up some tags.
  

There are many possibilities, so can we see a way to organise them?

Then add user defined properties... Say a user is interested in the country of origin of their music (songs, artists etc.) and they "tag" their music with countries. They are going to want to do with "country" everything they can do with genre - see a list, see those artists, albums, songs. Also want to combine country and genre or year, and switch between seeing album artists only or not. And go in reverse too - from a song, see the other songs with same country, or albums, or artists, or the genres. And then back down again, either with or without that country as a filter.

It is all so much harder to desribe than it would be to use!

Current (fixed) nodes would all continue, and I guess some things could be added to the context menu (although my fellow team members will fight that as clutter). But I hope we can add something flexible too.

At the moment I am imagining a new "super filter/navigation control" dialog, maybe replacing the current filter facility on the side blade. It defines what you are seeing both as filter rules, and the content. So it could have all the current song or album properties as rules, and then you deselect those limits you want to relax, and change content to albums, artists, genres or even some other user defined property (e.g. country, "hashtag" etc.)

But I will stop before this post becomes as impenetrable as the rest

[elee532]

This all sounds pretty great DaveBlake! Is it likely we'll see this new approach in Kodi v18?

[jjd-uk]

Since I believe pictures are the best illustration, here's an example of what I would consider to add more filtering to existing nodes.

Using Album parent node as an example



Enter Albums parent node



From there either:

Album Artists

enter Album Artists subnode



select Album Artist



select Album



Alternatively:

Titles

enter Titles subnode



select Album



Alternatively:

Year

enter Years subnode



select Year



select Album

[WelshPaul]

Well, I can see how these posts got so involved. I'll try to give my bit on your queries, but the TL/DR (as I think the kids call it) is that when Dave first made composer tags available I asked in the skinning forum if I could somehow create a link from the song info xml to create a search of other songs composed by that person. Ronie just shut me down with a "that's not possible in Kodi" reply, and implying it never would be, With the push from Kodi to make TV, movies, PVR and music all behave in the exactly the same way I wonder whether this is just an academic discussion or if you are actually thinking of altering the Kodi code, or just the music DB. Anyway, with that in mind:

what are the benefits of having a DB right now?

Being able to create smart playlists based on a number of criteria, for me it's normally rating >4 out of 5 (or 8 out of 10) and genre = whatever. I understand Nodes to be just saving the smart playlists you access very frequently in a form you can add to your menu rather than just favourites.

I would expect to be able to use it for what it is made for: querying, sorting, filtering and searching... but I can't...

Why not? This is what I don't really understand. How do you want to search or filter that you can't do now. I know it's a problem that not all attributes are available in all option boxes, and that's a pain in smart playlist creation, but it's a lot better than it used to be, and presumably missing options can be added if they're requested.

I've got my music sorted on file level and I'm able to find what I want to listen to with just a few clicks without the need of a DB.

I don't understand how you can have a directory structure that allows you to drill down by year, genre, rating, publisher, colour of hair, or whatever other thing you want. That was why I thought we had a library in the first place.

Only if I have multiple tables/sheets with additional information, like a publishers table with addresses, owner, etc or a manufacturer sheet with electrical and nonelectrical tools, product numbers, etc, I would benefit from a DB.

But isn't that what the attributes of songs, albums and artists are?

So here are my questions for to distract you from having to watch Trump (btw, there's one good reason to do: know your enemy :-):
What do you think DBs are made for?

Sadly, inauguration turned out only to mean getting the keys to the office while some girl sang out of tune. I thought it was going to be much more Game of Thrones than that.

What are the advantages of having a DB for music right now?

As above.

Do you think that's all a DB can offer and do you think kodi makes good use of it?

I don't really know, but I bet if you give people the ability to select things on the basis of 5 different criteria the next day someone will say they need 6. It seems to me the first priority is to be able to get information out from the data you put in. Therefore, ensuring that all the columns in the database are available to select in searches, playlists, and filters is the main thing.

Give me a hint on how I'm able to listen to music I've copied from a friend with using a DB?

If you've copied it then it's surely no different to the stuff you had already, you scan it to your library and play it as you would any other. Or am I missing something.

Tell me why kodi is awful slow when it comes to DB queries?

Isn't that a function of the size of your collection and the spec of your hardware. The angle of the dangle and all that. I find mine remarkably quick considering I'm using a Fire TV connected wirelessly to a Synology NAS. But it probably depends where you're coming from and what you're comparing to.

if a DB is the answer to all questions regarding music, why do all these audiophile people owning a huge collection of CDs or Vinyl sort them in a shelf?

My Dad was a jazz buff and had filing cabinets full of old 78s and things. It was only when he died that we found all these typed cards with lists of which records such and such a saxophonist played on, and which drawer of which cabinet they were in. He obviously hadn't bought into the Dewey-Decimal system. The reason they had them on shelves was partly so they could put them on the player quickly, and partly so people like me could superciliously snigger at their collection at parties. A DB may not be the complete answer but it is easier than typing up a load of cards, that you then forget where you put.

First part of this thread is all about support for user defined properties of songs, albums and artists - both from custom tags within music files or NFO files, and a user "hash tag" facility to mark items (songs, albums or artists) in some way. I have taken that idea onboard, just need to find time to flesh out the details and do it.

Yes, I'd like custom tags. One thing I've not worked out is how to store biography and song information for singles collections. We have nfo files or you can scrape album artists, but I don't want directories full of files and artwork for a one-hit wonder. This is why I use the comment and unsynced lyric tags to store this info, which I then display in my musicviz xml. You can't have artist info for every singles artist, and a single album nfo for say an Assorted 90's single collection won't tell you about every song. Custom tags may make this easier. I may well be very out of date on this, as I do still live in the 90s and Dave may well have enabled some sort of singles scraping by now.

sorting - letting the user have more control over multiple field sorts rather than the limited hard coded ones be have now.

As I said above however much control you give people they'll still want more and still mess it up. How else do you explain Nigel Farage. As I said above I think the main thing is being able to get out what goes in by ensuring all database columns have an info tag available to skinners and all selection boxes have all possible options.

navigation - Current navigation is very prescribed

It seems to me prescription is the way Kodi's going. It's getting more and more complicated for a novice to tailor Kodi to their personal taste. To me the beauty of Kodi was the you could pretty much make yours a unique system, particularly if you learned a minimum of skinning. The direction of travel for Kodi over the last few years has certainly been away from that, with some wanting pretty much a one-click set-up for newbies. Wouldn't the way around this be to enable some kind of hyperlinking within Kodi, but then that's probably beyond the scope of both this forum and my brain.

On song info you can see who composed it, from there go to all the other things they composed and or the albums they are on.

I refer the honourable gentleman to the answer I gave some moments ago.


Sorry, added to the information overload and probably completely missed the point. But I do love the work you're doing Dave and thanks Rusendusen for taking the time to clarify the discussion.

[Uatschitchun]

Afaik, in movies it's possible to click on an actor from movie information dialog and see what movies I have with this same actor. So I don't know, for the sake of consistency, why it shouldn't be possible to have the same for composer, guitarist or any other information available.

I don't understand how you can have a directory structure that allows you to drill down by year, genre, rating, publisher, colour of hair, or whatever other thing you want. That was why I thought we had a library in the first place.

I'm not able to, neither with my sorting on file level, nor with kodis DB. That's why I'm suggesting...

I have a dream...

Starting kodi first time ever, I add music. Music is scanned to library and because the path is added to the DB (if the path is /music/artist/... it's nothing else as a csv with dash as separator). After scanning, the user is presented his music in "file level" view put together from DB. This has a huge recognition value and the user experience is: a, wow, my music as I know it.
From there he's able to experience the advantages of a DB, as he's able to use cross references (list other songs composed by, played guitar on, etc.). A few predefined DB views, like there are already, gets him (or her) deeper in the advantages of a DB.
I do not think of a prescribed number of views (as they will be never enough, as the user always wants what's not prescribed), but the freedom to create views... as many one likes...
Attention, here's coming a vision... think of 'The minority report'...
Choose a criminal within the criminals DB. Put focus on him and "whooosh whoossh", be able to change the context from criminals DB to the "local residents' registration office' DB, zoom out a little from the criminals flat to see his neighbors, pick his next neighbor and "whoosh whooosch" be able to change the surrounding context to the 'traffic department' and see the neighbors car plates, our criminal has stolen...
The "whoosh whooosh" thing is (statically) possible right now with defining SPLs or nodes, but one looses focus on the chosen target.
Only thing we need, is a way to define the 'context'. There could be predefined ones (like folder1>folder2>folder3>folder4>... folderX or artist>album>song or genre>artist>album>songs, similar to the ones we have right now). If one is able to click together those chains, one would be able to choose from self defined contextual views (query chains) with focus still on one item.

How to define query chains within the UI?
Let's do it like with choosing music. Give the user a list of all available tags and let him choose the first link in his new chain. Present a new list with all tags but the one he has chosen for to define the second link... the last link will always be songs/titles. So no matter how long the chain will be, choosing song title tag will always be the end of the chain.
I see no difference, UI-wise, between choosing data (artist>album>song) or choosing tags. Displaying a list of artists is the same as displaying a list of tags to choose from.

After defining the query chain, the user will be able to change the context while keeping focus on a selected item with simply switching from one chain to the other. A song in a context of artist>album>song could then be settled in a new context of whatever the user defines.

That implies, that the audio DB has the path separated as single cells (dash separated value).
Enable cross references like within movies (consistency), where I'm able to go from a movie to an actor to another movie with this actor.
And lastly make chain definition possible and allow the change of contexts on-the-fly

The advantages I see:
A huge recognition value in first use experience, as the user gets his music presented in a replica of his ordering on file level. Go from the known to the unknown.
No loss of information! The sorting on a shelf is work put into the collection. Not loosing this work is keeping the worth of the work put into.
Cross references allow quick movement (from a song in a playlist to the corresponding album, from a playing song to the folder it's in, from an album to other albums of the same producer, etc)
Definition of chains and contextual changes on-the-fly would be like re-sorting the shelf within a flick of the eye

As stated, I have a dream :-)

[WelshPaul]

Ah, OK I'm with the programme now. But wouldn't the Minority Report analogy be more suited to a streaming service, Spotty type addon, where you're seeking out something you've never heard before and want some imaginative way of delving into it. Wouldn't your own music library be more like the Usual Suspects. If you bought the music you would already know it, so it's more like having a set of mugshots and wrap sheets so you can say "Ahh, we ain't seen this type of caper in a while, this fits his MO, let's give his collar a pull, Guv". Though maybe I've been watching more of The Sweeney than The Usual Suspects. That's where I think a tag-based database is useful.

[jjd-uk]

To fully flesh out my proposal in http://forum.kodi.tv/showthread.php?tid=...pid2505279 & http://forum.kodi.tv/showthread.php?tid=...pid2506002

Since you either want to play an album or a song/collection of songs, I would completely restructure the current nodes into:

where PN= parent node and SN=subnode

1. PN - Albums
   * SN - Album Artists -> list of album artists -> after selection of album artist choose from list of albums -> display album tracks
   * SN - Genres -> list of genres (don't think there is currently an overall album genre) -> after selection of genre choose from list of albums of genre type -> display album tracks
   * SN - Roles -> not sure about roles as a subnode in this new structure perhaps Composers, All Contributors, All roles could fit as their own independent subnodes directly under the Albums parent node.
   * SN - Titles -> choose from list of album titles -> display album tracks
   * SN - Compilations -> choose from list of album titles -> display album tracks
   * SN - Years -> lists years which have albums -> after selection of year choose from list of albums in that year -> display album tracks
   * SN - Top 100 Albums -> choose from list of album titles -> display album tracks
   * SN - Recently added albums -> choose from list of album titles -> display album tracks
   * SN - Recently played albums -> choose from list of album titles -> display album tracks
   
   
2. PN - Songs
   * SN - Album Artists -> list of album artists -> after selection of artist display matching songs
   * SN - All Artists -> list of all artists -> after selection of artist display matching songs
   * SN - Genres -> list of genres -> after selection of genre display matching songs
   * SN - Roles -> not sure about roles as a subnode in this new structure perhaps Composers, All Contributors, All roles could fit as their own independent subnodes directly under the Songs parent node.
   * SN - Titles -> display all song titles
   * SN - Years -> lists years which have songs -> after selection of year display matching songs
   * SN - Top 100 songs -> display all song titles
   
   
   
3. PN - Playlists
   * SN - New playlist
   * SN - New Smartplaylist
   * SN - Party node playlist
   
   
4. PN - Files
   

[Uatschitchun]

Since you either want to play an album or a song/collection of songs, I would completely restructure the current nodes into:

That all would be possible with what I suggested... Additionally you would have the ability to change these "nodes" without loosing focus on a selected item.

As said, it's more a vision than a request. I'm not known to how kodi's core is open for something like that or if it even would be possible to implement!
I know it's easy to suggest something... And I know it's unfair if I'm unable to provide any contribution code wise...

The people I've talked to, especially women as they have a different technical affinity and approach, told me, they would love the recognition value, the cross references and sorting in an easy way.

The best, a UI can offer, is being able to use it with only a few explanations.

[jjd-uk]

While it's good to dream and all suggestions are welcome, what you propose is simply not going to be anywhere near possible in short term.

[Uatschitchun]

Know that! But even small changes can be designed to support further development.

Dave, regarding cross references, is that what's possible in movies (references to actors) able to be used in music, too? A core function, so to speak? I sadly don't know anything about how kodi is designed code wise. If there's a good ressource for to get an idea of the design concept... :-)

It's always more satisfying for all parts to have an idea of how easy or hard something is to implement!

[jjd-uk]

Some cross referencing is actually there already I think in the core code, I'm assuming it's yhis type of thing you're on about https://github.com/xbmc/xbmc/pull/10951

[DaveBlake]

There is some cross referencing in v17 yes, song -> (artist that performs a role). But it is a total dead end, you can't do go anywhere else from there.

What is wanted is to be able to wander about for example song -> artist (some role) -->
a) other albums or songs with artist have that role
b) other albums or songs with artist have some other role, or any etc.

and if at the time I was on the song I had filtered by genre, year, or some user property, then continue to apply that filter or clear it.

Just a quick reply. But I must take more time to catch up with what has been said on the thread.