Jump to content

Incorrect AlbumArtist, Artist and Composer Item Counts


Go to solution Solved by bkreeger,

Recommended Posts

Posted

Hi, After updating from Emby Server 4.8 to 4.9 today, my JS script that counts AlbumArtists (2,142), Artists (12,549) and Composers (9,242), using the API, is now returning inflated totals (15,743) for all three entities instead of the expected totals.

Other item counts for Songs, Folders, Collections, Playlists... and more... are all still working correctly.

My script hasn’t changed. All counts were working correctly yesterday. The only change has been 4.8 to 4.9.

There doesn't seem to be any obvious sum that gives 15,743?

Has the /Artists endpoint behavior changed in 4.9?

Is there a new recommended query for distinct top-level artist entities?”

Any basic advice/information would be appreciated (I am not a professional developer). Cheers!

Posted

Hi, what is the query being used?

Posted
  fetchCount('http://localhost:8096/emby/Items?IncludeItemTypes=Folder&ParentId=4&Recursive=false', folderCountDiv);
  fetchCount('http://localhost:8096/emby/Artists?ArtistType=AlbumArtist&ParentId=4&Recursive=true', albumArtistCountDiv);
  fetchCount('http://localhost:8096/emby/Items?IncludeItemTypes=MusicAlbum&ParentId=4&Recursive=true', albumCountDiv);
  fetchCount('http://localhost:8096/emby/Items?IncludeItemTypes=Audio&ParentId=4&Recursive=true', songCountDiv);
  fetchCount('http://localhost:8096/emby/Artists?ParentId=4&Recursive=true', artistCountDiv);
  fetchCount('http://localhost:8096/emby/Items?IncludeItemTypes=BoxSet&Recursive=true', collectionCountDiv);
  fetchCount('http://localhost:8096/emby/Items?IncludeItemTypes=Playlist&Recursive=true', playlistCountDiv);
  fetchCount('http://localhost:8096/emby/Artists?ArtistType=Composer&ParentId=4&Recursive=true', composerCountDiv);

All of the /Items still work as they previously did.

All of the /Artists now return 15,743 which does not match any of the 3 item count totals shown in Emby.

Posted

Well what do you see when browsing the web app? if those counts look right then I would compare your query to what it is sending.

Posted

Thanks for the tip… I’ve tested quite a bit more and still have a problem with API count inconsistency between 4.8 and 4.9. Version 4.8 is still accurate, but 4.9 returns an unfiltered list (and combined TotalRecordCount) of total unique AlbumArtists+Artists+Composers for all queries…

Here is what I did…

  • New test portable installation of 4.8
  • New test portable installation of 4.9
  • Both Servers have 1 music library pointing to the same source folder
  • This folder has 1 test album with a non-unique total of 7 AA+A+C entities
  • 1 Artist is also a Composer so there are 6 unique total entities
  • Used Swagger/REST API ArtistsService to auto-generate identical queries

Here are the results…

image.thumb.png.72dd0a4c51e7834ed80617825747c4d7.png

  • All of the auto-generated Request URLs are identical (apart from API Key)
  • 4.8 returns all counts (3,1,2,4) as expected and matches the Emby UI counts.
  • 4.9 returns all counts (6,6,6,6) incorrectly and does not match the Emby UI.

Is there anything obvious I am missing and could test for? If the ArtistsService API is not fully working as it was previously, then can it be fixed please? Or if not, is there another (easy) way to obtain the counts from another Service? Thank you.

Posted

How do your query urls differ from the web app?

Posted

Apart from the yellow, I don't think there is anything else I need and both seem the same???

image.thumb.png.22f30868a9558caa18b4a82225aa2c86.png

Has something changed between 4.8 and 4.9?

Posted

Well those two queries have different parent ids.

Posted (edited)

They have different parent Ids because they are different versions of Emby Server, as shown with my  4.8 and 4.9 headings, and as already explained in the previous post to that one. These are both web app queries and both of these return the same correct counts into the Emby UI as detailed in the table in the previous post above.

The discrepancy is what the Swagger/REST API directly returns for 4.9 (6,6,6,6 instead of 3,1,2,4). It appears to be a combined unique count total instead of individual counts. As best as I can determine, and from the details I have posted, both of my queries in both Server versions are the same and match what the web app shows for ArtistType for the Composer example above.

I have also now verified this same count discrepancy, and what it comprises of, with my main music library in 4.9, which is much larger.

Has something changed in 4.9 that causes these ArtistType counts to be now filtered client-side instead of server-side. (Sorry if my terminology is not 100% correct.) Or perhaps something else??? Do you want more info or is what I have provided enough for you to investigate further? Is there a new query I should now be using instead? Thanks.

Edited by user24
Posted

Are they different server machines? Or why can't they use the same parent id? Or why can't you just use the same query that the web app uses?

I want to help but first we have to get to the point where the query urls are the same for both versions. Until then it seems like an apples to oranges comparison.

Quote

Has something changed in 4.9 that causes these ArtistType counts to be now filtered client-side instead of server-side.

No.

Posted (edited)

Ok. I’ve been doing some more testing and will try to reset (like-for-like) and explain again...

