[LongMan]

@DaveTBlake
Good Day,
Thanks for all your hard work in modernizing the music section. As I am sure you can tell from your efforts, the music section really needed some love. Really appreciate it.

I really like the Sources feature that you added. I think your reasoning is right; many people do separate sections of their music physically. I do. In fact, I depended on that physical separation because I really didn't use the library section for music. I just browsed from files  to find whatever I wanted to listen to. It was your recent work that encouraged me to give music library a try. Unfortunately I am unable to use the feature because I use Emby Server for my media. Initially for videos, music was browsed from a a shared networked folder until recently. The sources feature is based on file path, and all Emby libraries are imported with a single path so there is no way to separate the libraries in Kodi.

I do understand that Emby is not officially supported, however, Kodi as central server is not happening right now, Kodi Media Import has stalled. So I am stuck with the unsupported approach.

The Request
Would you consider adding a taglike property to the sources feature. For videos, Emby libraries imported into Kodi are separated using the video tags feature. Each video is tagged with the name of its Emby library and Video Nodes and Smart Playlists are then used to separate them. AFAICT The same is not possible with music, no similar tagging property and the source property is only based on path.

What are your thoughts?

Looking forward to your response.
Cheers,
LongMan

[DaveBlake]

@LongMan I have split this feature request into a thread of its own so it can be discussed some more.

As an aside perhaps you can explain more why you are using Emby for music and thus lose the source filtering capabilities that v18 has. You say "music was browsed from a a shared networked folder until recently", why not continue? I'm just curious what Emby is doing for you, not criticising you or Emby, I really don't know anything about it nor time to research.

Supporting items having custom properties is an idea I started looking at for v18 but never finished.  The sources feature seemed more fundamentally beneficial so I put my finite effort into that.  I'm pretty sure there is a thread about it too which I will try to find and link later. I think a custom property facility would cover what you want, and be something similar to the "tag" facility of video. I prefer "custom properties" as terminolgy to "tagging" because tagging already means something else in music (the metadata embedded in the music files themselves) and I want avoid any confusion with that.

At its simplist it could be something like a "hashtag" string, much like you see on Facebook posts or Instagram, stored against artists, albums or songs. Added/modified via GUI, JSON API or NFO files (for artists and albums), and exported/imported so that things previously added during Kodi use can be applied to a fresh installation. Available for smart playlist, custom node rules  and dynamic filtering.

But my immediate thought is to look at the sundary data we already have for albums and artists that many users do not use at all e.g. themes, styles, moods. You could possibly make use of those to split your albums and artists at least?

[LongMan]

Thanks for replying.

To be honest I have always used files on a network share. I also use the share with Virtual DJ to record mixes, which are what I listen to most of the time.

I have used Kodi as standalone (SQLLite) HTPC. I later used it with MYSQL, UPnP sharing and now with Emby. I have five Kodi HTPCs around the house and a central server means that metadata is managed in only one place. I also carry a Raspberry Pi in the van with me for music. Whenever I buy new music I have to remember to take it in to copy the new albums. With unlimited mobile data plans now available it will be easier to just stream from my server at home and skip the copying.

Just a few words on Emby (was open but is now closed sourced), Plex (close sourced) and  Jellyfin (open source fork of Emby). They all have plugins for Kodi, that enable Kodi to be used as a client. Some plugins are not 'santioned' by Team Kodi because they write directly to the database. Other plugins use dynamic links are are in the repo.

These servers take a separation of libraries approach to one's media. Kodi does allow one to add multiple named media sources for each type of media but it is not used, as far as I can tell, outside of file browsing. So whereas Kodi can have many 'Sources' but one library per media type, these servers allows one to have several libraries.  Libraries such as Classical, Pop, Gospel, Reggae, Oldies , 80's, 90's, 2000's etc. In the apps each library shows up separately so it is easier to filter one's music. However, when imported into Kodi, all libraries are combined.

The custom properties sounds like a brilliant approach. I was hoping the separation would be in source feature as that seems the appropriate place. I consider VideoTags method being used, for videos, as a hack. Video Tags were meant to be a way for one to create their own non standard collections. A way to avoid polluting Movie Sets primarily while allowing user to create their own collections. I suspect it was used for videos because it was available, not because it is ideal. It is itself now polluting user made collections.

