PDA

View Full Version : Full-text search missed results



dolodobendan
2018-02-20, 12:07
My niece wanted to listen to "99 Luftballons", so I ran a search for "99". I found three songs, but not "99 Luftballons". Because I know I have this awful song, I clicked "back" and "done" again (Squeezeplay on Windows 10) and suddenly there are plenty results, the dreaded "99 Luftballons" included.

I always had the feeling that this happens sometimes, but blamed it on misspelling or whatever. But there's only so much you can screw up with "99" and the few results I got had 99 in the title, too.

I could not reproduce this (yet) and the server log doesn't show anything unsual (=literally nothing for the last two days). Is there a way to track this down?

mherger
2018-02-20, 22:28
> I could not reproduce this (yet) and the server log doesn't show
> anything unsual (=literally nothing for the last two days). Is there a
> way to track this down?

Hmm... I hoped it would log a warning about this being a "popular term".
You could enable logging for plugin.fulltext to get more information.

--

Michael

dolodobendan
2018-02-21, 06:11
> I could not reproduce this (yet) and the server log doesn't show
> anything unsual (=literally nothing for the last two days). Is there a
> way to track this down?

Hmm... I hoped it would log a warning about this being a "popular term".
You could enable logging for plugin.fulltext to get more information.

--

Michael

plugin.fulltext already is on "warn", I'll set it to debug.

May I ask how "popular term" is defined? Is it generated by the Full-text search's database, is it because of the search string's length...?

mherger
2018-02-21, 08:45
> May I ask how "popular term" is defined? Is it generated by the
> Full-text search's database, is it because of the search string's
> length...?

It's terms which would return more than 500 items. Track numbers or
years can easily be part of them. But 99? I'd be surprised.

FWIW: I do have 99 Luftballons in my collection. And I'm seeing the same
behaviour, too.

--

Michael

dolodobendan
2018-02-21, 10:05
> May I ask how "popular term" is defined? Is it generated by the
> Full-text search's database, is it because of the search string's
> length...?

It's terms which would return more than 500 items. Track numbers or
years can easily be part of them. But 99? I'd be surprised.

FWIW: I do have 99 Luftballons in my collection. And I'm seeing the same
behaviour, too.

--

Michael

I did some testing with debug level logging enabled.


