"Browse Artists" only shows a small subset of artists

[cbemoore]

I moved over from 7.3.4 to 7.4 about a week ago, and its massively improved compared to the last time I tested 7.4 a couple of months ago.

So far, I've only come across one major problem. For some reason, "Browse Artists" only shows a small subset of the artists in my library. This happens both on my SB and on the web interface.

The albums appear to have been correctly scanned, since they show up correctly under "Browse Albums".

Is this a known problem? Is it anything to do with my large (26000 song) library? Should I file a bug?

(By the way, I'm running on Windows 7 build 7264, and installed 7.4 on top of my existing 7.3 installation. Could this be related?)

[Phil Leigh]

I moved over from 7.3.4 to 7.4 about a week ago, and its massively improved compared to the last time I tested 7.4 a couple of months ago.

So far, I've only come across one major problem. For some reason, "Browse Artists" only shows a small subset of the artists in my library. This happens both on my SB and on the web interface.

The albums appear to have been correctly scanned, since they show up correctly under "Browse Albums".

Is this a known problem? Is it anything to do with my large (26000 song) library? Should I file a bug?

(By the way, I'm running on Windows 7 build 7264, and installed 7.4 on top of my existing 7.3 installation. Could this be related?)

26,000 is not large.
Which artists are missing?
Is it artists that have whole albums or just those that appear on tracks on compilation albums?

[cbemoore]

Thanks for the reply, Phil.

The problem doesn't seem to be restricted to compilation albums or a particular file type. I finally found some time to do some investigation this morning, and it appears to be database-related.

On my Squeezebox, if I browse to a track and press "right" to get the track information, I see the following:

All my tracks have an "album artist" field correctly set. In addition, some of my tracks have an "artist" field (these tracks show up correctly in "Browse Artists"), whereas other tracks have a "track artist" instead (these tracks do NOT show up in "Browse Artists").

I don't think this is a tagging problem - it should be sufficient for a track to have "album artist" and "track artist" tags, without having to add an additional "artist" tag. Also, 7.3 lists all my tracks correctly, so I'm pretty sure its a regression with 7.4.

Does this help? Am I making any sense? And should I raise a bug?

[michael123]

I have same problem..
**Sometimes** - depending how I navigate to the 'Artists' - I get 2 albums, instead of 4.

I cleared the library and rescanned few times.

[cbemoore]

Just downloaded the latest nightly (now that it's reverted to MySQL), and all my artists are back! So it was obviously something to do with the SQLite implementation...

[cbemoore]

Aaargh - I spoke too soon....

In today's nightly (r27990) loads of my artists have disappeared again. Everything appeared correctly in yesterday's nightly (r27942), so it must be down to one of the changes which were merged back from the SQLite branch yesterday.

Is there anything I can do to help with debugging? Is now a good time to raise a bug?

[Phil Leigh]

Thanks for the reply, Phil.

The problem doesn't seem to be restricted to compilation albums or a particular file type. I finally found some time to do some investigation this morning, and it appears to be database-related.

On my Squeezebox, if I browse to a track and press "right" to get the track information, I see the following:

All my tracks have an "album artist" field correctly set. In addition, some of my tracks have an "artist" field (these tracks show up correctly in "Browse Artists"), whereas other tracks have a "track artist" instead (these tracks do NOT show up in "Browse Artists").

I don't think this is a tagging problem - it should be sufficient for a track to have "album artist" and "track artist" tags, without having to add an additional "artist" tag. Also, 7.3 lists all my tracks correctly, so I'm pretty sure its a regression with 7.4.

Does this help? Am I making any sense? And should I raise a bug?

a-ha!

Your tags need to be ARTIST (for the tracks) DO NOT USE "ALBUMARTIST" or "ALBUM ARTIST"...


You should only add ALBUMARTIST in a very specific scenario (where you want to override normal compilation behaviour).

[JJZolx]

You should only add ALBUMARTIST in a very specific scenario (where you want to override normal compilation behaviour).

It does no harm to include ALBUMARTIST tags that match exactly the ARTIST tags. In a sense it's redundant, but I make a point of having an ALBUMARTIST for every album that isn't a compilation. With the way SqueezeCenter works to retrieve an artist to display for an album, it actually speeds things up slightly by not running extra SQL queries to find all the artists on all the tracks on an album.

[Phil Leigh]

It does no harm to include ALBUMARTIST tags that match exactly the ARTIST tags. In a sense it's redundant, but I make a point of having an ALBUMARTIST for every album that isn't a compilation. With the way SqueezeCenter works to retrieve an artist to display for an album, it actually speeds things up slightly by not running extra SQL queries to find all the artists on all the tracks on an album.

Jim - yes I agree, but there have been a few cases recently where folks have had inconsistent tags (accidentally) between track artist and album artist.
Which queries are helped by the presence of the AA tag? - I'd like to test that out.
Thanks
Phil

[JJZolx]

Which queries are helped by the presence of the AA tag? - I'd like to test that out.

Heres' the code from \server\Slim\Schema\Album.pm

# Return an array of artists associated with this album.
sub artists {
  my $self = shift;

  # First try to fetch an explict album artist
  my @artists = $self->artistsForRoles('ALBUMARTIST');
  
  # If the user wants to use TPE2 as album artist, pull that.
  if (scalar @artists == 0 && $prefs->get('useBandAsAlbumArtist')) {
    @artists = $self->artistsForRoles('BAND');
  }

  # Nothing there, and we're not a compilation? Get a list of artists.
  if (scalar @artists == 0 && (!$prefs->get('variousArtistAutoIdentification') || !$self->compilation)) {
    @artists = $self->artistsForRoles('ARTIST');
  }

  # Still nothing? Use the singular contributor - which might be the $vaObj
  if (scalar @artists == 0 && $self->compilation) {
    @artists = Slim::Schema->variousArtistsObject;
  } elsif (scalar @artists == 0) {
    @artists = $self->contributors;
  }
  return @artists;
}

First see if there's an albumarist, then try band (if pref is set). If none found, get every artist on the album. By having an albumartist for the album, you essentially short-circuit this at the first query.

Actually, with the way I've tagged my library, the last

@artists = $self->contributors;

works perfectly and requires no queries at all. I've just moved it to the top but I don't know how much faster it is.