MediaMonkey forum

• Change of View mode should just change the view, not change filter criteria. MM5 takes us out of control of navigation|filtering causing confusion. Examples:
  • I am in Grid View in the AlbumArtist node ... I have filtered to just Captain Beefheart ... I change view to List by Album ===> you re-filter the contents that I have navigated to, by adding 92 other unwanted albums?
  • again in AlbumArtist node ,,, I am in List by Album View, and have filtered to just Jazz albums ... I change to Grid View, to get rid of the visual clutter coming from all the tracks details ==> You disappear all my Albums, and show me nothing
  • the confusion continues in AllTracks node ... I type "cap" again ... this time Captain Beefheart is joined by other artists, since I an not in AlbumArtist node, so you are searching more than just the AlbumArtist index ... that's good, I can understand that .... but if I change my View from List By Album View to Grid, ===> the album count goes from 28 albums, to 127 albums ... unexpected, and unhelpful
  • in each of these cases I lost control over MM5, by just changing "View"

• Column Browser filter integration issues; does not work well with other filter mechanisms. Examples:
  • I have AllTracks filtered to the 28 albums containing "cap" in the album summary tags ... I turn on the Column Filter to help me navigate what I am seeing ===> You destroy my filter, which is not what I wanted ... and you leave the UI looking like you are still applying my filter
  • there is a reproducible crash when switching from Grid mode, To List by Album view, when the Column Browser is open ... and the crash leaves behind a persistent artefact that affects other programs running on the PC

• Lag. Can you look at this response lag here? I changed View ==> For 10 seconds the MM5 UI was unresponsive ... ie. ignored clicks ... to demonstrate I tried to change sub-nodes ... S started clicking persistently on the Albums sub-node ... for 10 seconds it ignored me, and then took a further 7 seconds to make the change I requested ... I sent a debug log to Ludek.

Re: the lag; Do you experience that lag directly after closing a dialog window or popupmenu? I've been noticing unresponsiveness in that circumstance, where it takes a few seconds for the UI to "catch up" before it responds to any input.

drakinite wrote: ↑Sun Nov 15, 2020 10:47 am Re: the lag; Do you experience that lag directly after closing a dialog window or popupmenu? I've been noticing unresponsiveness in that circumstance, where it takes a few seconds for the UI to "catch up" before it responds to any input.

I see the same effect, but am noticing it from a different trigger.

Most obvious when toggling back to a sub-node which has the Column Filter open ... maybe the Column Filter qualifies as something like a popup of some kind.

What I see is lots of jerking around with the display .. elements popping in & out of view ... and then it settles down ... but the UI is unresponsive for a further 9 or 10 seconds.

I am seeing the same issues as Barry with the column filter with a good 8 - 9 seconds lag... Gets to be annoying...

Barry4679 wrote: ↑Sun Nov 15, 2020 1:56 am

• Change of View mode should just change the view, not change filter criteria. MM5 takes us out of control of navigation|filtering causing confusion. Examples:
  • I am in Grid View in the AlbumArtist node ... I have filtered to just Captain Beefheart ... I change view to List by Album ===> you re-filter the contents that I have navigated to, by adding 92 other unwanted albums?
  • again in AlbumArtist node ,,, I am in List by Album View, and have filtered to just Jazz albums ... I change to Grid View, to get rid of the visual clutter coming from all the tracks details ==> You disappear all my Albums, and show me nothing
  • the confusion continues in AllTracks node ... I type "cap" again ... this time Captain Beefheart is joined by other artists, since I an not in AlbumArtist node, so you are searching more than just the AlbumArtist index ... that's good, I can understand that .... but if I change my View from List By Album View to Grid, ===> the album count goes from 28 albums, to 127 albums ... unexpected, and unhelpful
  • in each of these cases I lost control over MM5, by just changing "View"

I have given some more thought to this, and have a suggestion to make.

I think the design decision was that a contextual filter query should only return results where the user can easily understand why the items were included. This is why a filter of "cap" from Album Artist, in Grid mode, only returned Captain Beefheart in my example, because I can only see albumartist tags in that grid.

And the same search in the Album Node returns many more results, because this Grid display displays Album title, as well as AlbumArtist, so I also get results like Hub Cap from Freddie Hubbard.

That's OK in one sense ... not 100% OK, because maybe I was searching for any album containing that track Captain Stupido ... but it is generally OK.

