museeks icon indicating copy to clipboard operation
museeks copied to clipboard

Advanced search

Open vprigent opened this issue 7 years ago • 11 comments

When you right click on a track, you can search for the name of the artist and for the album of the track.

Even if it looks good on first sight, I've experienced some case where the filter is too broad. Searching for the artist "Her" gives me 197 track over 3200 for example.

We should perhaps look for a way to specify on which field we want to search ? Or open a dropdown that allows us to specify what kind of thing we are looking for ? ( Kind of I'm looking for an artist, an album, a track or i'm feeling lucky)

vprigent avatar Oct 16 '16 16:10 vprigent

Hello,

Tanks for opening this, this is a known issue. Mostly due to the fact that we don't separate albums/artists in database.

The idea of filtering by album/artist would improve it, but not fix it. "The Do" would show "The Doors" too and so on.

The implemation/improvement of this is open to discussion, I'll post my ideas here when I have time.

martpie avatar Oct 16 '16 21:10 martpie

You are right. And as a drowback, restrictive search for "The Do" would not give us "The Do ft IDK"

I should take a look at how are handled tracks ..

vprigent avatar Oct 18 '16 10:10 vprigent

We use NoSQL and a Track collection: there is no Album collection or Artists collection.

That's basically the main problem.

martpie avatar Oct 18 '16 11:10 martpie

However, we save the artist, the album, it should be possible to search based on these keys no ? ( I never touched NoSQL ... )

vprigent avatar Oct 18 '16 12:10 vprigent

Yes of course, we could (and I will implement it), but two albums can have the same name. So we would need to filter by artist AND album, and then, there's two albums of the same artist with the same name ("greatest hits" for example), and then we're screwed, and then we cry.

The best idea would be to index albums in database as well as artists, so we could loop up for "the album with this _id".

But it'd get a bit complicated with NoSQL and the current state of the app.

martpie avatar Oct 18 '16 12:10 martpie

Imagine we had the ORM + models system of Laravel, it'd be extremly powerful (and this issue would become a trivial problem).

Maybe we need a database with SQL and joins, but this'd a gigantic work.

martpie avatar Oct 18 '16 12:10 martpie

Hum ... I see ... Search queries become much more complex than I thought ^^

vprigent avatar Oct 18 '16 12:10 vprigent

Putting aside how we implement it for a sec, I think we should support a search syntax similar to google, github, slack, and many others. So, in our case, you'd be able to do something like artist:"AC/DC" album:"Back in Black". Then in the contextmenu, we'd just have to put the right syntax in the search bar.

dkniffin avatar Nov 23 '16 15:11 dkniffin

I'm not so sure about that. It's great if you are a developer or at least someone who has advanced knowledge on computer but most of the users does not want to have to specify what they are looking for, as in google.

It can be a start; but doing some kind of search engine using weight depending on columns would be accurate enough and easier for the final user

vprigent avatar Nov 23 '16 15:11 vprigent

Hmm, that's a good point about most users being dumb :P Maybe we add a little UI, like google does, that allows you to put in Artist/Album/Song or whatever, and it updates the search bar to reflect that.

Edit: to be clear, if you don't do artist:, etc, it would be treated as a search across all fields. So if you just enter "Back" it'll come up with results in the album "Back in Black", as well as the artist "Backstreet Boys", and any songs that have "Back" in them.

dkniffin avatar Nov 23 '16 16:11 dkniffin

@martpie I think that advanced search syntax is a great idea, even if there's no UI. Also, this issue is almost four years old, bumping for visibility.

binyamin avatar May 06 '20 18:05 binyamin