Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[creal]

Hello,

I have several views (#ALL, Acoustic, Dances, Electro, Jazz, etc.) because of a huge audio library.

I noticed that if you click on the little arrow button to "dive" into an artist, genre, or album, it searches from the current library view. It's by design and I understand that it makes sense for people, even if for me it should be better to automatically switch my main view (#ALL) when clicking on this arrow.

Here is the real problem: I am listening to songs from, say, the "Electro" view. I then go to a playlist. From there, I see a Jazz album that I'd like to "dive" into. I click on the little arrow, nothing is displayed because it searches from the "Electro" view, which is the last focus library view before switching to a playlist. From my point of view, it's an inconsistent behavior.

Are you experiencing the same problem? What are the solutions for this, please?

Note I am running MC28 on the last Windows 11 update.

Thanks for helping.

[creal]

Hello,

No one to help here?

Please note that the problem also happens with the "playing now" view, not just playlists.

[HPBEME]

Something more specific than "the little arrow button" is needed.  MC has lots and lots and lots of "little arrows", and depending on which skin you are using, an arrow is sometimes depicted by a different glyph/graphic.  I am also unclear what "dive into" means... Does that mean search?

Screenshots are invaluable.

[creal]

Thanks HPBEME,

You're completely right. Here is an enclosed screenshot.

If I click on the little arrow to "search for" (this is the right term, instead of "dive into") Laura Cahen, it will not find this artist because I was in the "Electro" library view before switching to playing now (hence it will show the search field with "Laura Cahen" in the "Electro" view although I'd like to search into my entire library).

[HPBEME]

Those "little arrows" that prefix list line items are called "link arrows".  You can select which fields that MC will add those to via options (see pic below).

I click these links all the time when I use MC and have never had a problem.  For the heck of it, click on the View's Tab/Button first and then click on the link. If that doesn't work, try clicking on the tree item Player, and then the link arrow.  If something different/interesting happens with either of those two approaches, screenshot it so I can see the result. A screenshot of what you're getting currently after clicking the link would be useful as well.

[creal]

Thanks for your help.

The link arrow works well: it searches for the artist. But it always searches from the last library view, which, in my case filter exclusively by storage folders. So if I am on the "Jazz" library view, then go to the playing now and click on the link arrow of a song that is not located in the "Jazz folder", it's useless because the search result will be on the "Jazz" library view.

In the screenshot, you can see that the search shows no result, which is logical since Laura Cahen is not Jazz music. My wish is that the search would always be on the "#ALL" library view, which gathers all of the music files. In that case, searching for Laura Cahen (by clicking on the link arrow) will show results.

******************

By the way, I'd like to know if you can send me a screenshot of your options for the "artist" field. In my case, I noticed a problem when clicking on a link arrow of two simultaneous artists: it only searches for the first one instead of both. The thread concerning that problem is here: https://yabb.jriver.com/interact/index.php/topic,135820.msg940864.html#msg940864
Apparently, it works well in MC31, but not in MC28 which is the version I own. But who knows, maybe there is an option I have to change to make it work.

Thanks in advance.

[markf2748]

@creal:  I believe the Link Arrows auto-populate the MC Search box, so everything you say and your search results are consistent with MC's definition of Search:
https://wiki.jriver.com/index.php/Search_Bar

All my views are different ways of listing my full library, so I haven't tested your restricted files use case.  The view recursion behavior you report from a playlist sounds similar to that seen when clicking a Link Arrow in a Playing Now "Player" tab.  That always succeeds for me since all my tabs have the same search universe.

Seems you need a new Search box option which overrides the default, allowing you to specify which collection/view to search in from a Playlist.  Or MC could make a Search Bar exception for Playlists, so that it searches the full library path rather than starting from a restricted view.

[HPBEME]

This has nothing to do with MC28 versus MC31 -  I've been using link arrows for many versions prior to (and including) MC28 with zero issues.

When you click on a link arrow, it auto populates the search box as Mark noted, which then searches whatever you have defined for the Top Level Audio View (see pic).  This is the key - How have you defined your top level audio view?  If this view is restricted to some subset of your audio library, then that is all it will search (which has nothing to do with the last view focused). 

As long as your Top Level Audio View is not restricted to a subset of your full audio library, clicking on the link arrow should search everything in your audio library.  This applies to wherever/whenever you click the link arrow, be it in a Playing Now list, or a list of genres/artists/albums/tracks.  When you click a link arrow, it searches whatever you have defined for your Top Level Audio View. 

Note that the search results will also be displayed in the same style you've defined for the Top Level Audio View. For example, if your top level audio "View as" is Panes (which is how I have mine set up) then after you click the link arrow the "search results" also display as a Panes view.   If your "View as" is defined as "3D", after clicking a link arrow the search results also display as "3D".

[markf2748]

... searches whatever you have defined for the Top Level Audio View (see pic).  This is the key - How have you defined your top level audio view?  If this view is restricted to some subset of your audio library, then that is all it will search (which has nothing to do with the last view focused). 

As long as your Top Level Audio View is not restricted to a subset of your full audio library, clicking on the link arrow should search everything in your audio library.  This applies to wherever/whenever you click the link arrow, be it in a Playing Now list, or a list of genres/artists/albums/tracks.  When you click a link arrow, it searches whatever you have defined for your Top Level Audio View. 

Sorry, but this all sounds a little confused to me.  Here's what I find:
1) When I click on Audio in the tree from an unlocked tab, then that tab opens to the last Audio view I clicked in the tree.
2) If I click Audio in the tree from a locked tab, then a new adjacent tab opens with the last Audio view I clicked in the tree.
3) If I RMB Audio in the tree, I can choose to Customize View.  But that just adds a new audio view to the list.

