View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0008599||MediaMonkey (current)||Properties/Auto-Tools||public||2011-11-01 04:11||2012-01-25 22:54|
|Target Version||4.0.3||Fixed in Version||4.0.3|
|Summary||0008599: Tracks with missing Album Artist show Album Artist as if it's been tagged|
|Description||If user scans an album with Title='Title', Artist='Artist', Album='Album', Album Artist="", then it appears as follows in the File List:|
Title, Artist, Album, ...
However, if the user views the same album in the Properties dialog, it displays the above + Album Artist=Artist.
This is confusing to users since they're unclear what is actually contained within the DB--Album Artist="", or Album Artist=Artist.
Note: In MM3, the tracklist displayed Album Artist=Artist, however, that was probably worse than the current situation in MM4, because it implied to users that the Album Artist field was populated--even though it wasn't.
1) display the Album Artist text (in the Properties dialog) that's been 'inferred' from the 'Artist' field in greyed out format, if it hasn't been saved to the tag.
2) don't display the 'recommended' text, but, if the Album Artist field is empty and the user switches to that field, auto-populate it (if appropriate), but leave the entire field selected, so that if the user starts typing, the auto-populated text is deleted.
3) Use the 'infer properties' setting to also control whether 'Album Artist' field is inferred from 'Artist'. The problem with this approach is that the 'Infer properties' function is only active during scanning but applies to the DB, whereas this functionality is active only within the Properties dialog, and doesn't affect the DB.
Failed auto-organize--most likely the same issue:
Albums being moved to Folder unknown by auto-organize (most likely if the user clicks auto-organize from within the properties dialog):
|Tags||No tags attached.|
|Fixed in build||1465|
||Raising priority due to the large number of issue reports. Added a few other ideas. Thoughts?|
The main problem users report is that Album Artist value Unknown is used, this makes no sense as those functions should use (Summary column, Auto-Organize, etc.) should be using the database values instead of the tags in the files.
1) Would be wonderful, but would need to be extended to all tags as otherwise there is an inconsistency that some unsaved tags are shown greyed out and some aren't.
2) I think that would lead to confusion. In any case the auto-population of the Album Artist field with Artist is really useful. I'm not sure that is the problem here, the problem seems to be that various MediaMonkey features don't recognize the auto-populated values when they should.
3) In a sense a good solution other than that Infer can cause strange results and many will turn it off and thus they will no longer benefit from this.
4) Regardless of whether 1 is implemented or not I think an option to auto-populate Album Artist with Artist is the best. This would also help out the real hardcore tag controllers who do not wish anything to be tagged without their consent (as now anytime any tag is updated the Album Artist also gets saved back to the files). The ability to disable Album Artist auto-tagging has been requested a couple times on the forum. This does leave the underlying bug which is using Unknown when DB has values for Album Artist.
I'd say that the best would be to implement two fixes:
2) Seems to make sense to prevent this automatic guessing.
4) Add an option to Library sheet:
[x] Automatically guess Album Artist from Artist field
so that any scanned track that _has_ Artist and Album fields set and does _not_have_ Album Artist would get Artist assigned to Album Artist during scanning. This option could also control whether that auto-filling on field entry (see 2. above) is used or not.
My preference is suggestion 1). Is there a reason why you don't like that approach? I think it would be best, and would also be useful for automatically looked up metadata. I suppose it would require DB changes to support that are too risky for a minor release?
Assuming 1) isn't possible in the short term, I would suggest going ahead with 2) now (for 4.0.3) since there are so many complaints about this issue.
And, I can create a separate bug for 4) since that would have to be deferred to version 4.1 due to new strings.
||Only detail with 1) is that grey is also used for multiple values when multiple files are selected.|
||As discussed with Rusty over IM, 1) might result in some slightly confusing behavior. So, Petr will implement 2) now and 4) will be implemented later.|
||Item 2 implemented in 1464|
||Resolving as item 2 implemented in 1464. Feel free to reopen for item 4.|
||Petr, you forgot to merge the fix into 4.0.3 branch|
||Fixed in 1465|