But what is not OK is when I have made my filter selection, and then are just changing View mode ... it is not OK for you to change filter criteria.

In this case your "helpful" approach is just damn annoying, and is unacceptable IMO.

My suggestion is as follows:

• introduce a new rule into existing sort syntax rules:
  • n:xxxx being results where xxxx is the primary tag for the current sub-node ... ie. just the albumartist in albumarist subnode, or both the album & albumartist in the album sub-node
  • +:xxxx being where xxx is any tag (from the list at Tools|Options|Library|Search), regardless of whether they are displayed

• everything would work exactly the same as now, excepting when the user is only changing view ... a simple change of View would, unless the criteria was already in one of the "+" or "n" formats, modify any current contextual criteria from:
  • from "xxxx" to "+:xxxx" when changing to Grid View
  • or from "xxxx" to "n:xxxx" when changing from Grid View

• this way the user remains in charge when changing View mode

• the other benefit would be that the existence of the + and n syntax formats would be generally useful to power users, and would overcome the one reservation that I mentioned at the top of this post

If you were feeling super-generous you could add:

• -:xxxx being results where xxxx is any tag that is returned to be displayed ... eg. ignore matches in path, if path was not one of the columns selected for display

Certainly it would really beneficial in searching, but whether it would fix the painful lag issues is questionable....

I can't seem to replicate that lag from switching views... but maybe Ludek can with the debug log.

drakinite wrote: ↑Mon Nov 16, 2020 9:22 am I can't seem to replicate that lag from switching views

Maybe library size? I test with a library of 70k tracks.

Re the crash: I see, this happens only when 'Column Filter' is enabled for both Grid and List and also contextual search (to filter matches) is used at the same time.
Entered as https://www.ventismedia.com/mantis/view.php?id=17104 with steps to reproduce

Re the lagging: I'll check the logs, thx

Re the switching views when items are filtered:
- once only the 'Column Filter' is enabled for both 'Grid' and 'List' then the selection in 'Column Filter' is preserved for me
- once the contextual search is active (a phrase to filter matches) then the crash appears ( #17104)
- once the 'Column Filter' is disabled with contextual search active then yes, the results are different in List view (when the phrase 'cap' can be contained within track title) and in Grid (when the 'cap' phrase can be contained only within album or album artist -- less results)

I replicated also the UI lag and added as https://www.ventismedia.com/mantis/view.php?id=17106

Is good that you are on top of most items from the report so quickly.

Ludek wrote: ↑Mon Nov 16, 2020 12:17 pm - once the 'Column Filter' is disabled with contextual search active then yes, the results are different in List view (when the phrase 'cap' can be contained within track title) and in Grid (when the 'cap' phrase can be contained only within album or album artist -- less results)

Is hard to tell, from what you have written, how you feel about this issue, and whether you intend to do anything about it ... ?

It seems to me that it is an unintended consequence from otherwise helpful behaviour ... but IMO it is an unacceptable situation.

I know that All Text search was already available in MM4, but I think that is going to be a much more central feature in MM5, due to your GUI improvements:

• ease of access

• ease of tweaking the original criteria phrase

• addition of facility for search to be contextual to current collection

So I think that it is unacceptable that the facility in MM5 be hard to understand, and appear to be flaky.

Also I think this should be seen as a MM5 bug, because the similar situation works as expected in MM4 ... ie. Search on AllText = 'cap, and then change View from "Show Art" to "Show Art with Details" ... the same results are returned when merely changing View.

Did you see this ... it seems to me that it integrates well into what you have done so far, and is also a standalone worthwhile extension to the existing search|filter syntax rules.

Barry4679 wrote: ↑Tue Nov 17, 2020 1:18 am
Did you see this ... it seems to me that it integrates well into what you have done so far, and is also a standalone worthwhile extension to the existing search|filter syntax rules.

It is related to issues like https://www.ventismedia.com/mantis/view.php?id=16989 that are planned for 5.1 (due to technical complexity)

Ludek wrote: ↑Wed Nov 18, 2020 6:10 am It is related to issues like https://www.ventismedia.com/mantis/view.php?id=16989 that are planned for 5.1 (due to technical complexity)

OK. I probably should have known that. It is hard to keep track of the various stalled parts of this project.

Thanks.

Hi,
Bug 17106 should be fixed in 2283