This time I only got one result for "99" in the first searches.
There are three searches logged for each "1999" and "2000" while I only searched once.
(Same with "123", there was only one search while two were logged.) (I had to cut that to post this here, see attachment)
(There was one search for "122" and only one logged. That's what I would expect.) (I had to cut that to post this here, see attachment)
The last search for "99" gave me plenty results.


Why do some searches get a "w10"?





[18-02-21 17:46:16.9290] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): 'w10:99*'
[18-02-21 17:46:16.9294] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? no
[18-02-21 17:46:16.9307] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track w10:99*' ORDER BY fulltextweight
[18-02-21 17:46:17.0261] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)
[18-02-21 17:46:38.7255] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): 'w10:99*'
[18-02-21 17:46:38.7260] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? no
[18-02-21 17:46:38.7273] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track w10:99*' ORDER BY fulltextweight
[18-02-21 17:46:38.8554] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)
[18-02-21 17:46:56.4073] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (251) Searching for very popular term - limiting to highest weighted column to prevent huge result list: 'w10:98*'
[18-02-21 17:46:56.4569] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): 'w10:98*'
[18-02-21 17:46:56.4573] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? no
[18-02-21 17:46:56.4587] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track w10:98*' ORDER BY fulltextweight
[18-02-21 17:46:56.8271] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)
[18-02-21 17:47:24.5352] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (251) Searching for very popular term - limiting to highest weighted column to prevent huge result list: 'w10:97*'
[18-02-21 17:47:24.5523] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): 'w10:97*'
[18-02-21 17:47:24.5528] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? no
[18-02-21 17:47:24.5541] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track w10:97*' ORDER BY fulltextweight
[18-02-21 17:47:24.8855] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)
[18-02-21 17:48:00.0133] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): '2000'
[18-02-21 17:48:00.0138] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? yes
[18-02-21 17:48:00.0161] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track 2000' LIMIT 500
[18-02-21 17:48:00.6963] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)
[18-02-21 17:48:01.1529] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): '2000'
[18-02-21 17:48:01.1533] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? yes
[18-02-21 17:48:01.1546] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track 2000' LIMIT 500
[18-02-21 17:48:01.4384] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)
[18-02-21 17:48:01.7764] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): '2000'
[18-02-21 17:48:01.7768] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? yes
[18-02-21 17:48:01.7781] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track 2000' LIMIT 500
[18-02-21 17:48:02.0843] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)
[18-02-21 17:48:37.7412] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): '1999'
[18-02-21 17:48:37.7417] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? yes
[18-02-21 17:48:37.7430] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track 1999' LIMIT 500
[18-02-21 17:48:38.2301] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)
[18-02-21 17:48:38.7059] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): '1999'
[18-02-21 17:48:38.7063] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? yes
[18-02-21 17:48:38.7076] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track 1999' LIMIT 500
[18-02-21 17:48:39.0490] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)
[18-02-21 17:48:39.3149] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): '1999'
[18-02-21 17:48:39.3153] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? yes
[18-02-21 17:48:39.3167] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track 1999' LIMIT 500
[18-02-21 17:48:39.6789] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)
[18-02-21 17:52:36.4320] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): 'w10:99*'
[18-02-21 17:52:36.4325] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? no
[18-02-21 17:52:36.4339] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track w10:99*' ORDER BY fulltextweight
[18-02-21 17:52:36.5627] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)
[18-02-21 17:54:14.4884] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (251) Searching for very popular term - limiting to highest weighted column to prevent huge result list: 'w10:91*'
[18-02-21 17:54:14.5371] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): 'w10:91*'
[18-02-21 17:54:14.5375] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? no
[18-02-21 17:54:14.5390] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track w10:91*' ORDER BY fulltextweight
[18-02-21 17:54:14.8251] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)
[18-02-21 17:54:52.7395] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (300) Search token (track): 'w10:99*'
[18-02-21 17:54:52.7400] Slim::Plugin::FullTextSearch::Plugin::parseSearchT erm (301) Large resultset? no
[18-02-21 17:54:52.7413] Slim::Plugin::FullTextSearch::Plugin::createHelper Table (200) Fulltext search query (track): CREATE TABLE tracksSearch AS SELECT id, FULLTEXTWEIGHT(matchinfo(fulltext)) AS fulltextweight FROM fulltext WHERE fulltext MATCH 'type:track w10:99*' ORDER BY fulltextweight
[18-02-21 17:54:52.8365] Slim::Plugin::FullTextSearch::Plugin::dropHelperTa ble (207)

dolodobendan
2018-02-21, 14:17
even when Michael didnt see edits...

I'm sorry, but I'm not sure what you mean by that.


I've searched on all my devices over the gui and the first findings are always the same - and 99 from toto is the whole trackname and its included every time.

It's not always the first search but occurs randomly. As it is with the results: Today I got one, three and "more than five" results (maybe they differed, too?) for the same search string. And with both one and three results, none of it was "99 Luftballons".

kidstypike
2018-02-21, 14:31
I'm sorry, but I'm not sure what you mean by that.

Michael doesn't use the web interface to read these groups, so he doesn't see or even know about "edits" .

dolodobendan
2018-02-21, 15:12
Michael doesn't use the web interface to read these groups, so he doesn't see or even know about "edits" .


Michael only sees the original untouched Answers (they are sent to him over some tool) he didnt use the forum like we do...

How inconvenient. Thanks for the heads-up!

Well, here we go again, the unabridged (last two days) version:

24594

