View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0015106 | MMW 5 | Playlists (Auto) / Search / Filters | public | 2018-09-17 14:51 | 2021-12-06 19:07 |
Reporter | Ludek | Assigned To | |||
Priority | high | Severity | crash | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Product Version | 5.0 | ||||
Target Version | 5.0 | Fixed in Version | 5.0 | ||
Summary | 0015106: Searching and filtering issues and crashes | ||||
Description | There are some search/filtering issues and crashes reported (to be looked into): http://www.mediamonkey.com/forum/viewtopic.php?f=30&t=91115 http://www.mediamonkey.com/forum/viewtopic.php?f=30&t=91141 1) tools|option|library|search|searchmode "respect diacritix" ... causes the following crash when sorting.. big stack of error dboxes ... if I get past one of these sql errors, these is a different sql error in a following query ... both shown in illustration below [url]https://www.dropbox.com/s/js2spm3g7ajqzxb/sort%20option%20errors.png?dl=0[/url] 2) tools|option|library|search|SearchForFollowFields ... Custom6, Custom7, etc are defaulted off 3) tools|option|library|search|SearchForFollowFields ... suggest Path is off by default ... for the same reason (I guess) that Publisher is off by default, ie. the path col is not usually displayed, so can be hard to see what caused the match ... ie. I spent a lot of time trying see why unexpected tracks were returned ... the cause was the path, ie. Search for +Frank and was returning a track with tag containing "frank" ... the issue was that the track name (in path) was spelt in lower case. 4) maybe have a sort configuration option which only will only search the currently displayed columns? ... this could be a good default option ... ie. will generate less support queries, maybe 5) Search tooltip improvements? More at http://www.mediamonkey.com/forum/viewtopic.php?f=30&t=91115 6) crash: 367589F0 ... filter a display (with funnel) ... when trying to use condition 'Album Artist' equals ... 7) filter of Artist & AlbumArtist tabs is potentially confusing. ... below I have filtered Genre=Jazz & AlbumArtist starts with J ... the result includes all albums by Anouar Brahem (ie. no J) ???? ... after some study I found that I have one album which lists both Anouar and John Surman as AlbumArtists. .... the question is whether Anouar should be listed here at all? ... the album appears in this filtered view twice ... once under Anouar Braham, which lists that one album [u]PLUS all the albums that have no albumartist starting with J[/u] .... AND it also lists that album under John Surman ... maybe we only need the John Surman group? ... or maybe the Anouar group should not display his other albums, because they have no artists start with J ? https://www.dropbox.com/s/jxp2w6i7w9m1z0l/no%20J%20here.png?dl=0 https://www.dropbox.com/s/wbgrpe3mhe4axrx/J%20is%20here%20on%20another%20album.png?dl=0 8) there was an exception that occurred that wasn't sent to you https://www.dropbox.com/s/i985w4obmdo2aep/uncaught%20exception.png?dl=0 9) The search function only seems to return results with alphanumeric characters. For example, searching for entries with characters like $ @ " ! etc. gives "No results found". while searching for * works to bring items including * | ||||
Tags | No tags attached. | ||||
Fixed in build | 2185 | ||||
related to | 0015131 | closed | Ludek | Search whole words only when in double quotes |
related to | 0014347 | closed | Ludek | Shift+Ctrl+R starts filtering instead of launching Rip dialog |
related to | 0015185 | closed | Ludek | Scroll to match doesn't find all matches (and improvements) |
related to | 0015341 | closed | Ludek | Crash (this cannot be called from JS thread assert) when using funnel filter with "Genre equals" criteria |
related to | 0018628 | closed | Ludek | Shift+Character Hotkey also executes as character |
|
Items 1,2,6,9 are fixed in build 2124 3) I guess we could remove Path from the default search fields? => removed in 2124 from the defaults. Rusty, let me know if you don't agree. 4) Could be useful, but sounds rather like a feature request for MM 5.1 ? 5) Tooltip is same as MM4, the suggested changes to be reviewed by Rusty. 7) I can confirm, seems to happen from the time when the artist list is generated by tracklist (with introducing Album+Tracks views). i.e. it matches a track for which an artist starts with 'j' and shows list of all artists for such a track. To be resolved somehow later, but doesn't seem to be a high priority item (+the fix isn't trivial). I would suggest to postpone to 5.1 8) not sure how this could occurred, but added some assertions to see more next time when this happens (in the next build). Also, there was a bug in error logging that such a crashes didn't generate crash reports. This is also fixed in 2124. Assigned to Rusty for feedback re items 3,4,5 |
|
3/4) I thought that in MM4 we used the logic that enabled search fields would apply only if the field in question was displayed in a view. My preference would be that 'path' should be searched if a view displays the path column. Otherwise, users in Location/Folders views may not get expected results. 5) Re. user feedback: a) it would good if the entry field had a little "x" hotspot, so I could clear the search field. I think the current implementation is cleaner and works just as well (double-click to select text and then type new search entry) b) search tooltip ... would good if it mentioned that all search is for words starting xxx, not for words containing xxx ... eg "ank" finds Paul Anka, but not Frank Zappa. - search string +A... tooltip isn't very clear ... is a case sensitive search? ... is, you should state explicitly - the tool tips do not make clear I can use multiple characters, such as +Fran ... ie use multi character strings in your tooltip examples, where applicable Below are the suggested changes and additions wrt the above feedback: Search Tips: A : finds files with A*, a*, or variants with an accent --> Abc : finds words beginning with Abc (case-insensitive or accented) +A : finds files with A* only --> Abc : finds words beginning with Abc (case-sensitive) "A" : finds files with A only --> "Abc" : finds words beginning with Abc (exact match) A B : finds files with A AND B A OR B : finds files with either A or B A -B : ... New: fieldname:A : restricts search to a specific field. For example: artist:A : .... year:X..Y : .... rating:X : .... 7) Yes this should be fixed. If the logic described applies to any multi-attribute track, the problem might be much more significant than initially outlined. Note: I'd like to test this, but I'm finding that filtering isn't working properly in build 2123. See:0015115 |
|
3/4) No, in MM4 all configured fields are searched via searchbar. I guess that filtering only visible columns is problematic too, because even if 'Path' column is shown in the search results view by default, it isn't visible until you scroll the view, i.e. it is hidden behind the right sidebar, see: https://www.dropbox.com/s/s6n4n2rlx6tevvu/Screenshot%202018-09-21%2011.36.59.png?dl=0 Therefore I think that current logic and MM4 implementation is still good enough just the defaults could be adjusted? 5a) OK, leaving as is 5b) Fixed in 2124 7) ok, just note that currently it filters based on track entries, so filtering artist list by "Rating equals 5 star" actually shows all artists for which a track has 'rating = 5 star'. I agree that this looks strange for multi-attribute example above, I guess I would need to add another layer for filtering already filtered results to cover the scenarios like this. Or we could just disable filtering for grid views and leave it only for "List View" and "Album+Tracks"? This would also prevent from the confusion re the fact that it actually filters based on track entries and not artist entries. Thoughts? I would suggest to retest in 2124 and decide. 10) Contextual search doesn't work at all when the non-default choice ""respect diacritics / search work infix" is selected => Fixed in 2124 |
|
3) I suppose that there are 2 sides to this issue (aside from performance): a) Search for items and fail to find them b) Search for items, and find them, but fail to understand why From my perspective a) is the worse problem and so I'd lean towards including more search results rather than fewer. 7) I'm unable to replicate any unexpected filtering behavior, so I'm probably not understanding the issue or my expections of what should occur are different. Can you clarify repro steps? |
|
3) OK, added the path field back to the defaults 5b) I've adjusted the tooltip further because of change 0015131 suggested by Jiri i.e. I changed it to "Abc" : finds words with Abc (exact match) it finds both exact phrases like "la femme" (0014127), but also can be used to find just "be" without seeing "beatles" in results (0015131) I guess that the wording should reflects this? 7) To replicate: - select a music track and set the artist field to [Rusty; Ludek], i.e. the track has now assigned two artists (Ludek & Rusty) - go to Music > Artists node - switch to 'Grid View' - type 'Ludek' => Both 'Ludek' and 'Rusty' are shown The reason is that the artist list is based on matched tracks, and the single track was matched, but actually has two artists to list. 11) The search tooltip is missing in case of contextual search / filtering (e.g. in Music > All tracks) > Fixed in 2125 |
|
5b) Sounds like it should read "Abc": finds whole words Abc (exact match) 7) Strange--I still can't replicate this!? |
|
5b) is fixed in 2127 7) Sorry, my bad, the last repro step is bad, it is not type "Ludek", but click on the funnel icon and add criteria [Artist contains Ludek] or [Artist equals Ludek] => it lists both Rusty and Ludek then |
|
7) I agree that this can be deferred (in fact I'm not even sure that it needs to be fixed). 10) When searching for +Beatles, is there a reason why MM only shows the tracklist (even in Browser view) ? |
|
Some further tweaks found by users: http://www.mediamonkey.com/forum/viewtopic.php?f=30&t=93547&sid=b014a106693b4914854aeb04b8cfb402&start=15#p454926 11) in "filter matches" search: the first capital letter is consumed (not entered) 12) in "scroll to matches" search: using capitals in the search term does not find anything |
|
Fixed in 2149 |
|
Re-opened because of item 5b (wording item) I guess that the wording in the tooltip still doesn't reflect the ambiguity i.e. it finds both exact phrases like "la femme" (0014127), but also can be used to find just "be" without seeing "beatles" in results (0015131) ... and also one can use artist:"du p" to find tracks by artist "Jacqueline du Pré", see https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=94658 Further suggestions for the tooltip/wording issues here: https://www.mediamonkey.com/forum/viewtopic.php?f=30&t=94658#p459618 |
|
ABC | finds words beginning with ABC. e.g. XYZ ABCde or áBcde "ABC" | finds whole words e.g. ABC or áBc [Remove: +ABC | finds words beginning with ABC (exact)] -- note: if we want, we can leave the functionality and just delete the text from the tooltip--I'm not sure that anyone actually uses this.) .. .. artist:ABC | finds words beginning with ABC (in Artist) e.g. XYZ ABCde or áBcde artist:"ABC) | finds whole words (in Artist) e.g. ABC or áBc {note: as in the examples above, '|' should replace non-significant ':' in tooltip text except in cases where the ':' changes the meaning of the search} |
|
Based on the feedback on the forums and based on the above I guess that the following might work (added to 2185): foo | finds words beginning with foo (e.g. Bar Food or fóObar ) +Foo | finds words beginning with Foo (case-sensitive, e.g. Football) "Foo" | finds whole words (e.g. FOO or fóo) "foo bar" | finds matches including phrase foo bar (e.g. foo barman) foo bar | finds matches with foo and bar foo OR bar | finds matches with either foo or bar foo -bar | finds matches with foo and not bar fieldname:foo | restricts search to a specific field. For example: artist:foo | finds words beginning with foo (in Artist) e.g. Bar Food or fóObar year:X..Y | finds matches in range X to Y rating: X.. | finds matches with X stars or more |
|
Looks good. Setting as 'resolved' for testing. |
|
Verified 2261 All is working OK. |