View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004395 | MMW v4 | Playlist / Search | public | 2008-02-14 07:52 | 2008-12-07 18:37 |
| Reporter | Ludek | Assigned To | |||
| Priority | immediate | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.1 | ||||
| Fixed in Version | 3.1 | ||||
| Summary | 0004395: Configurability re. which fields the searchbar searches | ||||
| Description | Based on feedback from wishlist forum users would like to have more control over the search bar in order to be able to set which text fields should be searched or an option to search only visible fields. So far you can only change the quick search behaviour in MM.ini file by editing that file. It will search only Title, Artist, Album Artist, Genre, Album fields then. Add parameter QuickDBSearch = 1 to the [Options] section of MediaMonkey.ini file stored in Doc & Settings\User\Local Settings\Application data\MediaMonkey Originally raised at: http://www.mediamonkey.com/forum/viewtopic.php?t=25710 http://www.mediamonkey.com/forum/viewtopic.php?t=25367 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1197 | ||||
|
|
Assigning to Rusty as post 3.0 issue. |
|
|
There should also be a mechanism to enabled searches of _more_ fields. See: http://www.mediamonkey.com/support/staff/index.php?_m=tickets&_a=viewticket&ticketid=1119¬econfirm=1 |
|
|
Once we implement full text-search, I suspect that this issue changes from a performance issue to a user issue--e.g. does the user want tracks that have 'U2' in the comments to appear when they just enter U2 in the search bar? Since text search will allow the user to manually narrow the search (e.g. artist:u2) is there a need for this feature any longer? i.e. perhaps we can just index/search all fields. |
|
|
Yes, there's probably no need to add this feature. Or, we could add some ini file configuration for fields not to be searched (e.g. Comments or Lyrics), so that user wouldn't have to write 'artist:u2' every time, but 'u2' would work fine too. |
|
|
How about something like searchbar_ignore: comment, <other field>, etc. in the .ini file (and deprecate the current quicksearch ini configuration parameter). The only question is which fields should be ignored by default. |
|
|
Yes, we can add: SearchBarIgnore=Comment,... but in order to be language neutral, we have to either store masks like %A,%S,etc. in the ini file, or add this configuration to MM interface with proper localization of each field. A small dialog with checkboxes would work fine here. As for the default, I'd prefer to search all fields. |
|
|
OK, if we go that route, on the Options panel we'd add sub to Library (under filters and views): Search Search the following fields via the Search bar: ------------------------------------------------ [ ] <List of fields in same order as other locations> |
|
|
Assigning to Ludek to implement together with other Search improvements. |
|
|
Assigning to Ludek to implement together with other Search improvements. |
|
|
I have implemented this, it is in the SVN branch ../Branches/Full-text Search , but there is a problem: In case of "Current Selection" mode we are searching the current track list without using SQL and the SQLite's FTS3 engine, because there (in the track list) can be presented tracks that aren't in DB (e.g. Devices' node tracks or My Computer's node tracks). The problem is that all tracks in the track list have currently the Lyrics and the Comment fields only 200 characters long (because of performance and memory utilization reasons when filling the track list). We should resolve this problem. Suggested solution: As default all fields except Comment, Lyrics, Encoder, Publisher, Copyright are ticked on the Options|Search panel. If user ticks also the Comment and Lyrics then the _whole_ Lyrics and Comment are read to the current tracklist so that correct comparison could be made. The functionality can be tested/reviewed by using the MM_FTS.exe and SQLite3.dll uploaded to our FTP, folder SQLite-FullText. |
|
|
Per offline discussion: If the whole Lyrics and Comments fields are read tot he current tracklist when the user enables Search on Comments and & Lyrics performance may suffer. An alternate approach might be to use Full Text Search in case of current selection except for those tracks in the current tracklist that are from locations that aren't in the DB. This might not yield the greatest performance for selections that have a mix of DB and non-DB tracks, but _would_ work well in most cases since selections will usually consist of tracks from the DB or tracks not from the DB, and only occasionally a mix of the two. Unfortunately, the Now Playing node may often consist of a mix of DB and non-DB tracks. A possible solution to this would be to implement NP in a DB table instead of via an m3u file (see 0004445) which would resolve other performance issues as well. Summary: whatever approach we take should yield good performance Search Selected even if the Lyrics Field is enabled (which most users would want by default) and even if some tracks in the selected list aren't in the DB. It would be acceptable for there to be some limited performance degradation if tracks weren't in the DB, though. |
|
|
As I think about the most straightforward solution, I don't think it would cause any significant slowdowns: We could leave everything as currently is, just when Lyrics/Comment is checked and user is in Search Selected mode, the search function would check each track for Lyrics/Comment length. In case these fields are of the limiting length (currently 200 chars), it's necessary to read them fully. ReadSongAddInfo() is used for this purpose and we can modify the SQL used there to be pre-compiled, which would make this action even faster. |
|
|
I found another solution, implemented both and compared performance. The mine seemed to be better and therefore I have used it. The performance is good. You can test/review by using the MM_FTS.exe and SQLite3.dll I have uploaded to our FTP, folder SQLite-FullText. |
|
|
Reopened, because after re-testing I have found the Jiri's solution as better in several aspects. Re-implemented. |
|
|
The functionality works correctly, but there's an entry called 'SubTitle' in the list of search fields, but such a field doesn't exist! Note KB Article 76 has been updated. |
|
|
'SubTitle' is field in DB, it is in track's tags, but it is missing from MM UI, why? |
|
|
We'll probably add 'subtitle' into a future release once we figure out exactly how we want to use it, and add support to all tag formats. |
|
|
Fixed in build 1197. i.e. Removed the SubTitle field. |
|
|
Verified 1201 |
