View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0015185 | MMW 5 | Playlists (Auto) / Search / Filters | public | 2018-10-25 17:13 | 2020-12-27 15:18 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | always |
| Status | closed | Resolution | reopened | ||
| Product Version | 5.0 | ||||
| Target Version | 5.0 | Fixed in Version | 5.0 | ||
| Summary | 0015185: Scroll to match doesn't find all matches (and improvements) | ||||
| Description | This functionality doesn't work well in certain instances. e.g. 1) if the user wants to find an entry with a space e.g. 'The Beatles' (or similar things beginning with 'A' or 'The') --> it won't find the intended result 2) Similar to issue 1, though a slightly different usecase: If the user wants to find a word in the middle of a title. e.g. 'hole' for 'fixing a hole' --> not found 3) If the user wants to find an album (Abbey Road) and types 'Abbey' to find next track from 'Abbey road' --> Titles beginning with 'A' are found. The issue is that at a minimum, the user expects that at least displayed fields will be found for this type of search. In MM4 this expectation didn't exist because the search was based on the words displayed in the tree. But the tree values (e.g. Genre Values) isn't displayed in MM5 so the user doesn't have any clear expectation of a restriction on which fields will be searched. 4) On all such searches, MM appears to highlight incorrect matches (due to the cursor's position) 5) It occasionally crashes. See video and eLog C84B45B3 https://www.screencast.com/t/7RikegsNuCK Note: I think that this is a pretty confusing issue, but if it's not trivial to fix, we can push it. | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 2273 | ||||
| related to | 0015077 | closed | Ludek | Improve incremental search |
| related to | 0015312 | closed | Ludek | Freeze when pressing space while a track is selected in large tracklist |
| related to | 0015344 | closed | petr | Auto-tag: Dynamic Sorting makes it difficult to edit tracks |
| related to | 0015803 | closed | michal | Popup in grid view auto-scrolls unintentionally after opening inner popup |
| related to | 0015106 | closed | rusty | Searching and filtering issues and crashes |
| related to | 0015559 | closed | Ludek | Default tracklist columns sort and visibility is problematic |
|
|
Fixed in 2131 |
|
|
Verified 2132 |
|
|
Re-opened: 3) isn't fully fixed, while it works for non-track entities (like albums/artists) it fails for track entities (in tracklist) Some other issues requested at: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=93547 6) user is requesting a pop-up showing the text being searched 7) a scrolling shortcut to scroll to the next result, currently the search word needs to by typed again to find the next result 8) Barry's UI freeze (id 5367CF21) -- tracked as 0015312 |
|
|
Item 3 fixed in 2148 Item 8 is fixed as 0015312 |
|
|
6,7 are fixed in 2148 |
|
|
Note to Peke: Don't close--Rusty should review new strings added in this build: e.g. 'Scroll to', 'Use %s for the next occurence', 'No occurence for' , you might want to review them in the next build |
|
|
Re-opened for further improvements based on the last feedback from http://www.mediamonkey.com/forum/viewtopic.php?f=30&t=93547#p454778 9) Similar to current "Ctrl + Down" for the next occurrence add also "Ctrl + up" shortcut for the previous occurrence 10) Increase the current 500ms timeout (in which another letter needs to be typed to be suffixed) for slower typists, i.e. increasing to 1000ms could work 11) Using "space" key when using the incremental search pauses a playing song |
|
|
9,10,11 are fixed in 2149 |
|
|
Verified 2149 |
|
|
I haven't tested items 1-10 in 2149, however, I noticed the following: 11) in Music > Locations > FolderName, if scroll to match is enabled and the user types a search term that matches Title or Artist for tracks that only contain inferred Title and Artist fields, then the items aren't found! video: https://www.screencast.com/t/c8KxakCvQiCE |
|
|
Rusty, note that contextual search (scroll to matches) isn't supposed to work the same way as filter matches. This is going to work as in MM4 (related to 0015077 - see item a) there, namely: a) When user focuses a list-view then it always scrolls to the first file/track starting with the search phrase within title of the track. When user sorts the file list by artist then it scrolls to the place where tracks from this artist are. Someone can call this "power scroll" (more at https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=90949&p=449187#p449182 ). In your case you have sorted the list by Album artist so the term is searched within the Album artist column. Nevertheless I agree that this is hard to realize for novice users (and by evidence for you too ;-) ), this could be resolved by changing current tooltip from No occurence for "coasters" => No occurence for "coasters" within Album artist column ? Another possibility would be to search within all visible columns, but this would break the MM4 approach that some (or many?) users are expecting ( see the Power Scroll section here: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=90949&p=449187#p449136 ) |
|
|
11) Somehow, in MM4, powerscrolling seemed more intuitive--possibly because it worked in the tree and the tree was always visible. Also, in MM4, the user could powerscroll, or search the library, collection, node In MM5, with powerscroll enabled, the user can only search the Library However, with filtering enabled, the user can search collections, nodes, or the Library, and considering that it's enabled by default, we can probably leave things as is for now. In the future, though, we may find that we have to expand search options that are available on-the-fly for users that opt to enable Powerscroll. |
|
|
Re-opened: 12) power-scroll don't work for symbols. For example, if I search for "Don't Know Much", I get no occurrences, because it has an apostrophe in it. Other symbols - like brackets, quotation marks, slashes, etc. - also don't work. Reported as: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=94019 => Fixed in 2166 |
|
|
Verified 2166 Tested on all symbols I have in library including brackets, quotation marks, slashes |
|
|
Looks good. I just noticed a couple of items in 2166 1) Still open. i.e. scroll to multi-word item fails (e.g. Abbey Road or The Beatles) 13) There seems to be a performance issue with the use of CTRL-DOWN / CTRL-UP. e.g. if the sort is by Album, and the user searches for Abbey Road --> the first instance is found. If the user presses CTRL-DOWN to find the next one (which is the next track in the list), MM should find the next track _instantaneously, and yet what actually happens is that the Toast message appears, and then about 500ms later, MM scrolls to the next track! Could it be that MM is applying the typing delay for CTRL-DOWN/UP? |
|
|
+ 11) No occurence for "coasters" => No occurence for "coasters" within Album artist column to prevent from confusion (related to 0015559 ) |
|
|
11) fixed in 2167 13) yes, fixed in 2167 1) fixed in 2167 |
|
|
Tested 2175 1) Verified 11) It currently displays 'No occurence for: "SearchTerm" , column: ColumnName' 'No more occurence for: "SearchTerm" , column: ColumnName' The following is simpler: 'phrase not found in "ColumnName"' Also, the second string 'No _more_ occurences...' isn't required (it's grammatically incorrect, but more importantly, it's self-evident from the fact that MM loops back to the top). 13) Verified |
|
|
Fixed in 2177 |
|
|
Re-opened, items 1&2 are rather problematic based on feedback here: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=94486&p=458812#p458798 Namely: I don't always know exactly what i'm searching for, but i may know it starts with " L" so if i can bring all the artists starting with "L" into focus then i can quickly scan thru them (visually) to find what i am looking for. This is also an aid to editing, so for example i may have typed "Lupez" instead of ""Lopez" Maybe we should make it a little be tricky and whenever only one or two letters are entered ('L' or 'Lo') then it would scroll to artists starting with 'Lo' , but when three (or more letters are entered) like 'Lop' or 'Lopez' then it would rather scroll to "Jennifer Lopez". i.e. it would be combination of both behaviours based on the length of the entered phrase. => Implemented in 2179 |
|
|
I haven't tested the revised implementation yet, but there's a problem with issue 11) in 2178: 1 Type 'postal service' --> 2 tracks found 2 press the down arrow twice --> MM loops back to the first instance, but displays the message 'phrase not found in "ColumnName"'. This message should never display if instances are found--even when they loop back to the first instance. |
|
|
Fixed in 2179 |
|
|
Tested 2261. I haven't reviewed all of the previous fixes, but there seem to be a few issues with basic functionality: 14) Scroll to match often highlights matches at the bottom of the screen making it appear as if the match hasn't been found e.g. 1 Navigate to Music > All tracks 2 Type 'Lov' --> Track by 'Love and Rockets' is highlighted but it appears only partially visible (it's at the bottom of the screen, only partially visible)! 3 Type 'Los' --> Track by 'Los Lobos' appears at the top of the screen, as expected. 15) Pressing BACK to erase the search term results in a message "" phrase not found in "<fieldname>" 1 Navigate to Music > All tracks 2 Type 'Lov' --> match appears 3 Press BACK 3x --> "" phrase not found in "<fieldname>"! 16) The 'Use %s for next match' message never seems to appear for me. This is problematic since I don't remember what the shortcut to advance is. It might be that I disabled this somehow, but can't find a way to re-enable it. 17) If the user enters a search term and presses ENTER, then pressing BACK causes the view to go back to the parent view, when what would be expected is for the search term to be deleted (and MM remain in the current view). e.g. 1 Navigate to Music > All tracks 2 Initiate contextual search [scroll to match]: love 3 Press ENTER 4 Press Back --> View switches to Music! 18) Usability improvment: Pressing ENTER causes focus to switch to the tracklist which causes pressing ENTER again to initiate playback. This is annoying because it deletes the currently playing list, when the user actually expects MM to just highlight the next match. e.g. 1 Navigate to Music > All tracks 2 Type 'Lov' and press ENTER --> First instance appears 3 Press ENTER again to find the next instance --> Playback starts! The issue is that focus is shifting to the list, when it probably should just highlight the relevant instance. I find this annoying, but wonder if some users might like this. 11) Usability improvement for the future: although the current functionality has been designed to work like MM4, I think that many users will find it confusing that matches are only based on the current sort field. For the future, we may want to consider improving the functionality to allow matches for any visible field. |
|
|
14/15) Fixed in 2262 16) The toast message isn't shown whenever the search bar is shown (as it would just include redundant information). i.e. the search term is visible in the search bar same as the arrows for the next/previous occurence. You can simply hover the arrows to see the "Ctrl+Up" / "Ctrl+Down" shortcuts. 17/18) It was suggested somewhere in the past that presing ENTER should leave the search bar and switch focus to the current view. Thus both 17&18 are actually expacted behaviours. i.e. If you don't want to switch focus from search bar to the current view then just don't press ENTER. |
|
|
Reopening, fix of 14) was causing regressions (unwanted scrolling in several situations), code commented out. |
|
|
14) Fixed in 2263, the partial visibility was caused by overlapping bottom scrollbar. |
|
|
Verified 2264 14. no overlaps 15. Unable to replicate using steps from 0015185:0058998 @Rusty I agree on points 16/17/18 set by Ludek in 0015185:0059047, please close if you agree. |
|
|
Tested 1-13 so far and noticed the following issues in 2272: 19) The warning re. xx is not found in <field> always appears even when an item has been found! e.g. search for 'Mornin' and an error appears after typing the first two letters: "'mo' is not found in 'Title' " even though the track has been found 20) Scroll to match won't scroll to the searched term if the search term has been changed. e.g. 1 Powerscroll Search for 'rock' in Music > Genres > Rock [List View|sorted by Title] --> screen scrolls to first title containing 'rock' which is highlighted 2 Press the BACK button 4 times (so that there's no longer a search) 3 Type 'love' --> Song with 'love' will be highlighted offscreen, but the tracklist doesn't scroll to it (i.e. if I manually scroll further down the list I can see that it's highlighted) 21) Scroll to match stops scrolling to the searched term after it has been used several times: 1 Powerscroll Search for 'love' 2 Press CTRL DOWN 10 times --> The first few times it'll work, but after a few times, MM stops scrolling to the next track! 3 Press CTRL (or any other button on the keyboard) --> MM for some reason scrolls to the correct track! 22) Performance issue in Music > Genres [Grid] 1 Powerscroll search 'Rock' 2 Press CTRL DOWN several times --> after a few times MM will take several seconds to find the next Genre containing 'rock' (even though there are only 247 genres! Could it be that there's a problem with my database? |
|
|
These issues are affected by the regression in 2270 and fixed as 0017045 for 2273. So re-test in 2273, works fine here after the fix. |
|
|
Verified 2288 Unable to replicate behavior. |
|
|
Re verified 2291 points 19-21 and they work fine Also retested 1-13 and unable to replicate. |