I do use genre to separate my music using audio nodes, but sometimes even music of the same genre are separated eg. 80's, 90's 2000's etc.

The critical thing here is centralization. One source at home and on the road. As it is now, Kodi by itself does not allow that.

Cheers,
LongMan

[DaveBlake]

I guess I just live too much a stationary life, not only staying in one location, but I'm even happy with Kodi in one room!!! My quality audio system isn't mobile, and if I can't have the shear pleasure of it I don't want to listen. But that's just me.

From my viewpoint all of Kodi's databses belong to the user and hence they can do with them whatever they like as long as they don't ask team Kodi for support to sort out any mess they may make. As for the "unsanctioned" plugins that access the db directly, I just wish that the authors would come and work with me on improving the JSON API to support their needs if it is lacking in some respect. Otherwise use JSON, no need to get down and dirty with the data. [That is just for other readers that may happen to come by, not anything specific to you].

Separate libraries, separate sources.... just different terms for cutting up the cake really. Again I'm here if the plugin authors would like to talk to me about how when loading their "libraries" into Kodi music library they could be indentified as separeate sources (I like to think I'm an approachable guy). That is really what you want.

Kodi does allow one to add multiple named media sources for each type of media but it is not used, as far as I can tell, outside of file browsing.

Well it is used now, by music anyway. Sources are very flexible, a source can be a number of descrete folders, a folder can be in more than one source. But knowing nothing about how other things add media to Kodi I didn't consider any requirements to  support them.

Yeap genre alone is not adequate to partition up an extensive music library. And I'm not sure about custom properties either really, any data unique to Kodi and separate from the media is weak. It is also tedious for the user to set up e.g. mark these 100 albums as XXX, another 500 as YYY etc. A good feature would make use of inherent media properties, and provide the user with ways to access their music using them with little to set up.

It is kind of Emby's fault that it obscures that source(Kodi)/library(Emby) when it loads music into Kodi, but understandable since acutally using sources as a filter is new and I'm sure their approach was designed some time ago and around how video works. Perhaps someone at Emby (or Plex) will be interested in catching up with new possibilities.?

[scott967]

I'm not sure I understand the advantage of a multiple library approach unless the semantics change between libraries.  I could see this might help in classical vs other but is Emby client for example making use of this?

scott s.
.

[DaveBlake]

I actually think truely separate libraries (as in separate databases) is a weak approach: what about when you would like to see all your music? What about things in more than one library, do you duplicate the data?

I suspect, but don't know, that Emby/Plex have one database and that libraries work like simplistic (only one folder path per library) version of sources in Kodi, but that they have had filtering by it for longer. Hence the user feels like they support "separate libraries" as something different to Kodi.  But hey, I know nothing about them for sure of that is just noise from me.

The trick is is changing how they populate Kodi music library to make full use of what filtering Kodi now supports.

[sualfred]

+1 for tag support for the music DB. 
In Emby users do split their music to different libraries like "concerts", "albums", "kids music", etc.
That will give us the option to mark the items correctly and to display different libraries like we already do with the video section.



@angelblue05 
Maybe you want to join the discussion.

[angelblue05]

+1 for that feature.

[DaveBlake]

Ah @sualfred @angelblue05 you heard the drums.... good 

No idea what Emby does,  but other than wait for implementation of custom properties  (which I still have reservations about) and then using that, any way Embry could just get into using source when it populates the library? How does it work now that results in same path for everything regardless of library?

In Emby users do split their music to different libraries like "concerts", "albums", "kids music", etc.

Yes sure, but is that really separate databases or some kind of internal indexing?

Don't assume I use or have read anything about Emby, I don't have the time, tell me what I need to know.

[LongMan]

Emby, Plex and Jellyfin all support multiple folders per library (source in Kodi). Until your recent work Kodi had no way to do the separation.

In terms of having all music or all tv shows etc together, I have used naming schemes to achieve that.

I understand why you would want to use properties of the files rather than something external. I appreciate that. I used to be annoyed every time I had to move files (change drives) and lose my watch status. Now with Emby I think, not sure about, they used the tvdb, and imbd ids to preserve watch status. Music doesn't have something similar so I understand the use of a hashtag, especially to preserve data.

I see you have source and source path tables. I was thinking that a source tag could placed somewhere there. The hashtag i agree is essential but for the source separation could be done with tag.

