View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0001807 | MMW v4 | Properties/Auto-Tools | public | 2005-02-10 05:36 | 2007-07-15 05:21 |
Reporter | rusty | Assigned To | |||
Priority | high | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Fixed in Version | 3.0 | ||||
Summary | 0001807: Auto-tag from Amazon should display changes in the same way as other parts of the UI | ||||
Description | Users pointed out that the Auto-tag from Amazon dialog doesn't give any visual cues re. what aspects of the Metadata are new/changed vs. what currently appears. The suggestion was that a visual cue should be displayed to indicate which items will change and that this visual cue be similar to that used for Auto-Tag and Auto-Organize. i.e. have 2 lines for each item and use with yellow highlighting for new metadata, and grey to show old values. | ||||
Tags | No tags attached. | ||||
Fixed in build | 1046 | ||||
|
It has been done. I should mention that I also changed functionality of 'Undo' button so that it undoes changes made by simple editing of individual fields. |
|
By bried testing it looks good, I just don't see that yellow highlighting of modified fields (i.e. artist is 'REM', but Amazon suggests 'R.E.M.', so the field should be yellow until user accepts the change). |
|
You are right that it should behave as described in the last note. Implemented that way in revision 1400. |
|
Currently it doesn't react when a checkbox (e.g. release year) is unchecked - the value is still in yellow, i.e. to be modified. We should somehow catch the event of check/uncheck in WebBrowser and react appropriatelly. |
|
Fixed in revision 1543. i.e. Auto-tag from Amazon reacts according to Web browser's changes now. (when a checkbox (e.g. release year) is checked or not). |
|
Tested in 1005, and it doesn't seem to be working at all :( i.e. No tracks are ever highlighted in yellow, whenever any of the following fields from Amazon are different than what is saved to the tag: Artist, Album, Year, Art, Comments, Label, etc. (i.e. any change to any field or multiple fields has no effect). |
|
I'm not sure what you are pointing to. Do you mean the situation that the new lines' checkboxes are unchecked? Yes, in case of unchecked checkbox the fields contain the old values, but it makes sense. |
|
What I mean is that the results of the amazon lookup differ from metadata that is stored to the tags, there's no yellow highlight to indicate that a difference exists (for the fields/tracks that have been checked off). I've saved an screencap of this to the ftp server, in which the Year field looked up on Amazon differs from the information stored in the metadata, the year field and the tracks are both checked off, and there's still no indication that the Amazon lookup has different metadata! |
|
That is very strange. I can't find any way to reproduce it, see my autotag_amazon_highlight.JPG screenshot -> build 1005 works fine for me. Are you sure that you have been testing build number 1005?? If yes, does it behave this way everytime or is it a special case? |
|
Retested in builds 1005 and 1007 and in both cases, checking off the 'year' field in the ATFA dialog doesn't cause the tracks (which are missing 'Year' metadata) to become yellow. |
|
Found a way how to reproduce both correct and incorrect behaviour, discussed with Ludek, Ludek will fix it soon. |
|
Thx to Jiri for his help in order to reproduce the bug, it is fixed in revision 1628 (build 1008). |
|
Tested in build 1008 and found that it never seems to show/highlight the Year field if the year is absent in the original track. I've posted a screengrab that illustrates this to the ftp server. |
|
In order to reproduce: Uncheck checkboxes, keep e.g. Cover checked, perform auto-tag, close, open dialog again - now it works strangely, modified fields don't get yellow no matter what I do. Also, sometimes Undo button is enabled immediatelly after the dialog is openned, i.e. even before any taggin is made! |
|
I thank Jiri again for finding a way to reproduce. Both bugs fixed in revision 1719. (build 1010) |
|
This is working fine now, I just wonder why the top line (i.e. greyed) is editable, I'd expect the second line to be editable. Assigned to Rusty to comment... (also, should Undo work also for these manually edited fields?) |
|
I totally understand the logic of the current implementation, but you're right that for consistency, it should be implemented in the same manner as the Auto Tag from Filename dialog. i.e. -The second row should be editable (and not the first) -Edits to the second row shouldn't result in immediate changes to the tag--only after the 'Auto-Tag' button is pressed. -As far as undo functionality, you're right--it would have to be able to undo the operation whether the user made manual changes or not. |
|
Currently it works pretty much well. Just, in some cases I'd prefer if the old entries weren't there - this way I could check out the new/current values only, which is quite a tough issue now. I'd suggest to implement a switch between the current mode and the old mode where only modified rows were shown. It could probably be implemented as an item in pop-up menu, something like '[x] Show old values'. Assigning to Rusty for a review. |
|
Sure, though I'd change the wording to: [ ] Show current properties |
|
Added in build 1046. |
|
Verified 1048. |