> I'm not sure what you mean by library view, but it's about all tagged
> search commands
7.9 introduced a feature I often refer to as library views: you can
define to only work on a sub-set of your total collection. Eg. exclude
your kids' music. If you're not familiar with it, then you likely don't
use it ;-).
> interesting is also that after input of a meaningful term sometimes / at
> first request often a more correct/correct number is returned. however,
> if i'm adding at the end for example => "xxx" no more results come, but
> the count remains on the old resault value. So first we thought of a
> cache problem.
Same here. At first it looked good, then later on there was some kind of
constant value returned. Server side caching might very well be the
reason. I'll look into this.
> only current solution is to use "search" command, not filter based
> search?
Yes, I'd use that for now. It's optimized for search speed, as it's
being used for the web UI's "live search".
--
Michael
> search commands
7.9 introduced a feature I often refer to as library views: you can
define to only work on a sub-set of your total collection. Eg. exclude
your kids' music. If you're not familiar with it, then you likely don't
use it ;-).
> interesting is also that after input of a meaningful term sometimes / at
> first request often a more correct/correct number is returned. however,
> if i'm adding at the end for example => "xxx" no more results come, but
> the count remains on the old resault value. So first we thought of a
> cache problem.
Same here. At first it looked good, then later on there was some kind of
constant value returned. Server side caching might very well be the
reason. I'll look into this.
> only current solution is to use "search" command, not filter based
> search?
Yes, I'd use that for now. It's optimized for search speed, as it's
being used for the web UI's "live search".
--
Michael