View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000347 | MMW v4 | Playlist / Search | public | 2003-05-04 11:34 | 2007-04-04 23:29 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | feature | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Fixed in Version | 3.0 | ||||
| Summary | 0000347: Restrict Quicksearch to current view | ||||
| Description | There are one very significant occasion where it would be useful to restrict a search to the current view: -Determining if a certain Track appears within a certain playlist A good way of dealing with this issue would be to allow the user to restrict a search as follows: (o) Search entire Library (o) Search current Playlist only | ||||
| Additional Information | See bug 0000481 and #95 for additional refinement to this feature. http://www.mediamonkey.com/forum/viewtopic.php?t=15410 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1027 | ||||
|
|
I don't think it's necessary to implement this feature, because: - It adds new complations to the UI. - Isn't of much value, I think that showing playlists where a track is added in 'track properties' dialog is much more useful. - There are serious implementation problems. |
|
|
IM discussion summary: Rusty: Couldn't this be done as described in #95 by doing a search for Node=xx AND yy where yy is the search term (e.g. if Genre/Rock is the active node then search for Genre=Rock AND yy)? Or is the problem that the UI isn't always aware of which tree node is active? Jiri: No, not with Access on the back end. Jiri: Other issues are that if the user enables (search current node), then all searches subsequent to the first one will result in searches of the search node. Russell: Behaviour could be that it searches the last selected node, however, this introduces other usability problems. Jiri: Better implementation might be through the user of a filter that limits the search to the current node. Rusty: This would work but current filter implementation needs improvement to: a) tell the user a filter is active b) tell the user which filter is active c) easily configure filters (currently it's by right clicking a node) Conclusion: defer to later release. |
|
|
This comment supercedes all previous comments (i.e. the UIs defined in previous comments are not required per the spec below). Now that MediaMonkey works in this manner (e.g. it aggregates Node + Album browser filters) to determine what is displayed in the tracklist, it would seem to be time to do the same with the QuickSearch bar. As the user types in the search bar, only what is in the current view should be searched, and the search results should not be displayed in the search node, but rather in the currently selected node. If the user wants to search the entire library, then they can switch nodes (e.g. switch to library node and/or change the filters in the Album browser). This is nicely implemented in WMP 11. Note: this applies ONLY to the quicksearch function. If the user searches using the full search/advanced search, then the search results should be displayed in the search node and the Album browser where the Album Browser is hidden. |
|
|
Assigning to Ludek to implement as described in the last Rusty's comment. Feel free to discuss with Petr any issues related to the showing of results (there must be two lists, one of all tracks in the current node and other of filtered tracks only - this is what Petr has already done in his Browser). As for the decision whether a track belongs to the filter, for this QuickSearch it is enough to implement it as a simple search in strings of tracks in memory. However, from the perspective of implementing some other future features, it would make sense to improve QueryManage.pas so that it is able to do such in memory queries, i.e. so that instead of using SQL (or rather in addition to using SQL!), it would be able to process a given list of in memory tracks and return another list of tracks that fulfill the given query (given by TQueryData type). So, please try to go this way. And one design note: Some users might like/need the current behaviour, thus I'd suggest to add it as a switch to the dropdown associated with QuickSearch, something like: [v] Search current node only [ ] Search whole Library {Rusty can improve the wording} |
|
|
Implemented in the way described by Jiri in the last note, but left out disabled/invisibled because of a performance reasons. Surprisingly the described method is slower than common DB SQL searching (e.g. if you search accessible tracks node with up to 5500 tracks shown and you search all text fields it takes 7 seconds instead of common SQL searching takes only 1 second). I have found out that it is because of AddSongInfo reading which has to be done per each song (i.e. if you search only SD.Title there is no performance problem, but in case of searching All fields it has to search SD.Comment which causes AddSongInfo reading ). I'm going to discuss it with Jiri later. |
|
|
Discussed with Ludek over IM: Due to technical difficulties and also because it seems to make sense, we could either: 1. Remove Comment and Lyrics from QuickSearch (but not standard Search dialog!), because these fields aren't fully loaded into memory when working with Library. 2. Or go even further and search only fields visible fields in tracks list (except for Comment and Lyrics for obvious reasons). It might sound limiting, but I think it's quite reasonable, not only it would increase performance, but also I'd say that QuickSearch is most often used for look up of artists, tracks, etc. and then searching in lyrics or comments can be even undesired. Assigning to Rusty for a review. |
|
|
I like your second suggestion. I think it does make sense to limit the quicksearch to the fields that the user has configured to display. It also fits well with bug 0002894 which is that the search term should be highlighted in search results (i.e. this avoids the situation where search results appear but nothing is highlighted). |
|
|
Assigning to Ludek to implement as described, i.e. search only in visible columns and never search in Comment and Lyrics fields. |
|
|
Implemented in revision 2486. The Comment and the Lyrics fields are searched, but only its 200 chars versions that are read in order to show it to a user in tracklist. (i.e. no need to call ReadSongAddInfo() which loads its full text length). |
|
|
I wouldn't search in incomplete comment and lyrics fields, it seems to be much better to ignore these fields completely than to find only text that's within the first 200 characters. Assigning to Rusty to confirm. |
|
|
Probably better to be consistent one way or the other. I.e. search lyrics/comments or don't search them. |
|
|
Ok, so please remove them from search. |
|
|
Ok, removed. |
|
|
Something very strange just happened: 1) Quicksearch for 'mp3' (entire library) --> thousands of tracks found 2) Click 'Artists' and then Quicksearch for 'mp3' (restricted to current node) --> 3 tracks found!! This doesn't seem right. The search criteria for Entire Library vs Restricted to current node should be identical except that 'Restricted...' searches a smaller subset. |
|
|
Yes, it looks like path field isn't searched? There's also another problem: if I search for 'a' (in some node) I get e.g. 1000 results, then I search for 'b' and get e.g. 500 results, then I search for 'a' again but this time I get 500 results instead of 1000!!! It looks like my comment above wasn't considered for implementation, it was: Feel free to discuss with Petr any issues related to the showing of results (there must be two lists, one of all tracks in the current node and other of filtered tracks only - this is what Petr has already done in his Browser). |
|
|
All fixed in build 1027. |
