View Issue Details

IDProjectCategoryView StatusLast Update
0004395MediaMonkey 4Playlist / Searchpublic2008-12-07 18:37
ReporterLudek Assigned To 
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:
TagsNo tags attached.
Fixed in build1197


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 



2008-02-14 07:52

developer   ~0013111

Assigning to Rusty as post 3.0 issue.


2008-07-13 04:40

administrator   ~0014362

There should also be a mechanism to enabled searches of _more_ fields.



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.


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.


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.


2008-07-17 19:17

administrator   ~0014382

Yes, we can add:

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.


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>


2008-07-18 07:11

administrator   ~0014393

Assigning to Ludek to implement together with other Search improvements.


2008-07-18 07:11

administrator   ~0014394

Assigning to Ludek to implement together with other Search improvements.


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.


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.


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.


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.


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.


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.


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?


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.


2008-11-30 12:34

developer   ~0015259

Fixed in build 1197.

i.e. Removed the SubTitle field.


2008-12-07 14:50

developer   ~0015531

Verified 1201