[implemented] Add includeGuids URL parameter to return external Guids

+1 for Ombi, Overseerr, Tautulli and all the other must-have 3rd party tools for Plex :slight_smile:

+1 from me

Absolutely need this +1

yes please! +1

it has my vote

+1 from me

Just curious what you need all the external guids at once for? Are you just trying to save on future calls?

You can request metadata for more than 1 item at a time, just use comas to separate the ids in the request.

Just curious what you need all the external guids at once for? Are you just trying to save on future calls?

(Not for myself or my applications)

Short answer: To create a map of externalGuid: ratingKey. This allows applications to map media from external databases (i.e. IMDB, TMDB, TVDB) to media in Plex.

Example: Do you know if IMDB tt0111161 is in your Plex library? Currently, the only way to answer that question through the API is if you retrieve the external guids for the entire library to see if any of them match to the IMDB ID. You could search Plex by title/year instead of external guid, but that is not accurate enough where different movies could have the same title/year.

To improve performance, I have suggested that applications create the map once and cache the guids, but eventually the cache will need to be updated as rating keys change (adding/removing media) and those API calls will need to be made again.

You can request metadata for more than 1 item at a time, just use comas to separate the ids in the request.

The performance of /library/metadata/<commaSeparatedRatingKeys> is very poor. I don’t expect it to be designed or optimized to retrieve a massive amounts of comma separated values. This is probably because it also returns a lot of useful, but unnecessary, data for this use case (e.g. complete tag data, complete cast list, all video/audio/subtitle stream data, etc.). Not to mention you need to make one API call to /library/sections/<librarySectionID>/all in the first place get all the rating keys in the first place so you can concatenate them. So why not have the guids available in the first API call?


I tested the performance on my own library of about 2000 items (e.g. 2000 comma separated rating keys). Also, pagination using X-Plex-Container-Start and X-Plex-Container-Size is not functional using /library/metadata/<commaSeparatedRatingKeys>, but that can be accomplished by batching the rating keys. I tested with pagination/batches of 50 items which is still 40 API calls for 2000 items when it could be one API call with this feature request. Pagination shows no performance improvement. I also tested with 2000 individual API calls for comparison.

API call Time to retrieve all items
/library/sections/<librarySectionID>/all 6.83 seconds
/library/metadata/<commaSeparatedRatingKeys> 46.23 seconds
/library/sections/<librarySectionID>/all with pagination 6.84 seconds
/library/metadata/<commaSeparatedRatingKeys> with batched rating keys 46.12 seconds
/library/metadata/<ratingKey> individually 50.08 seconds

Notes:

  • No include parameters were used for testing. Some exclude parameters could be used to improve performance.
  • Performance of /library/sections/<librarySectionID>/all is expected to decrease slightly if includeGuids is implemented and added to the API call, but not to the same magnitude as /library/metadata/<commaSeparatedRatingKeys>.
  • Performance will decrease significantly with even larger libraries with more comma separated rating keys.

Here is the source code for my script used for testing. It is using the Python PlexAPI library.

(obviously this would be a completely different request)

I wonder if search-by-external-Guid would be another useful addition.

OP’s feature suggestion would speed up retrieving the entire list. But retrieving the entire list is also wasteful when maintaining a cache isn’t the goal.

For many apps the ability to search by external Guid would be awesome too. It might sometimes avoid the requirement to maintain a cache.

Lol, that’s what I also said like 20 minutes ago elsewhere.

image

Edit: Why not both? Improve performance for retrieving the entire list, and apps maintain their own cache. It’s a win-win situation. :slightly_smiling_face:

I’ll vote for it!

I usually just scrounge directly in the database myself, but that’s hardly something one should admit in gentle company.

Voted :slightly_smiling_face:

Please do it

I get that, but what would that be used for?

Just thinking out load, but what if instead of trying to search for that TTxxxx ID, convert it to the Plex guid and search for that. I think there is a way to do that.

I get that, but what would that be used for?

To know if a movie is in your Plex library
? Isn’t that what I said? tt0111161 maps to rating key 25754 so I can just retrieve /library/metadata/25754 (until the rating key changes for various reasons and the map needs to be updated). Basically, I want the rating key. With the rating key, I can do whatever I want with the API.

Just thinking out load, but what if instead of trying to search for that TTxxxx ID, convert it to the Plex guid and search for that. I think there is a way to do that.

Sure, do you know how the Plex guid hash is generated? My thought is this might be something proprietary that Plex might not be willing to share.

If I know tt0111161 maps to Plex guid plex://movie/5d7768248a7581001f12bc77, but I still need the rating key 25754 to retrieve /library/metadata/25754.

I do know you can filter by guid through the API (/library/sections/<librarySectionID>/all?guid=plex://movie/5d7768248a7581001f12bc77). A filter is not necessarily the same as accessing the metadata directly by rating key. I don’t know how the filters are applied in the server code, but my assumption is that it’s slightly less efficient than directly with the rating key. I can do speed tests to compare it if you want.

Add this, please !!

It’s upsetting to see the Plex devs somewhat reluctant to add a feature that can only help people and doesn’t already exist. I could understand the caution if this was a modification request to a feature that already exists, but this is simply something that will be used by those who need it and can be ignored by those who don’t, so what’s the hold up here?

Edit: See my below response. I read the situation wrong.

Hey, that attitude isn’t necessary here. There is nothing upsetting or hint of reluctance. It’s only been a week and we are still discussing options.

I’ll bet $1 this isn’t possible externally, and that they’re generated as randomGuid() within the Plex meta DB cloud.

Not reluctant, also not a dev, just the go between. Trying to understand the need for this so I can explain it better to the devs.

To be clear, this is not an “easy” change.

Nope. Some sort of internal system.

Are you able to run SQL commands against the database? Just found that the external IDs are stored there so you can do a quick SQL command to check if it’s there and to get the rating key.