So tree Audio has some "memory" to it, somewhat analogous to what has been described earlier in this thread for the Playlist Linked Arrow search path.

Seems to me that the Audio "universe" is defined only by the original library path definition.

Also, if you launch a search from any restricted view, then the search range is limited to the files actually displayed in that view.  See the wiki page for "Search Bar" I cited above.

[HPBEME]

1) When I click on Audio in the tree from an unlocked tab, then that tab opens to the last Audio view I clicked in the tree.
2) If I click Audio in the tree from a locked tab, then a new adjacent tab opens with the last Audio view I clicked in the tree.
3) If I RMB Audio in the tree, I can choose to Customize View.  But that just adds a new audio view to the list.

Yep. Whether MC opens a new tab (because the active is locked), or uses the same (unlocked) tab, it still searches whatever is defined for the top level Audio view.

My guess is that you and the OP have never specifically defined a top level Audio view.  This would be logical if you have never checked the "Enable Tree Selection" box in the Customize View dialog (see pic).  If that is the case, I don't know what MC defaults to using.  I have always had a defined view associated with the top Audio view, and for that scenario it behaves exactly as I described in my previous post, in a 100% repeatable way.

I suggest enabling the checkbox, creating a top level Audio view - you can then confirm what I am saying is accurate.  After defining the view, you can even uncheck/disable "Enable Tree Selection" box if you wish.  MC will continue to use the view you just defined for the link arrow click, but will not show that view when you click Audio in the Tree, since that it is now disabled (again).  Just be sure to define a view that includes your entire audio library.


Oh... and

Also, if you launch a search from any restricted view, then the search range is limited to the files actually displayed in that view.  See the wiki page for "Search Bar" I cited above.

This is exactly what I said in previous post here:

If this view is restricted to some subset of your audio library, then that is all it will search (which has nothing to do with the last view focused).

[HPBEME]

I just did a little more checking - when I uncheck the "Enable Tree Selection", MC does appear to use the last active tab/view for the link arrow click search results. This means my suggestion from my last post would solve the problem, but not the second part of the recommendation (crossed out below).  To have the link arrow search results behave in a completely consistent manner, you do need to have the "Enable Tree Selection" box active.  Disabling reverts to the behavior you are getting right now that is causing the problems.

I suggest enabling the checkbox, creating a top level Audio view - you can then confirm what I am saying is accurate. After defining the view, you can even uncheck/disable "Enable Tree Selection" box if you wish.  MC will continue to use the view you just defined for the link arrow click, but will not show that view when you click Audio in the Tree, since that it is now disabled (again).  Just be sure to define a view that includes your entire audio library.

[marko]