Using the same Windows 11 machine, new portable installations (again) of 4.8.11.0 and 4.9.1.80. These are separate and independent test servers only. Nothing to do with my main server/music library and nothing to do with any custom created js/html/css scripts. 

Both test servers have only 1 new music library pointing to the same test Folder containing only one test Album (comprising: AlbumArtists 1, Artists 2, Composers 4). All imported FLAC metadata, initially set up in Mp3tag. One Artist and one Composer are purposely the same entity, therefore there are 6 total unique MusicArtist entities. (The parentID is now 3 for both new test libraries on both new test servers.)

The Emby UI for both test servers shows the correct item counts as follows:

  • AlbumArtists: 1
  • Artists: 3 (this is actually a total of AlbumArtists + Artists, as per how the UI functions)
  • Composers: 4

The next examples use fully automatic direct simple test queries, with no additional filtering parameters selected at all. Just clicking through the default API options as follows:

Manage Emby Server>API>ArtistsService>/Artists>Try It Out>Execute

4.8 Server query (correct results, matching Emby UI)

  • API: http://localhost:8096/emby/Artists?api_key=
  • TotalRecordCount: 3
  • Console: http://localhost:8096/emby/Artists?api_key=
  • TotalRecordCount: 3

4.9 Server query (incorrect results, matching total unique MusicArtists)

  • API: http://localhost:8096/emby/Artists?api_key=
  • TotalRecordCount: 6
  • Console: http://localhost:8096/emby/Artists?api_key=
  • TotalRecordCount: 6

Manage Emby Server>API>ArtistsService>/Artists/AlbumArtists>Try It Out>Execute

4.8 Server query (correct results, matching Emby UI)

  • API: http://localhost:8096/emby/Artists/AlbumArtists?api_key=
  • TotalRecordCount: 1
  • Console: http://localhost:8096/emby/Artists/AlbumArtists?api_key=
  • TotalRecordCount: 1

4.9 Server query (incorrect results, matching total unique MusicArtists)

  • API: http://localhost:8096/emby/Artists/AlbumArtists?api_key=
  • TotalRecordCount: 6
  • Console: http://localhost:8096/emby/Artists/AlbumArtists?api_key=
  • TotalRecordCount: 6

With everything now being equal (I think?), 4.9 still does not return the same correct counts as 4.8. I’m not sure of how/what else to test, to isolate the problem further?

Perhaps this is enough for you to replicate with a similar basic test and figure out what is happening? Am I missing something fundamental as to how the API works? I’m fine with using any queries that will work for 4.9 – just let me know what to try!!!

If you can’t replicate this at all, or it is difficult to fix/low priority, then I may be able to figure out another way of calculating the counts???

Either way – thanks for the support and trying to help!

Edited by user24
Sorry: just to clarify: the console responses above are still the API queries. If I check the console of the Emby UI direct, then i still get much longer URLs, I can provide them if needed.
  • Solution
Posted (edited)

I noticed this discrepancy this evening when calling the Emby API on my server and checking some API responses! Long story short, this endpoint behaves the way it should if you pass in userId=… as a query parameter.

* On my server, I have 843 album artists, but 3,255 regular artists.
* I wanted to get a list of album artists, and I haven't tried this on older versions of Emby server, just v4.9.1.80.

I would expect /Artists/AlbumArtists to just… return album artists, and not all artists. Based on what @user24 is saying, that's the way it used to work in previous Emby server versions, too.

The following cURL gets me all 3,255 artists, which is identical to the response returned from calling /Artists.

curl "https://EMBY_HOST/Artists/AlbumArtists" \
     -H 'Authorization: Emby Client="Client Type", Device="Device Name", DeviceId="DB533F1F-D2A3-44F7-AE9A-2C45E4D4F5A5", Version="0.1.0", Token="TOKEN"'

So given @Luke's advice, I looked at what the web UI (which shows the correct list of album artists) is calling, and compared query parameters, and started making the same request and removing individual query parameters one at a time, and the one that changed the response to show all artists was userId — as soon as I removed it from the query the web UI was making, I started getting all artists. Put that query param back in, and I get the list of album artists. So I modified my API call to add just that parameter, and that did the trick.

curl "https://EMBY_HOST/Artists/AlbumArtists?userId=USER_ID" \
     -H 'Authorization: Emby Client="Client Type", Device="Device Name", DeviceId="DB533F1F-D2A3-44F7-AE9A-2C45E4D4F5A5", Version="0.1.0", Token="TOKEN"'

Success! That returns the 843 items I'm looking for.

Edited by bkreeger
Clarified my wording
  • Like 1
Posted
4 hours ago, bkreeger said:

Long story short, this endpoint behaves the way it should if you pass in userId=… as a query parameter.

Thank you!!! This is very helpful. I haven’t tried every relevant ArtistsService query permutation yet but adding “UserId=…” is sufficient for me to now get the correct counts for AlbumArtist, Artist and Composer in 4.9, and easy to implement.

Perhaps Emby can answer if this is a new permanent requirement for 4.9 ArtistsService? It doesn’t seem to be necessary for 4.9 ItemsService /Items. Thanks!

  • Like 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...