View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0006157 | MMW v4 | Main Panel/Toolbars/Menus | public | 2009-11-09 13:26 | 2015-02-05 15:13 |
| Reporter | Ludek | Assigned To | |||
| Priority | high | Severity | minor | Reproducibility | always |
| Status | feedback | Resolution | open | ||
| Product Version | 3.1.2 | ||||
| Target Version | 4.0.7 | ||||
| Summary | 0006157: Renaming a genre via node in one Collection affects tracks in another Collection | ||||
| Description | 1. Swith to filter with criteria [Rating > 4 stars] 2. Go to 'Genre' -> 'Rock' node 3. Right-click the node and rename 'Rock' to 'Pop' => all tracks with genre 'Rock' are renamed to 'Pop' although one would expect only those tracks (that satisfy the current filter) will be renamed. This problem exists also when renaming an album, an artist, an folder etc. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
Probably too complex to be included within 3.2 at this release point. |
|
|
Agreed. Possibilities of regressions are nasty. |
|
|
In addition it is speculative whether the current approch is buggy or not. If I e.g. rename artist then I would expect that the artist will be renamed for entire collection, not just for the current filter. |
|
|
Assigning to Rusty for a review. I would also leave it as is (definitely for MM 3.2, but probably rather forever), it seems to me that one can expect either one or the other behavior, so let's stick with the current, simpler one. |
|
|
Ludek: I agree with scope of the current implementation. Songs and track tags are only changed for tracks that satisfy the current filter. The problem is the presentation of the data. The view from the Tree or Basic Search is inconsistent with a raw data view from Searchbar. Searchbar is correct. Tree is incorrect. Your example could be particularly nasty for the user. |
|
|
There are 2 points of view here: 1) Editing the tree is like editing the ontology used throughout the library 2) Editing the tree is like editing the attributes of the tracks in focus Like Jiri, I tend towards the former, but there still the case of users _editing_ the attribute (e.g. changing Rock to Pop), and inadvertently triggering other changes in the library. For such cases i.e. where all of the following hold true: -A filter is active -User changes a node value that has additional tracks in the unfiltered view of the library -User changes the node value to another existing node value (i.e. the change is a change in attribute rather than a correction to the ontology) --> This change will apply to all '<attribute>' tracks in the library--even those outside the '<filter>' collection. Do you want to proceed? |
|
|
Just a note that in 4.0, there will probably almost always be a filter active (because of Video support). |
|
|
The use case for changing the attribute in the tree is straightforward. It is easier & faster to review, e.g. Genres, from the tree, and make corrections there than it is to select all tracks and edit properties. Not sure why you have the last condition. If the usage count for the node is greater than the tracks provided by the filter, then you have changes to non-visible tracks. |
|
|
>"The use case for changing the attribute in the tree is straightforward..." I agree. I'm just trying to say that in most cases, the intent of the user will be to both change the attribute _and_ change the ontology. >"Not sure why you have the last condition..." You're right. The third condition shouldn't be used. |
|
|
An idea here could be to add a simple information box (with option to cancel the operation) if the user tries to edit the node caption and Usage Count <> Count of Tracks in the main window. E.g. something like: "Changing the Genre 'Pop' will affect all tracks in your library and not only the tracks in the main window." |
|
|
It still seems to me to be a little unnecessary, since the operation doesn't result in anything serious. This way we could have warnings about pretty much anything in MM, which makes everything more complex from development point of view and also is rather annoying for many, if not most users. If we really decide to implement it, let's at least keep the message without 'genre', so that there isn't too many messages to be localized. Based on Bex's suggestion, it could be something like: "Changing 'Pop' to 'Pop2' will affect all tracks in your library and not only the tracks in the main window." However, I'd rather not implement it in the first place... |
|
|
Something has to be done. The existing implementation leaves the database in an inconsistent state. The inconsistency can be detected and the link tables reconstructed from raw data. It is better to not have to do any reconstruction at all. 1287 only changes Track attributes for tracks provided by the active filter. This is intuitively obvious to the user. What they see is what they get. This could be maintained by modifying the code which updates, eg. GenresSongs and Genres tables, to create a new Genres row if required (the change may match an existing row) and Update the GenresSongs.IDGenre for the matching (and modified) tracks to the Genres.ID of the target node. No warning would be required. Possibly a big plus given that MM4 will probably have a Filter in effect all the time (per Jiri's previous note). Rusty's design proposal says the change should apply to all tracks which are referenced by the node (the ontology). This could result in unexpected changes to data, thus, the warning. |
|
|
In the current 4.0 design, Genres still span collections. Nonetheless, this issue should be resolved. |
