[geeohgeegeeoh]

My partner and I share a music purchasing account. In google play, we can maintain different playlists but we still see each others music. Mostly this works, but there are days she wants to not be distracted by the 1960s pop I collect, and I don't always want to wade through her collection of new-wave post punk. In Kodi. we just live in the same universe.

She asks: why can't we have two databases pointing to the same back-end filestore, but 'prune' it to show only the things we each want? Then we'd both feel like we had 'our' music, but it wouldn't require reboot or two instances of shared music. I mused about this, and decided one database, but with 'mine, yours and ours' flagging would do this.

In google, this would be pretty hard. But in kodi, I think this might actually be pretty simple. EG, there could be an arbitrary tag, which was used as a filter select in remotes, so that her (yatse, but it would work for anyone) remote only lists her+common, and my instance only lists mine+common.

If this is already implemented, I'd love to know!

[nickr]

You can do all sorts of things with smart playlists.

[zag]

Can also be done with http://kodi.wiki/view/Audio_nodes

[geeohgeegeeoh]

Can also be done with http://kodi.wiki/view/Audio_nodes

Thanks! -So, if eg I use a tagfield in the songs for 'hers' 'ours' or 'mine' then I can use this to show only things which match by tag? I guess if I have a tagfield which is spare, I don't have to 'create' one, just populate it.

According to http://kodi.wiki/view/Audio_file_tags there is a limited set. I could re-use 'rating' %R which is obviously not relevant. PG/A/R would be at least amusing, to separate into three groups.

Or did you mean construct state outside of the ID3 tagspace, held in Kodi database per track/album?

-G

[zag]

Personally I'd put them into a separately filesystem folder, and filter using the CONTAINS PATH feature.

Have not tried this myself yet, but let me know how it goes, the system should be infinitely customizable now with the new Node feature

[geeohgeegeeoh]

Thanks for the replies. nodes turned out to be almost EXACTLY what I needed.

Because the path attribute relates solely to songs and not albums (movies being single things, there is no equivalent to the album I can see) the path= trick to separate dirs didn't work well but I have overloaded ratings and used audio nodes to create a hers, mine, ours model.

I can use sqlite3 to cut the value into the DB, and have a project to write some nginx .cgi code to present a table of the albums/songs and let this be set.

Thanks for the help! much appreciated the pointers.

[geeohgeegeeoh]

Turns out the nodes don't expose well in Yatse. you can see them in the TV screen view for remote control, but if you use yatse blind, there is no clear mapping into the view available there.

Profiles might work, but I also think Yatse lacks direct support for Profiles.

Having invested in tagging the albums, I think I'm probably going to tear the music into three sub-states by directory, map to profiles, and then put up a distinct kodi instance behind each so I can avoid the problem until code moves forward.

Just in case: would the profiles/nodes information actually propagate properly in the JSON interface kodi exposes? Is this something which yatse could exploit right now, with re-coding?

For example, if I hacked the existing library/music/*xml files, instead of adding my own, would that translate into the view exposed to yatse over JSON?

[zag]

Just in case: would the profiles/nodes information actually propagate properly in the JSON interface kodi exposes? Is this something which yatse could exploit right now, with re-coding?

Good question, I have no idea really but I'm guessing not for now.

Nodes are simply a way of organizing things in Kodi, I think maybe the YATSE developer might be able to look at it though.

I know some remotes have categorized things like A-Z independently from Kodi

[DaveBlake]

Custom nodes are great way to organise things in Kodi, but they are not propagated by JSON. It is also difficult to see how they could be. Generally remote apps use JSON to grab all the basic library data to a local cache, then present it to the user using its own design of UI. The equivalent of custom nodes in a remote (Yatse or Kore) would be great, but I suspect it is quite a bit of work.