angleblue05 and sualfred are the primaries of the Emby plugin. It is nice to see them chiming in. Maybe they could provide some operation details that could help. They could also explain why all music files have a single path even though they are from libraries.

Cheers,
LongMan

[sualfred]

I cannot tell you how they are handled exactly in the core of Emby, but from a administration panel view they are real unique libraries. You create a database, select what content does it store (movies,tvshows,music,mixed,audiobooks,musicvideos,etc) and then you just add paths to it. Voilá. 
Each library has its own "parentID" so this database ID that can be used for API usage to filter stuff. If I drop the parentID from a API call, it will return all movies instead of the movies of "HDR" for example.

Anyway, long story short, with Emby for Kodi @angelblue05 does store the library name in the "tag" field for videos. That's all we need for the music database. She also uses the tag field for the "favourites" section that is splitted into content types.

[dubwat]

+1 for this feature (if I understand the OP correctly).  I don't use Emby.

I can think of 2 examples off the top of my head:  
- I'm from Ireland and but I don't have an 'Irish' genre since Irish musicians make rock, pop, classical music etc.  It would be nice to add an 'Ireland' tag and make a smart playlist from that.  'Ireland' is a very loose definition.  If an actor took a holiday here, I might add his/her movie/album 
- I prefer female singers over male singers.  It would be nice to add a 'Female singer' tag to songs/albums I particularly like and make a smart playlist from that.  Others might make 'Guitar solos' or 'saxaphone solos' etc.

I know I should probably do this before I add music to kodi but my favourite singers change over time etc...  Also, I'm hoping to use Kodi as my main source of music going forward (based on the work @DaveBlake has done so far - thank you!).  Movies & TV shows are already moved but I'm in a transition phase at the moment with music and keeping 2 copies of my music on my PC (Musicbee) and vero 4k+ (kodi).  

FWIW, in videos, there is an add-on called manageTags * that allows one to select video files individually and add it to existing playlists.



* Adds a context menu entry for movies and tvShows (under manage) to allow the selection of tags

[DaveBlake]

I can think of 2 examples off the top of my head:  
- I'm from Ireland and but I don't have an 'Irish' genre since Irish musicians make rock, pop, classical music etc.  It would be nice to add an 'Ireland' tag and make a smart playlist from that.  'Ireland' is a very loose definition.  If an actor took a holiday here, I might add his/her movie/album 
- I prefer female singers over male singers.  It would be nice to add a 'Female singer' tag to songs/albums I particularly like and make a smart playlist from that.  Others might make 'Guitar solos' or 'saxaphone solos' etc.

Associating artists with a place, or some other phantom property is easily done via NFO files. For example have "Irish" as an artist theme or style.

Artist gender is already scraped by the Universal Artist scraper, and can be used in both dynamic filtering and smart playlists. Not a property you need to add manually (but you may need to re-scrape to populate).

So both your examples are already covered by existing functionality.

That isn't saying I won't still consider adding a custom property facility, just do we really need it on top of the properties artists and albums already have an users don't use. Made worse by the fact that Estuary does not show most of this data, so I forgive users for not knowing and using. Use Confluence instead, or any other skin that does present all the music data.

[DaveBlake]

I understand why you would want to use properties of the files rather than something external. I appreciate that. It used to be annoyed every time I had to move files (change drives) and lose my watch status. Now with Emby I think, not sure about, they used the tvdb, and imbd ids to preserve watch status. Music doesn't have something similar so I understand the use of a hashtag, especially to preserve data.

With v17 and before there was no way easy to save the dynamic music data that was set during Kodi use i.e. playcount, last played an user rating. A fresh install, or dropping a source and rescanning, meant losing this data. Moving files also lost this data unless you messed directly with the DB or used path substitution.

With v18 this song playback history (+ rating but I had to find a term for it) can be exported/imported. The import matching is based on song properties like tile, artist, album, mbids etc. so values will be reapplied to the correct song even if the music file is in a new location.

@ LongMan the music library is even better than you think

I see you have source and source path tables. I was thinking that a source tag could placed somewhere there.

It is not just those tables involved, but in principle a means to populate the necessary data could be provided. I would like to explore that approach.

[LongMan]

LongMan the music library is even better than you think

 Indeed. Much better.

BTW. I think the main problem the addon authors have with JSON is speed. Writing to the database directly is significantly faster.