when I uncheck the "Enable Tree Selection", MC does appear to use the last active tab/view for the link arrow click search results.

"Unchecked" is the default MC setting for all of the 'top level' library views.

[markf2748]

@HPBEME:  Thanks a lot for your clarifications.  I confirmed that what you say about Audio and Link Arrow searches is correct.  To summarize:

• When the box (tree Audio RMB > Customize View... > Settings > Tree > Enable Tree Selection) is checked, the top level Audio Library View is automatically used in Link Arrow searches from Playlists, SmartLists, and the Playing Now "Player" tab.  The top-level view can be defined to include the entire Audio library.
• If the box is unchecked, only sub-level Audio views are available for selection in the tree.  Then a sub-level Audio View is used (which one is not always predictable from the selection) in Link Arrow searches from Playlists, SmartLists, and the Playing Now "Player" tab.

I too expect that these considerations will solve the OP's issue.

6/1/2023 Corrected the bullets.  Hopefully they are now accurate (if not, please comment).

Win 10/11 Pro (64-bit)  MC 30.0.96/31.0.17

[markf2748]

"Unchecked" is the default MC setting for all of the 'top level' library views.

Thanks for that tidbit. 

I wonder if it would make better sense to define a fixed default for the top level Audio Library View which included all Audio files, applicable whether the checkbox is checked or not.  That would provide more stable and expected default behavior of the Playlist Link Arrow searches.

In any case, with current default, one can never be 100% sure which sub-view is active during Playlist Link Arrow searches, which is a poor state of affairs.

6/1/2023 Correction:  When a Link Arrow search result is displayed, either "Audio" or the active Audio sub-view for the search (depending on Audio checkbox) is highlighted in the tree and also appears in the tab label text.  However, for sub-views, I find it is not always predictable which sub-view will be used in the search if the "allow tree selection" box is unchecked for some sub-views.

[HPBEME]

"Unchecked" is the default MC setting for all of the 'top level' library views.

That was my suspicion when I suggested Mark and the OP probably did not have it enabled.  Thanks for the confirmation.

@HPBEME:  Thanks a lot for your clarifications.  I confirmed that what you say about Audio and Link Arrow searches is correct.

Whooo Hooo! I would have been very surprised/frustrated if that turned out to not be the heart of the issue.

I wonder if it would make better sense to define a fixed default for the top level Audio Library View which included all Audio files, applicable whether the checkbox is checked or not.  That would provide more stable and expected default behavior of the Playlist Link Arrow searches.

In any case, with current default, one can never be 100% sure which sub-view is active during Playlist Link Arrow searches, which is a poor state of affairs.

Agree with that. I use link arrows all-the-time, and am completely dependent on how it behaves for my setup (i.e., with "Enable Tree Selection" option checked). I personally consider those "little arrows" to be one of MC's most important features.

[creal]

@creal:  I believe the Link Arrows auto-populate the MC Search box, so everything you say and your search results are consistent with MC's definition of Search:
https://wiki.jriver.com/index.php/Search_Bar

It's not. A user confirmed that, in MC31, clicking on a link arrow of two artists separated by a semicolon searches for all the songs of one or the other artist. It seems that I just need to upgrade.

[creal]

Yep. Whether MC opens a new tab (because the active is locked), or uses the same (unlocked) tab, it still searches whatever is defined for the top level Audio view.

My guess is that you and the OP have never specifically defined a top level Audio view.  This would be logical if you have never checked the "Enable Tree Selection" box in the Customize View dialog (see pic).  If that is the case, I don't know what MC defaults to using.  I have always had a defined view associated with the top Audio view, and for that scenario it behaves exactly as I described in my previous post, in a 100% repeatable way.

I suggest enabling the checkbox, creating a top level Audio view - you can then confirm what I am saying is accurate.  After defining the view, you can even uncheck/disable "Enable Tree Selection" box if you wish.  MC will continue to use the view you just defined for the link arrow click, but will not show that view when you click Audio in the Tree, since that it is now disabled (again).  Just be sure to define a view that includes your entire audio library.


Oh... and
This is exactly what I said in previous post here:

Defining a top-level audio view did the trick! I was not aware of such a feature! Thank you very much