from http://bugs.musicbrainz.org/ticket/2660

When performing the analyze function, my LCD monitor does a great job of hiding the "slightly" gray text of the PUIDs-in-waiting. I'd like to see a more dramatic indicator, like a red strike-thru or a different icon, or a different background color, or italic / bolded text. Almost anything would stand out better than the slight gray that's being used now.

A different icon would be great IMO, and I'd love to see the background turn to pink after the analysis of each one is finished. That way I can remember to save the files to make the PUIDs stick.

But the paradigm that's being used is flawed in more than just this one case. Any changes made either by analyzing, or manual tag edits are being ignored when the file is dragged from a cluster to an album on the right-pane.

For example, I had an album worth of mp3s clustered and analyzed, but they didn't auto-match an album on MB (which is not necessarily a problem with this obscure album).

I figured that there was no album on MB, so I began to edit the tags manually. They had a pattern like "album/artist/title" in the title tag but the file name had dropped the slashes so they came out looking like "albumartisttitle.mp3". Obviously, I couldn't use the tags-from-filename tool, so I just manually moved the data around from the title tag to the other tags on all 30 songs. Color me annoyed.

As I did this, I recognized the album name as one that I saw on MB, so I manually looked-up the album and actually found it on MB. I sent the album ID to the tagger and then I dragged the (manually fixed) songs from the cluster window over to the album window on the right-pane.

I was astonished to see a flood of pink, yellow, and red in the album! When I looked closely, I noticed that all my manual edits were gone (or were just being ignored by the GUI) - which explains why nothing matched very well.

PicardQt acts like the manual edits and the newly-created-PUID field are being stuffed into memory somewhere that isn't being used to match the data on the right-pane. I haven't tried this yet, but I suspect that if I had saved those edits and then unloaded / reloaded those files, I'd have gotten a bunch of forest-green color when I dropped them onto the album. I'll find another test case and let you know if this is true.

It's not that the color means anything, but when it can't "greenly" identify the tracks, it puts them into the wrong places more often than not. The green ones, are usually spot-on. The fact that I had just editted those 30 tracks and then had to check / re-order them after dropping them on the album made me less than happy.

In any case, I think the analysis and the manual user edits should be going into the same place that is being used to match the albums on the right-pane and everything else. I think the "before" tags are being used now, and I wish the "after" tags were being used instead. Does that make sense?

I also think the act of saving the data (in all cases) should cause a reload of the "before" data, as a precaution against cache-sync problems like this in the future. That way, if something goofy happens, you can save the song and get everything back to normal instead of having to manually remove and reload the songs. This would at least be a work-around for the manual-edits-being-ignored problem which may be a bit messier to actually fix.