Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Matt]

When Media Center processes searches, currently it does it in two steps.

First, it applies any rules like "bob dylan" or "hard rock".

Second, it applies post processors (things that start with ~) like ~n=100 to limit to 100 tracks.

We recently changed the search engine so that we _could_ do all of this in one step.  That way, the order, parenthesis, etc. would be honored for special processors.

Would this be a good change?  It would break some existing smartlists since ~n=100 rock would return less than 100 songs after the change.

However, it also allows new things like this example to get 200 songs:
rock ~n=100 or folk ~n=100

Thanks for any advice.

[glynor]

I think it sounds fine.  Basically, to fix post-processed search rules you'd have to enclose the search in () and then add the ~n=100 to the outside of the ()?

Could you show a couple of before/after examples to make sure we fully understand what we're getting?

[ghappe-MC]

About search engines in general:

I.M.H.O any search engine should come, for syntax, as close to the world standard for queries, being native SQL  , as possible, and therefore the changed version would be better, or more generic.

But now that we're at it, any change of adding the functionality of a drop-down list box giving access to all your quiries / smartlists? ?

Grtz,

Guido

[gappie]

it sounds like a great idea. but i guess it takes some experimenting to see what the drawbacks are.

[hit_ny]

We recently changed the search engine so that we _could_ do all of this in one step.  That way, the order, parenthesis, etc. would be honored for special processors.

If this means it executs as written, then i'm all for it.

Would make smart lists more intuitive, following the train of thought so to speak.

What about modifiers, those uber class citizens ?

However, it also allows new things like this example to get 200 songs:
rock ~n=100 or folk ~n=100

i interpret this to mean

- find all tracks with rock in them (for all searchable fields)
- give me 100 random tracks from that list

or

- Also find all tracks with folk in them (for all searchable fields)
- give me 100 random tracks from that list

for a total of 100 each of both random rock  & folk.

sounds fine to me

Would this be a good change?  It would break some existing smartlists since ~n=100 rock would return less than 100 songs after the change.

- give me 100 random tracks
- out of those, give me all tracks with rock in them (for all searchable fields)

i might expect this to give random amounts of tracks with rock in them. But the current system has to be user friendly that way isnt it

Isn't to preferable to say

rock ~n=100

instead.

to me this makes the result more predictable, therefore easier to construct more complicated searches.

Now the modifiers are not so uber anymore and thats a good thing in my books, otherwise it can get difficult to figure out which modifier is firing off (for smartlists with many modifiers in them). I bet it would make things a lot easier for that user formerly-known as tab (is he called the 'bat' now ?)

This needs more playing with, thats all i can think of, at first glance.