I guess the closest to my practices are the last 3 cases.

The procedure I have been using is to:
1)Run the FTE Inconsistent Album Art node
2)Sort by AlbumArtist+Album
3)Review results, then:

Case: Track in music blogs download area duplicates main album track.
- Copy & Paste play history metadata from music blog track to main album track
- Remove music blog track

Case: Downloads only, unknown album
- Bah. Either ignore it or remove all album art. Without known album difficult to apply correct Album Art.

Case: Downloads only, known album
- Scroll through list of tracks and pick one as seed, or
- Use Batch Art Finder to get new Album Art
- Cleanup using procedure for next case

Case: Main album/Part of main library. No duplicates.
- Select (usually) first track of album.
- Properties->Album Art.
-- Review.Clean up (if needed).
-- Make sure Apply to Album is checked.
-- Click OK

Case: WTF. I fixed this already.
- SQL Viewer time. Review Covers table and take appropriate action. Objective, remove visible inconsistencies in database.

4)When finished, F5 refresh the node and review results.

PS: I apply General Music filter before running the node. Podcast album art is a dog's breakfast. e.g. NPR has a unique Album Art description for each episode.

Good luck.

Ludek wrote:If the CoverDescription is in the DB than it really should appear on the Album Art panel in track properties. Are you sure it is really the track with id 7011 and not a duplicate track?

Yes this is the only track with this id.

Owyn wrote:Two observations.
1)Song 7011 has a conlicting (ie. existing) description to the rest of the tracks in the album.

According to the sql it does but not according to the properties panel it does not.

Owyn wrote:2)The song ids are a bit strange. Normally I see close to consecutive id's for a single album. 7010 and 7011 seem apart from the 12141+ tracks.

Not really I do not always add tracks to my library based on album, most times I only add single tracks from an artist. The only times the entire album will be added together is if I purchased the entire album, which is a rarity for me.

Owyn wrote:One other thing I found last night, it is useful to set View->Album Art and then scroll through each track. The album that I thought was ok actually had no album art on 2 out of 11 tracks. The basic select I gave you will not catch that problem.

I already did this which led me to believe that this album is not actually a discrepancy.

If the CoverDescription is in the DB than it really should appear on the Album Art panel in track properties. Are you sure it is really the track with id 7011 and not a duplicate track?

Two observations.
1)Song 7011 has a conlicting (ie. existing) description to the rest of the tracks in the album.
2)The song ids are a bit strange. Normally I see close to consecutive id's for a single album. 7010 and 7011 seem apart from the 12141+ tracks.

One other thing I found last night, it is useful to set View->Album Art and then scroll through each track. The album that I thought was ok actually had no album art on 2 out of 11 tracks. The basic select I gave you will not catch that problem.

Edit: JIC:

Here is what the sql says is a discrepancy in the album:



Here is what the Properties Panel has for the track with the description from the sql statement, notice there is no description:

Ummm. There is a real problem.

I just ran the node and checked an album that I KNEW WAS OK both via SQL and select all tracks for album->Properties->Album Art and checking the tool tip for each image.

No visible differences.

Anyway, that really is it for tonight.

Thanks, I am getting a little frustrated when albums keep appearing here when they shouldn't, especially since they are albums which I am not "touching". But like you I am a little tired, I have been upgrading my husband's XP computer to Win7 for most of the day. I'll c u on the other side.

Nyn

Nyn:
I have been using this function a fair amount recently. Usually caused in my case by conflict between real albums and tracks downloaded from music blogs. However, I think I have seen a couple of cases where albums were showing up without obvious reasons.

Getting too tired to think straight at the moment, but, I can give you some SQL/script tomorrow which will let you see exactly where the problem is coming from. Thinking of a report which replicates tracks on node but includes reason for inconsistency.

Ludek wrote:And are you sure you are watching Covers with CoverOrder = 0 ? i.e. it checks consistece only of the first cover for each track

Yes, I only have 1 cover art for each track and they all have them embedded and set as the front cover.

And are you sure you are watching Covers with CoverOrder = 0 ? i.e. it checks consistece only of the first cover for each track

That is what I am saying, some of the tracks of the album have a coverpath and some of them don't, so they should be showing up in the node but they are not showing up.

As I have written, CoverPath is one of the attributes MM is checking. If all tracks on an album have same CoverPath and also same the remaining attributes then there is no need to show them under IAA node, because they have consistent AA.

Ludek:

Are you sure the CoverPath is one of the options the IAA node is checking? I removed all the descriptions from the Covers table and checked the node again, there should have been 8 albums listed since tracks from these 8 albums had a CoverPath, but they did not show up. Also, they may have not been listed because although the tracks had two covers, there were not two covers listed for them in the table.

Nyn