View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005565 | MMW 5 | Playlists (Auto) / Search / Filters | public | 2009-04-30 12:55 | 2021-10-14 15:38 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0005565: Full-text search only finds prefixes (gives poor results in Oriental languages) | ||||
| Description | Due to the design of sqlite full-text-search, MM is currently limited to finding word segments _only_ when they are at the beginning of a word. e.g. Typing 'Mad' will locate "Madonna" or "Child and Madonna", however typing 'donna' will not locate these. This is problematic for foreign languages which don't use the 'space' as a delimiter between first and last names. This means that MediaMonkey's search bar cannot be used to find Artist first names in Japanese, Korean, Chinese. | ||||
| Additional Information | Reported at http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=39122 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 2013 | ||||
| related to | 0005186 | closed | Ludek | MMW v4 | Quick Search with "" (quoted strings) doesn't work as expected |
| related to | 0017276 | closed | Ludek | MMW 5 | Search mode options counterintuitive |
| has duplicate | 0013040 | closed | Ludek | MMW v4 | Quick Search: Always work as STARTS WITH instead of CONTAINS |
| has duplicate | 0013144 | closed | Ludek | MMW 5 | Search fails to find results when entering end of word (Quick Search/All Text Fields) |
| related to | 0016453 | feedback | peke | MMW 5 | Full text Search: may not return all search results |
| related to | 0017395 | resolved | Ludek | MMW 5 | Respect diacritics breaks search operators |
| child of | 0003040 | closed | Ludek | MMW v4 | Implement proper full-text search |
|
|
I'm not sure what to do about this, it seems to be the correct behavior in most cases. We can possibly add an option for future versions that would control whether also searching in middle of words is possible, but for now I don't think any change is necessary. |
|
|
Possible approach for 3.1 is to add a config setting to .ini file for such languages. Better long term solutions that wouldn't require user configuration of these settings are: 1) switch the behavior so that it searches in the middle of words always. I don't think that this is such a bad option, if the performance implications are minimal. 2) change the behavior based on the language installed. |
|
|
deferring post 3.1. Too much risk associated with adding this functionality. |
|
|
Decreasing priority, since I don't see any reasonable shorter or longer term solution. The performance is problem here, FTS in SQLite can't be currently used this way. |
|
|
I've gotten some more feedback from Reika about this: > how is MM 3.1.x working for you / Japanese users (given the search problem)? I use 'search box', 'basic search', and 'advanced search' properly if necessary. Because the result that I expected is not provided, I often re-search by another method. In Japanese BBS, I did a question same in other users. For reasons of the deterioration of the search functionality, there are considerably the people who do not yet update from 3.0. There are even the people who downdate MM from 3.1 to 3.0. Any strings can be found by the search functionality of specific field in 'Basic' or 'Advanced' search. Why is it impossible only by the search from the whole tag? ---------------------------------------------------------- I think we need to revisit this for 4.0. |
|
|
Rusty, in the search bar it is impossible because we added new SQLite's full text search engine in version 3.1 (SQLite FTS3). The engine indexes all particular text fields/attributes of all songs and increased DB size, because the text data are indexed in the table SongsText. And the engine allows us to search prefix or full word (not infix, not postfix). The advantage of the engine is mainly performance of the search. My guess is that for oriental languages (japanese, chinese) we could automatically switch to the old approach we used to use in MM 3.0. We could decide whether to use the new engine or not according to the MS Window's locale? |
|
|
Perhaps an option such as: [ ] Search middle of words via the searchbar (reduces performance) Tooltip: Enable for Japanese or other languages in which words or names may not be separated by a space. It would be enabled by default for Japanese, and other languages that exhibit this problem. Note: this should modify the tooltips that appear under the search bar. i.e. if enabled no search tooltip would be shown. |
|
|
Also we should consider the discussion here: http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=43901 We have always searched via Search dialog (Artist->mel torme) is diacritical sensitive via LIKE on Artists. i.e. not using SQLite's FTS3. But Search bar "artist:mel torme" is diacritical insensitive MATCH on SongsText (using FTS3) As I now japanese users uses search dialog, because they can search also middle of the words ('donna' finds 'maddona') and the others uses Search bar "artist:mel torme", because it is diacritical insensitive. We should probably somehow unify this once this issue is resolved. |
|
|
User from the ticket UJR-193-58189 complaints about this issue being ignored since 2009, increasing priority to urgent and targeted to be included in MM5 User is saying that it DOES NOT only effect Japanese, Korean and Chinese languages and that it DOES effect ALL languages. His words: "when I work with my music I run into numberous situations where I want to search for a PART of a description/word e.g. a CD number DBCD12345 where 12345 is not found! Or anything behind any other sign as /test "test, etc. " With this in mind also item 1) here 0012521:0043400 should be re-evaluated , noted there 0012521:0043775 |
|
|
Solution is described at 0012521:0043916 i.e adding the following config in Options -> Search panel: Search mode: [Ignore diacritics / search word prefix (fastest), respect diacritics / search word infix] - enabled only when '[ ] Search whole words only' is unchecked (by default) |
|
|
Fixed in build 5.0.0.2013 |
|
|
Verified 2234 Works very well. Maybe it would be useful if no results are found for default search ([Ignore diacritics / search word prefix (fastest)]) user gets prompt (Delay few Seconds) "no results found would you like to have try full inline search?" For testing I used Search "ueen" as inline of "Queen" as both for artist, album and track names. |
|
|
Bug 0014653 is created as further improvement. |