mherger
2018-02-22, 01:21
> - There are three searches logged for each "1999" and "2000" while I
> only searched once.

As this is the live search, the search action isn't triggered when you
hit the enter key, but on a timer. It can happen that a search is
triggered more than once under certain circumstances. Which explains why
performance is crucial for this search action. See below.

> Why do some searches get a "w10"?

The full text index stores multiple sets of data for every item. They
are put in different places, which later on would be weighted by their
importance. w10 has highest weight, w1 lowest.


And here comes the lengthy explanation of what I've found investigating
this very special case. Most likely (depending on your music collection)
this really is a rather special case:

- the keyword is very precise: you know what you expect
- the keyword is very short
- the keyword likely is very popular

Now that popularity thing might be a bit irritating. You probably only
have one single track with this name. Why would it be popular? Because
we're dealing with a full text index, covering not only titles, but lots
of other pieces of information, too. Eg. years, file paths, comments,
even MusicBrainz IDs.

Digging the 99 case in my collection I found a lot of these:

Comment: ExactAudioCopy v0.99pb5

Yep. Or something like that:

UFID: [ http://musicbrainz.org, ebe13618-bbdd-4ef3-9a91-9981602e528f ]

That -9981602e528f at the end would match, too, as our search term is at
the start of that "word".

That would explain the popularity of the search term. But why would an
obvious hit not show up, but some obscure, hidden data would win?

Now this is getting complicated. Many factors play a role: optimization
for speed (which might penalize this particular case), the nature of
full text search indexing not only the obvious data, but anything. And
some poor, deliberate choices. And bugs. Wow. Searching for "99" brought
quite a few issues to the light of day :-).

So there's some optimization going on because the search needs to be
fast. One of these optimizations is to try to limit the result set when
we risk to deal with a large number of hits. Eg. short search terms, or
single terms. In this case we're limiting the results to hits in the
highest priority column only (which explains the "w10:99").

If we know that we are still dealing with a large resultset (>500 items
found), the current implementation would only pick the top 500 items.
And that's where I would say there is/was a bug: we pick the top items
out of an non-ordered list... which means that even if the score of "99
Luftballons" was high, but it was far down the "randomly" ordered result
list, it would be cut off.

When the search is being run, it does weigh the results based on
aforementioned columns. If Nena's album had one track called "99
Luftballons", but another album had ten tracks with the EAC version
string in the comment, the latter might outweigh Nena, because the track
title on an album has weight 5, but the comment has 10x weight 1.

This is where a stupid decision kicks in: for whatever reason I decided
it was a good idea to put the MusicBrainz IDs in w10. Sure, it's a
unique value for every item. But nothing else should have them, right?
Therefore they should always bring up exactly one track, even if the
value is stored in the lowest priority column.

New builds are due out in a bit. Unfortunately my shiny new build system
still isn't installed in a decent place. Therefore I have to upload from
behind this super slow 10Mb connection... So please be patient.

Thanks for an interesting test/edge case! :-)

--

Michael

dolodobendan
2018-02-22, 06:11
New builds are due out in a bit. Unfortunately my shiny new build system
still isn't installed in a decent place. Therefore I have to upload from
behind this super slow 10Mb connection... So please be patient.

Thanks for an interesting test/edge case! :-)

Haha, you're welcome! :) And thank you for this deep insight of how the search works and design choices behind it!

One more question, if I may: Are all tags included in the search? Because the disc / track currently running has a tag called "Organization" set to "Interscope" and the search wouldn't find it.

I'm patiently looking forward to an updated version. And again, thank you very much!

mherger
2018-02-22, 06:35
> One more question, if I may: Are all tags included in the search?
> Because the disc / track currently running has a tag called
> "Organization" set to "Interscope" and the search wouldn't find it.

No, I wasn't even aware of such a tag.

See
https://github.com/Logitech/slimserver/blob/public/7.9/Slim/Plugin/FullTextSearch/Plugin.pm#L15
for what is being indexed

