View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004088 | MMW v4 | Playlist / Search | public | 2007-12-05 18:17 | 2009-02-21 04:50 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 3.0 | ||||
| Fixed in Version | 3.1 | ||||
| Summary | 0004088: Search Results node is filled with non-sensical searches --> Optimize timer | ||||
| Description | The search results node is filled with searches that are useless as a result of MM generating a new node each time there is a 1 letter change in the search term. e.g. Typing "Jo....h...n" (... denotes wait time) yields the following search result nodes: Jo Joh John Similarly, if the user types "Help" and then presses the delete key 4 times, the following search result nodes appear: Help Hel He H MM should only generate a new node when a new term is entered. I'm hoping you have an idea for a good algorithm :) | ||||
| Additional Information | Reported at: http://www.mediamonkey.com/forum/viewtopic.php?t=23092 | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1185 | ||||
|
|
I've got 2 ideas about this solution: 1) Increase timer's interval (latency) in which the search action starts, currently it is in 500 milliseconds, could be increased to 1200 ms?? 2) Replace the node 'Joh' by 'John' and vice versa according to this algorithm: a) If the next search term (e.g. 'John') contains the last search term (e.g. 'Joh') then replace the last search node. b) If the next search term (e.g. 'Joh') is contained within the last search term (e.g. 'John') then replace the last search node. 3) Combination of 1 & 2. Assigning to Rusty for review my suggested solution (I prefer 2). |
|
|
Implemented 2) in build 1113. Check it out, seems to work fine for me. |
|
|
Tested in 1114 and it works great. I would only suggest one thing. With the new algorithm, the timer latency can be reduced in order to increase perceived responsiveness. Generally audio latencies of 150-250 ms are not perceptible by humans, so I would expect that latencies of 125-200 wouldn't be perceptible for visual information. |
|
|
Ok, the latency in which the query starts is reduced from 500ms to 200ms in build 1116. |
|
|
Maybe it is for new Bug, but until you do not restart MM you can't delete past Searches from Tree you do not need anymore. |
|
|
Ok, I've opened 4111 for this. |
|
|
Verified 1116 |
|
|
I think there's room for further optimization here, though I'm not certain of the best approach. I find that: -There are still nodes created that aren't desired -Search is still slightly 'delayed' Perhaps the best approach would be to only create persistent nodes when the return key is pressed and eliminate the delay altogether? I'm not sure--I just think that it can be made to feel a little more snappy. |
|
|
Re: -There are still nodes created that aren't desired: I see, you think the case if user type 'God' and then continues searching for 'Good' (i.e. he moved the cursor to the left and then typed 'o') Yes, in this case there should not be a new node created. It is fixed in build 1185. Re: -Search is still slightly 'delayed': This depends on performance of the full-text search operations. The new full-text search engine should resolve this. |
|
|
verified 1224 |
