View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006666 | MMW v4 | Main Panel/Toolbars/Menus | public | 2010-11-09 11:06 | 2011-06-14 11:11 |
| Reporter | Ludek | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | assigned | Resolution | reopened | ||
| Product Version | 4.0 | ||||
| Fixed in Version | 4.0 | ||||
| Summary | 0006666: Find more from same -> Album is no longer available (regression) | ||||
| Description | This is a feature I use a lot, but it is no longer available in recent builds. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1335 | ||||
|
|
This is caused by this condition: if MainTree.IsVisible[ TB.AlbumsNode[FLT_NONE]] and (SD.Album<>'') then and it means that the bug is reproducible only if 'Entire Library' is not visible or its 'Albums' subnode is not visible. Shouldn't we make 'Entire Library' always visible? |
|
|
As discussed over IM with Petr, it should be fixed like this: 1. If it's clear which collection we are at, this collection should be used (e.g. if we are in a node, which is a sub-node of a collection). 2. If it isn't clear which collection to use, it should be used based on Type of the focused track (e.g. if we are in Now Playing or a Playlist). The first visible collection that contains given Type should be used. 3. Note that we should also modify the visual aspect of this feature - e.g. if working with Video, instead of Artist we should use Director in the pop-up menu. |
|
|
Fixed in 1324 |
|
|
verified 1325 |
|
|
Re-opening, while fixing 0006936 I found one instance when it fails: 1. Load some Music tracks to 'Now Playing' list 2. Select any director subnode like Video -> Director -> Director1 3. Right-click a music track on the right (in 'Now Playing') and select Find More From Same -> Album => MM fails to find and focus the album node |
|
|
Based on current internal logic it's correct (MM is trying to locate album in current collection). Assigning to Jiri whether we should change this logic to something more sophisticated (if wasn't found on current collection, try in another ?). |
|
|
The problem seems to be that step 2. as I described above (http://www.ventismedia.com/mantis/view.php?id=6666#c21275) isn't implemented. As described there, if the search is made from outside of a Collection (which includes a NP window, as there isn't any Collection specified), then we should first find a good Collection for searching, based on Type of track. For example. a. User executes Find more from Album on a Music track in NP. b. In this case it _isn't_ important which Collection is selected in Tree. c. We should go through visible Collections and find the first one that contains Music type. d. Alternatively, we could also make sure that the track actually belongs to this Collection. This step probably isn't necessary, but might be useful in case user configures more collections/filters. e. Find more from ... is performed on the Collection found in steps c&d. |
|
|
Fixed in 1335 |
|
|
verified 1343 |
|
|
The current problem in 1388 is that if FMFS is used it will fail if just Entire Library and a Custom Collection (that doesn't contain FMFS results) is enabled. The problem with trying to use a Collection that matches when using FMFS out of Collection is that Collections can have filters excluding results. I suspect that using the following order would work better for out of Collection FMFS: 1) Use Entire Library if available 2) Use default Collection based on type if available 3) Use custom Collection Both 2 (user can modify default Collection) and 3 run across the problem of results of FMFS being filtered out by rules set by user. Ideally FMFS would evaluate if rules do filter out results. Alternatively out of Collection always uses Entire Library and if disabled shows the Entire Collection temporarily like the Search node. Alternatively to that FMFS runs a specific search instead of opening Collection (FMFS on Artist would run Artist:query in the search node). |
|
|
Assigning to Rusty for a feedback. |
|
|
Additionally there could be a user setting that would allow user to choose: 1) Always create search on FMFS use 2) Always open FMFS in Entire Library (even if hidden) 3) Use current method (not sure how to describe it) I have seen some forum posts suggesting some user would prefer FMFS to perform a search instead of opening corresponding node in Library (now Collections). |
|
|
From my perspective: 1) If FMS is operating within a Collection, by default FMFS should search the current collection by opening a node. 2) If FMS is operating on a track that isn't within a Collection (e.g. NP, My Computer), it might be simplest to allow the user to return results within a Search node instead. Ideally, the Search node would show 'Entire Library: <field> contains <search term>' (but this would imply additional changes--currently Searches don't persist the library to which they apply. 3) Optional: For case 1), a simple means of allowing the user to choose to return FMFS results as search results instead of as a node (without adding new strings) could be via a checkbox below a horizontal bar: [ ] <Current Collection> [ ] Entire Library Just a thought... |
|
|
I think something like that would work. |
|
|
I'm afraid that the proposed solution introduces a small inconsistency, which isn't nice. As discussed over IM with Petr, we are able to fix this for almost all cases that can realistically happen. The only problem is in case when user tries to find a track that 1. Isn't in DB, and 2. Entire Library isn't visible, and 3. other specific condition re. visible collections. We will be able to fix this remaining (almost negligible) issue later after 4.0, but since it isn't a trivial fix, there's no rush. |
|
|
Implemented in 1390. Reducing priority for further fix. As discussed with Jiri by IM we've updated to work this way: 1. use current selected collection 2. if 1 fail, try to find track in visible collections (it's new step) 3. if 2 fail, try to find collection (from among visible collections) based on Track type 4. if 3 fails, try to find in 'Entire Library' (if it's visible) Also in 1390 added a detection to show track related items in FMFS popup only when track can be located in visible collections. |