> I'm patiently looking forward to an updated version. And again, thank
> you very much!

It took hours to upload the builds, but they're up there:
http://downloads.slimdevices.com/nightly/index.php?ver=7.9

--

Michael

dolodobendan
2018-02-22, 06:59
> One more question, if I may: Are all tags included in the search?
> Because the disc / track currently running has a tag called
> "Organization" set to "Interscope" and the search wouldn't find it.

No, I wasn't even aware of such a tag.

See
https://github.com/Logitech/slimserver/blob/public/7.9/Slim/Plugin/FullTextSearch/Plugin.pm#L15
for what is being indexed

> I'm patiently looking forward to an updated version. And again, thank
> you very much!

It took hours to upload the builds, but they're up there:
http://downloads.slimdevices.com/nightly/index.php?ver=7.9

--

Michael

I hadn't even started to wait patiently... I'll give it a try, thank you!

I thought with "UFID: [ http://musicbrainz.org, ebe13618-bbdd-4ef3-9a91-9981602e528f ]" you were referring to a tag called "UFID". I get it now.

dolodobendan
2018-02-22, 07:23
I noticed two more things:


Sometimes I get "All Songs" at the bottom of the result list, sometimes I don't.
Sometimes (a different sometimes) I get "empty results", i.e. no cover, no text whatsoever, below "All Songs".


I wasn't able to narrow any of it down to when this happens, yet. But maybe it's connected to the other problem?

mherger
2018-02-22, 08:45
> I noticed two more things:

Oh, and I forgot one more thing... you'll have to run a rescan (no wipe
required) to update the FTS index to see the full effect of the changes.

> - Sometimes I get "All Songs" at the bottom of the result list,
> sometimes I don't.
> - Sometimes (a different sometimes) I get "empty results", i.e. no
> cover, no text whatsoever, below "All Songs".

How are you searching? Using the magnifying glass at the top, or one of
the search input fields?

--

Michael

dolodobendan
2018-02-22, 09:27
> I noticed two more things:

Oh, and I forgot one more thing... you'll have to run a rescan (no wipe
required) to update the FTS index to see the full effect of the changes.

> - Sometimes I get "All Songs" at the bottom of the result list,
> sometimes I don't.
> - Sometimes (a different sometimes) I get "empty results", i.e. no
> cover, no text whatsoever, below "All Songs".

How are you searching? Using the magnifying glass at the top, or one of
the search input fields?

--

Michael

I'm at my computer, so I'm using Squeezeplay's search function (the third entry in the main menu (1. My Music, 2. Radio, 3. Search...)). I almost never use the WebUI for controlling players.

I'll look into what iPeng, WebUI etc. do tomorrow after the rescan and keep you posted. Thank you!

dolodobendan
2018-02-23, 05:43
Oh, and I forgot one more thing... you'll have to run a rescan (no wipe
required) to update the FTS index to see the full effect of the changes.


The different results for 99 seem to be gone now, thank you.

I played around with the search a bit more: "99 luft" got me the empty results and this time I made screenshots:

24596
24597
24598

