Feature Request: Ability to create auto playlists based on genre/artist/track/etc.

[issuemover631]

Issue by deathspawn Friday Apr 28, 2017 at 02:13 GMT Originally opened as https://github.com/Libresonic/libresonic/issues/369

---

This is one feature I have wanted to see created outside of Google Play Music. I'm not sure how to even go about creating it myself, but it could have options to either check local tags, or check against an online database like last.fm.

Basically how I envision it working is loading up Black Sabbath, hitting an option somewhere named start auto playlist or something, then the playlist fills up with 10 or so songs by Ozzy Osbourne, The Doors, Stone Temple Pilots, etc.

[issuemover631]

Comment by fxthomas Sunday Apr 30, 2017 at 17:27 GMT

---

Right now we have the option to start an artist radio based on similar artists from Last.fm :

I'd love to have real support for smart playlists too, this has been on my wishlist for a long time.

[Dalvany]

What about creating playlist based on lucene query?

[muff1nman]

@Dalvany I think has been suggested before and I like the idea. Might also be able to use sql syntax too.

[Dalvany]

@muff1nman I'll open an issue on this then.

[tesshucom]

It is almost impossible to accept Lucene queries from outside. Only a narrow range such as English or a similar language of English can be implemented easily.

Unlike the search for newspapers and books, the target language of music is not necessarily narrowed down, so it is necessary to consider internationalization to some extent. When dealing with various languages ​​other than English, you need to keep in mind the design of the Analyzer and documentation.

If you mainly use StandardAnalyzer like Airsonic, Standard Analyzer will searche that use both words and n-grams. It's almost impossible to do a search with a human-readable query.

That's why Lucene uses Analyzer for indexing and searching. An index is created from the result analyzed by the Analyzer, and the input value is analyzed by the Analyzer at the time of search, and a query that matches the index specifications is automatically generated. If you implement it by ignoring this, tragedy like Subsonic will occur. People in some countries appear to have no problems, while people in some countries cannot use it. Due to this complexity, Lucene queries are mostly internal. It is not the same as SQL for which standards exist.

If you are considering internationalization suppot (or international music library suppot ), you should not consider entering a query from outside. There are other problems even if you exclude that. ex) you need a mechanism to filter dangerous syntax or characters.

If you prefer some sort of query-like syntax input, you'll need to write your own parser. I don't want such a proprietary one, but I did it when I fixed UPnP search to work properly on the clone server. UPnP search query can be converted to Lucene search query, and search can be performed. If you don't mind the effort, such a design is possible. Whether it's worth it, or having core implementors, is another topic.

[Dalvany]

For "dangerous" syntax and/or characters, I don't know what you have in mind but you can do, for characters, ascii folding.

[tesshucom]

The easiest entry is to get the filter implemented internally into the external input. There is also an escape function.Scrutinizing the syntax is difficult. The same topic as the SQL injection countermeasures begins.

Big issue, as already mentioned, is that backend design will be limited in order to achieve human-readable input. There are disadvantages to exposing the background document design to the outside world. If we want to search by very simple input, we can only create a very rudimentary index. It's easy if you only support prefix match or exact match. However, the size of the index is large, search accuracy is lower and the search speed is slow. Technically, it's a big setback.

[Dalvany]

In your previous comment, what do you mean by 'query-like syntax' ?
Lucene do have query syntax that I believe is human readable and provide several query parsers (see simple or classic).

[Dalvany]

To better handles foreign languages there's an ICU analyzer

[tesshucom]

Text Segmentation: Tokenizes text based on properties and rules defined in Unicode.

Unknown words are split as described in the documentation. This is not unique to ICUAnalyzers, as most Analyzers behave similarly when they encounter an unknown word. There are many other ways to control segment rules to balance sizing and accuracy.

To search for a segmented string, the input string must be segmented during the search. It is almost impossible for the user to do this manually. (Of course, the search itself is possible if segmented properly.) This is why the analyzer is used both during indexing and searching.

Lucene query should be generated using the tokens that passed through Analyzer. Perhaps there seems to be a misunderstanding about this search engine architect.

Lucene's introductory document uses the simplest case to describe the query. In fact, the internally used Lucene query is not as human-readable as SQL. If the user wants to enter control syntax, he needs a parser specifically for that purpose. It must be converted to Lucene query internally using its own parser.

[Dalvany]

I know about applying analysis at query time.
My analysis needs is quite simple : tokenization and folding because when I'll search I'll type words without diacritic symbols.
What do you mean by "the internally used Lucene query" ? Do you mean the Query object and subclasses ?

[tesshucom]

It refers to the query automatically generated by appropriate processing after Analyze.

muff1nman mentions SQL syntax.

@Dalvany I think has been suggested before and I like the idea. Might also be able to use sql syntax too.

The idea that the user inputs directly the Lucene syntax from the external interface and searches is not realistic. I had explained about that.

(Although web systems that accept SQL syntax from outernal are rare enough) Lucene queries are even more rare idea because they are not designed for external user use. The request to do a search is separate from the request to use the control syntax externally. Each needs a different design.

[Dalvany]

query automatically generated by appropriate processing after Analyze I don't really understand this sentence, if you have a link so I can get the whole context.
I disagree with The idea that the user inputs directly the Lucene syntax from the external interface and searches is not realistic. looking at Spotify query language, except for ranged query (which is close enough from Lucene's anyway), it's almost the same as Lucene classic query language.
Perhaps, it would be better to continue this conversation in a private manner ? Because I feel that we don't get each other's point since we both keep saying the same things.

[tesshucom]

Of course, you can do the same by writing a parser that looks much like Lucene's traditional query language. Have you seen the source code for Spotify?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Thank you for your contributions.