View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0005461 | MMW v4 | Properties/Auto-Tools | public | 2009-04-02 20:11 | 2011-05-06 16:32 |
| Reporter | rusty | Assigned To | |||
| Priority | low | Severity | major | Reproducibility | always |
| Status | feedback | Resolution | reopened | ||
| Product Version | 3.1 | ||||
| Fixed in Version | 3.1 | ||||
| Summary | 0005461: Inconsistent / Erroneous handling of Artist/Album Artist properties in the Tree | ||||
| Description | There are several issues related to the display, editing, and drag and dropping in Artist/Album Artist nodes: (1) Artist nodes (as opposed to Album Artist and A+AA nodes) contain Album nodes even if the Album is not by the Artist. e.g. Artist=Artist3, Alb Artist=AlbArtist3, Album=AlbNotEqual3, TrackTitle=NotEqual3 In the Artist node, there is a subnode for Artist3 containing a track NotEqual3. However, it also unexpectedly contains a node for an Album=AlbNotEqual3 despite the fact that it isn't the Album Artist for that Album. (db snapshot1). Issue (2) and part of issue (5) cascades from this problem, so fixing (1) by removing the Album node in this scenario might be the simplest approach. Drag and Drop of Album Nodes exhibit some related unexpected behavior. Here's a full test grid (bugs are numbered below):
Case 1 Case 2 Case 3 Case 4
Drag Artist1=Album Artist1 Artist1=Album Artist1 Artist1|=Album Artist1 Artist1|=Album Artist1
to Artist2=Alb. Artist2 to Artist2|=Alb.Artist2 to Artist2|=Alb.Artist2 to Artist2=Alb. Artist2
Artist1>Album1 --> Artist2 A+AA update A+AA update Fail - AA updates (2) Fail - AA updates (2)
Album Artist1>Album1 --> Album Artist2 Fail: A+AA update (3) Fail: A+AA update (3) AA updates AA updates
A+AA1>Album1 --> A+AA2 * A+AA update A+AA update AA updates AA updates
(2) Album Artist field of the Track updates instead of the Artist field! (3) One would have expected that only the Album Artist should update, however both Artist and Album Artist update. It's not that serious, but it's inconsistent with how the properties dialog operates (i.e. it doesn't modify Artist based on changes to Album Artist). --------------- Manual Editing of Artist and Album Artist nodes exhibits a similar problem. Here's the full test grid:
Case1 Case 2
Edited Node Artist=Album Artist Artist |= Album Artist
Artist A+AA Update A updates
Album Artist Fail: A+AA Update (4) AA updates
Artist+Album Artist A+AA Update A updates (4) One would have expected that only the Album Artist should update, however both Artist and Album Artist update. Like item (3) above, it's not that serious, but it's inconsistent with how the properties dialog operates. --------------- The final area where problems were observed is in dragging/dropping of Tracks into Album nodes:
Case 1 Case 2 Case 3 Case 4
Drag Artist1=Album Artist1 Artist1=Album Artist1 Artist1|=Album Artist1 Artist1|=Album Artist1
to Artist2=Alb. Artist2 to Artist2|=Alb.Artist2 to Artist2|=Alb.Artist2 to Artist2=Alb. Artist2
Artist1>Album1>Track1-->Artist2>Album2 A+AA update Fail: AA updates (5) Fail: AA updates (5) A+AA updates
AlbArtist1>Album1>Track1-->AlbArtist2>Album2 A+AA update (3) AA updates AA updates Fail: A+AA updates (6)
A+AA1>Album1>Track1-->A+AA1>Album2 * A+AA update Fail: AA updates (5) Fail: AA updates (5) Fail: A+AA updates (6) (5) In this case the Album Artist updated. I would have expected the _Artist_ to have updated as well. What's bizarre about the current behavior is that when you drag the track to the new node, it reappears in the current node with different attributes (since artist isn't modified)! (6) In this case both Artist and Album Artist are updated, and a user would have expected that only the Album Artist would update. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | 1246 | ||||
|
|
Discussed with Petr over IM and agreed that: 1) Is currently ok based on the idea that: 1a. Artist node shows albums, where given artist has at least one track. 1b. Album Artist node shows albums, where it's an AA. 1c. A+AA node shows combination of both 1a. and 1b. 2) Seems to be ok - we are dragging an Album and in such case a change of Album Artist seems to be logical. Note that I don't think there should be any difference among sub-nodes of A, AA and A+AA nodes - we are interested in the value, not whether it was originally Artist, Album Artist or both, from Album point of view, we should always change Album Artist. 5) It's driven by the target Album, when it looks like multi-artist album, only Album Artist is modified. 3,4&6) We chose to modify both A+AA in case it makes at least some sense. The consistency with Properties dialog is slightly questionable, but they are also two slighly different things. In Properties dialog we need a way how to modify A and AA to different values in case they are originally the same. In general, I think that one could look on these issues from many angles and have different opinions, but the current solution seem to make _some_sense_ and there doesn't seem to be another clearly superior solution. Therefore, particularly for 3.1, I don't see any change to be needed. |
|
|
1a) I understand that the Artist node shows Albums if the Artist has one track. My point is that it's inconsistent. In all other cases (even in the A+AA node), Albums are shown as children of _Album_Artists_ and not of Artists. Showing an Album as a child implies that the Artist is also the Album Artist even though it isn't! 2) I think that any user would expect that if they're dragging something from Artist A to Artist B, that the Artist field would change from A to B. e.g. if it were possible to drag an Album into Genre:Blues, the user would expect that all tracks on the Album change to Genre:Blues. The user's expectations are based on what they see in the tree. 5) You have to try this to appreciate how bizarre it is. You drag a track from A to B and then it reappears in A with other attributes modified. Again, this would be puzzling to any user. 3,4) I tend to agree that either approach can make some sense, so I don't think it's high priority. 6) In my test case, A|=AA so I'm not sure why it made sense to change both Artist and Album Artist. Summary: i think we should fix issue (1) (it appears very low risk), which would automatically cause issue (2) and 2 cases of issue (5) to be resolved. 3,4) Can wait. (5), (6): if they're high risk, they can wait, though as I mentioned, (5) is completely bizarre. |
|
|
1a) Ok, so, let's remove this. Note that this also involves removing it in 1c). 6) If I understand the table correctly, then A=AA in the target album, which is used for decision in this case (as an indicator, whether it's a multi-artist album or not). |
|
|
1a) removed in 1232 |
|
|
Verified items 1 and 2 in build 1233. Re-opened for remaining issues post-3.1. |
|
|
I'm not sure, based on the discussion above, do we really want to change anything else? I'd rather set as Resolved and just modify other items in case the prove to be problematic. |
|
|
in the artist node, why not just add whatever the current album artist to the expanded album (ie compilations). example: artist + abba ++ greatest hits (abba) ++ now! music 123 (various) or alternatively, only add the (various) when the album artist is different than the artist: artist + abba ++ greatest hits ++ now! music 123 (various) This would make it (the expanded album nodes) more consistent visually to the album node, having the album artist in (parenthesis) following the album name. |
|
|
see user discussion @ http://www.mediamonkey.com/forum/viewtopic.php?f=6&t=39390 and above comment |
|
|
It seems that the cure was worse than the disease (see the link in the comment above). There _are_ many problems with the drag and drop behavior that make it unclear what attributes will change in certain d&d operations, however, fixing them by making the change 1a) seemed to cause much user dissatisfaction. I recommend that we revert that change immediately, and fix the d&d behavior in the future. |
|
|
Reverted in build 1246. |
|
|
Verified in 1246. Re-opening to evaluate a proper fix to the original d&d issues. |