(That's Squeezeplay on Windows 10, the exe's date suggests it's v7.8.0r1034.)

Clicking on "Back" and "Songs" again and the results are displayed as they should.

I also tried the WebUI, here things look ok. However, I ran a search for "321" and got this disc as a result:

24599

I checked all other tracks on the disc for any "321" but couldn't find any reason for these results.

dolodobendan
2018-02-23, 07:09
I also tried the WebUI, here things look ok. However, I ran a search for "321" and got this disc as a result:


To clarify, I got other discs (or rather artists) with this search as well, but I don't know why they would be found, as there's no "321" in the tags.

mherger
2018-02-23, 07:20
> To clarify, I got other discs (or rather artists) with this search as
> well, but I don't know why they would be found, as there's no "321" in
> the tags.

Feel free top drop a copy of your library.db to my inbox:
https://www.dropbox.com/request/T3RctyzGgNg0oFDubq6a

I've never seen the issues you're showing on the screnshots...

--

Michael

dolodobendan
2018-02-23, 15:33
> To clarify, I got other discs (or rather artists) with this search as
> well, but I don't know why they would be found, as there's no "321" in
> the tags.

Feel free top drop a copy of your library.db to my inbox:
https://www.dropbox.com/request/T3RctyzGgNg0oFDubq6a

I've never seen the issues you're showing on the screnshots...

--

Michael

Before I do that, I wanted to test some things. I reduced the library to roughly 1/6 of its size to safe time and did a full rescan (if the cache is deleted, too, is that the "wipe" you mentioned? I did that to remove any remnants.)

Two things happened: I did not encounter these empty results anymore (Squeezeplay) and the search (WebUI) for "321" did not find the album I mentioned earlier (but it was scanned, of course). "321" finds one album/artist now (WebUI) "Home > Search > Artists (321) > Leonard Hokanson > The Piano Collection", and yet again I don't know why.

I'll start with this significantly smaller (~60MB vs. ~900MB) library.db first, if that's ok with you. If you need the larger one, just give the word.

And please, don't judge. Some family members have a weird taste. :rolleyes:

dolodobendan
2018-02-23, 16:33
This empty-result thing is back. Search for "99":

"99 Luftballons"
"All Songs"
""
""
""
etc.

But this time there are only 19 empty results and no "All Songs" at the bottom.

I did a new search and it's back to normal. But I'm far more curious about these false positives.

mherger
2018-02-23, 17:19
> This empty-result thing is back. Search for "99":

Could you please give me idiot prove step-by-step instructions how you
are doing searches? There are so many ways to search, it's not easy to
reproduce...


--

Michael

mherger
2018-02-23, 17:24
> Two things happened: I did not encounter these empty results anymore
> (Squeezeplay) and the search (WebUI) for "321" did not find the album I
> mentioned earlier (but it was scanned, of course). "321" finds one
> album/artist now (WebUI) "Home > Search > Artists (321) > Leonard
> Hokanson > The Piano Collection", and yet again I don't know why.

Hmm... now that's odd: it looks as if your LMS was looking in the id
column, too, not only the full text index. 321 is Leonard Hokanson's id
in the full text table...

Could you please check what version of DBD::SQLite is shown in
Settings/Information (web UI)?

--

Michael

dolodobendan
2018-02-23, 18:14
Could you please give me idiot prove step-by-step instructions how you
are doing searches? There are so many ways to search, it's not easy to
reproduce...


Open Squeezeplay :)
Click on third entry "Search"
Type in "99"
Click "Done"
Click "My Music"
Click "Songs"
And that's my how to produce empty results.


It also happens in My Music / Search.



Hmm... now that's odd: it looks as if your LMS was looking in the id
column, too, not only the full text index. 321 is Leonard Hokanson's id
in the full text table...

Could you please check what version of DBD::SQLite is shown in
Settings/Information (web UI)?


Database Version: DBD::SQLite 1.34_01 (sqlite 3.7.7.1)

mherger
2018-02-28, 05:12
I think what you're seeing is a buglet in my implementation: SQLite FTS would search across all columns by default. This includes the ID column. I'll have to implement the "notindexed" option (see https://www.sqlite.org/fts3.html#the_notindexed_option).

dolodobendan
2018-02-28, 05:27
I think what you're seeing is a buglet in my implementation: SQLite FTS would search across all columns by default. This includes the ID column. I'll have to implement the "notindexed" option (see https://www.sqlite.org/fts3.html#the_notindexed_option).

Thanks for getting back to me, not knowing why things happens drives me crazy!

dolodobendan
2018-09-17, 06:26
And thank you for attending this matter!

Ref.: https://github.com/Logitech/slimserver/issues/200