Genres, moods, themes and styles

[mherger]

> My plans right now is to extend the possibility to store tags from local
> files and make them browseable. A lot of files in my collection have
> mood tags, some files have as much as 10 moods stored, so your solution
> to create a library per mood seems unfeasible.

Why would this not be feasible?

If you don't want to flood your music menu with those items, your plugin
could provide an additional "Moods" menu item under which you'd have the
various moods?

--

Michael

[mherger]

> Michael, not sure if anything has changed since I last looked at
> browsing (in Custom Browse plugin I think). One issue I had back then if
> I remember correctly is that I more or less had to duplicate the logic
> in Slim/Menu/BrowseLibrary to be able to show an artist or album menu
> that were additionally filtered by information known by my plugin. When
> looking at the BrowseLibrary code I noticed that you had to modify it
> when you added the Virtual Library functionality so lauret will probably
> get the same problem as I had. Not sure if it’s possible but I think it
> would be very useful if is was possible to somehow hook in your own
> filtering criteria’s in the BrowseLibrary functions for at least
> artists, albums and songs. That way plugins that add new browse behavior
> could become more consistent with the standard browse menus. There is a
> lot of functionality in BrowseLibrary which you likely want to have even
> if the lists are filtered so fewer items are shown.
> If you don’t have the time/interest to look at it yourself maybe this
> would be suitable for a pull request if laurent finds a good solution
> for it ?

This certainly could be expanded. But it's a can of worms, trust me!
Submitting a pull request won't be good enough. A contributor should be
willing continue to work on such a change as people will discover more
issues and unwanted side-effects.

But before you go down that rabbit hole it would probably be worth
looking into what is possible already. I mentioned it in a response to
lauret that if you were happy with just Category -> Artist -> Albums,
this should already be possible using what we have. Eg. you could have a
menu My Music/Moods/Sleepy/Artists/Albums (or skip the artists right away).

--

Michael

[mherger]

>> A lot of files in my collection have mood tags, some files have as much
>> as 10 moods stored, so your solution to create a library per mood seems
>> unfeasible.
>>
>
> I wonder if it would be possible to adjust the browsing logic in the
> core so you for each library optionally can specify a parent menu which
> the library should be placed inside ?
> That way you would be able to specify that your libraries should be
> placed inside a “Moods� menu and that would maybe make the virtual
> libraries approach a bit more feasible since you mood libraries wouldn’t
> be showed together with all other virtual libraries.

As I just mentioned that should already be feasible with today's tools.
Look at the "Additional Browse Modes" menu.

--

Michael

[erland]

>> A lot of files in my collection have mood tags, some files have as much
>> as 10 moods stored, so your solution to create a library per mood seems
>> unfeasible.
>>
>
> I wonder if it would be possible to adjust the browsing logic in the
> core so you for each library optionally can specify a parent menu which
> the library should be placed inside ?
> That way you would be able to specify that your libraries should be
> placed inside a “Moods� menu and that would maybe make the virtual
> libraries approach a bit more feasible since you mood libraries wouldn’t
> be showed together with all other virtual libraries.

As I just mentioned that should already be feasible with today's tools.
Look at the "Additional Browse Modes" menu.

--

Michael

Sorry, I missed part of the Slim/Plugin/ExtendedBrowseMoods code when I looked at it on an iPad yesterday.
You are correct that if one wants to accomplish a My Music/Moods/<Mood>/<Artist>/<Album>/<Track> structure using virtual libraries should work perfectly. When I look at this again it looks like libraries would be the best way to accomplish the browse menus as long as we are talking about top level menus like Moods, Styles, Themes and similar. The tag values can still be stored in separate table structure similar to genres if one wants that and just generate the libraries based on that data after the scanning is complete, the alternative would be to fill the library_track table continuously during scanning and not have the tag values anywhere else in the database than I the library name.

Is the _hitlist based menus and their usage of params/search parameter a way to accomplish the reusability with extended filtering I asked for in my previous post ? Or is it just an example of the code duplication needed if you want to reuse code in BrowseLibrary but want to filter the lists more ? I’m only able to look quickly on this from an iPad at the moment so I apologize if these are stupid questions, not easy to view and analyze code on an iPad.... :-)

[Blackfiction]

My plans right now is to extend the possibility to store tags from local files and make them browseable. A lot of files in my collection have mood tags, some files have as much as 10 moods stored, so your solution to create a library per mood seems unfeasible.

What I am trying to do now is to stick as closely as possible to the tag handling for genres, but then for the tag mood. A stretch goal would be to making it configurable, so you can also choose to select other tags to store and browse.

Roland is indeed working on automatic genre recognition and storing it subsequently in the database.

This looks promising and I hope it can be realized. I do not use the mood tag but i use the style tag to store subgenres. For example, genre=Jazz, style=Hard Bop. Currently using custom browse and custom scan. Would be great if there is some more support for tags in LMS as erland mentioned that custom browse and custom scan will not be supported anymore.