View Issue Details

IDProjectCategoryView StatusLast Update
0004395MMW v4Playlist / Searchpublic2008-12-07 18:37
ReporterLudek Assigned To 
PriorityimmediateSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version3.1 
Fixed in Version3.1 
Summary0004395: Configurability re. which fields the searchbar searches
DescriptionBased 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
TagsNo tags attached.
Fixed in build1197

Relationships

related to 0003040 closedLudek Implement proper full-text search 
related to 0003760 closedLudek Searchbar returns different results for 'Search selected' vs 'entire library' 
related to 0004975 newrusty Support for Subtitle field 

Activities

Ludek

2008-02-14 07:52

developer   ~0013111

Assigning to Rusty as post 3.0 issue.

rusty

2008-07-13 04:40

administrator   ~0014362

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&noteconfirm=1

rusty

2008-07-14 16:06

administrator   ~0014367

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.

jiri

2008-07-17 15:14

administrator   ~0014376

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.

rusty

2008-07-17 16:29

administrator   ~0014380

Last edited: 2008-07-17 16:30

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.

jiri

2008-07-17 19:17

administrator   ~0014382

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.

rusty

2008-07-17 20:58

administrator   ~0014385

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>

jiri

2008-07-18 07:11

administrator   ~0014393

Assigning to Ludek to implement together with other Search improvements.

jiri

2008-07-18 07:11

administrator   ~0014394

Assigning to Ludek to implement together with other Search improvements.

Ludek

2008-08-21 21:00

developer   ~0014461

Last edited: 2008-08-25 17:43

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.

rusty

2008-08-25 20:38

administrator   ~0014481

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.

jiri

2008-08-26 06:59

administrator   ~0014485

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.

Ludek

2008-08-26 22:16

developer   ~0014490

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.

Ludek

2008-08-27 13:33

developer   ~0014493

Last edited: 2008-08-27 13:34

Reopened, because after re-testing I have found the Jiri's solution as better in several aspects. Re-implemented.

rusty

2008-11-26 22:11

administrator   ~0015160

Last edited: 2008-11-26 22:17

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.

Ludek

2008-11-27 15:15

developer   ~0015190

'SubTitle' is field in DB, it is in track's tags, but it is missing from MM UI, why?

rusty

2008-11-27 17:16

administrator   ~0015193

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.

Ludek

2008-11-30 12:34

developer   ~0015259

Fixed in build 1197.

i.e. Removed the SubTitle field.

stephen_platt

2008-12-07 14:50

developer   ~0015531

Verified 1201