Okay, I understand. So the tmdb-season-4020-1 was created by the matching of the Provider, which is then obviously used for future requests. That makes sense.
Thanks for the clarifications.
Some examples of the media i deal with
- /variety_shows/Tokyo PC Club/Season 2025
-- '251024 Tokyo PC Club ep141 - title [1080p] [TVer-epazv886fi-].mkv'
-- '251031 Tokyo PC Club ep142 - title [1080p] [TVer-ep4agwe23h].mkv'
-- '251107 Tokyo PC Club ep143 - title [1080p] [TVer-eprp8osb5b].mkv'
-- '251114 Tokyo PC Club ep144 - title [1080p] [TVer-epdlo6727o].mkv'
- /variety_shows/Task have Fun Diary/Season 2025
-- 'Task have Fun Diary - Task 97 20250718.mkv'
-- 'Task have Fun Diary - Task 98 20250725.mkv'
-- 'Task have Fun Diary - Task 99 20250801.mkv'
- /variety_shows/Gaki no Tsukai/Season 2019/
-- 'Gaki no Tsukai - 2019-01-27 - (#1440) New Year's Party.mkv'
- /youtube/Nogizaka Official Channel [UCfvohDfHt1v5N8l3BzPRsWQ]/Season 2025
-- '20251205 long title1 [youtube-lQLNFhb-Jgs].mkv'
-- '20251205 long title2 [youtube-8vUuD_YoQ3E].mkv'
any many more.
I have a couple of further questions:
How long are the request timeouts? Since the server is making a request to an API, I would assume that there is some sort of timeout when a request is forcefully cancelled if the response is taking too long to arrive. I couldnât find anything in that regard in the documentation. There doesnât seem to be a general default; it could be 10, 30, or 60 seconds. How long would that be for the Provider request?
For a bit of background, my current Metadata Agent requests the metadata from an API, which has rate limitations. However, to get all of the information, I already need to hit up quite a few individual API endpoints. Furthermore, I never really provided the synopsis of episodes because that information would only be available when I make a request for each individual episode. As you would imagine, the number of requests would stack up easily for that, and I quickly ran into the rate limitations.
While I probably will have to implement some form of request queue and cache the metadata source API responses, I was wondering how much time Plex gives the Provider to respond, instead of just saying" well, one minute is up and I got nothing" and cancelling the metadata update.
From what I can see in the example project, the incoming requests are split into separate requests to the provider: Show metadata, extras, images, and for each individual season. So, I wouldnât necessarily need to provide ALL of the metadata right in the first request and could simply wait for the season request to be made. In turn, this wouldnât mean that the show itself wouldnât get updated with metadata if the requesting of episode metadata took too long to respond. Which is good.
What sort of caching does the Plex server do? I tried to find where the /images endpoint is being triggered and found that this is an âon the flyâ request when you edit the show and click on poster or background, but this also doesnât seem to be hit every time because now, 12 minutes later, there is still no new response being logged in the example project even though I clicked on all of the 4 image tabs. This tells me that Plex is doing some caching or reducing the number of requests made to the providers, which is generally a good thing, but this could be confusing if this isnât mentioned somewhere; you might need to hit that up more frequently while developing that endpoint. But this doesnât seem to apply to the other endpoints so it looks like it is specific or unique for the images?!
Last question: With how metadata providers are now structured, acting as an API instead of a local plugin, local file access would now also be impossible, right? What my current metadata Agent does is that it reads a âmatchingâ file (similar to the plexmatch file) in the show/movie folder so that you can match the library item without having to add an ID to the folder title. This worked well because the old agents had access to the files through Plex. However, since this is now a separate application that could not even run on the same system, this wouldnât really work anymore, since I wouldnât be able to guarantee that the system has access to the file.
How would that need to work, or what would need to change on my side in the future? Especially if we consider the fact that 3rd party scanners will not be available in the future. Plex already can match by ID, but I donât think that this is that âopenâ right now that we could simply add whatever source to it (so instead of {tmdb-10283} we have something like {mal-12345} that is then passed to the metadata Provider for matching.
Or maybe the plexmatch file with guid in [source]://[id] format?
1 Like
Thatâs indeed a very important question. I plan to use a metadata source that takes âagesâ to provide the metadata - since multiple requests need to be done by my metadata provider before I can offer a response to the requesting PMS.
Well, since the location of the agent could be the PMS itself, you could definitely have access to local files for existing entries to the library, but I am not sure how to get the path in case of a new media - but to roll this out for users, such a system would need to match the available library pathes to real world pathes in order to make educational guesses on SMB mapping in case itâs not on localhost. Complex and full of pitfalls.
Local file access should definitely be something that the pms itself would need to provide for the metadata provider (for txt nfo or similar files in the same folder). Or those matching files need to find their way into a database that the metadata provider has access to.
A wide field of interesting questions. Thank you for asking them.
Our current timeout on these requests looks to be 90 seconds, we could make this configurable - how long are you expecting to wait? Taking so long will make refreshes painfully slow.
Good question. We donât generally do any caching for the provider calls in PMS, except in the instance of the images endpoint where we just donât make another call for image if one was made less than an hour ago (this will be reset if you refresh the metadata for the item). This was just a measure to reduce API load.
In a sense yes, thatâs no longer possible. However it wouldnât be impossible if your provider was running locally and had access to the same files then you could in theory match them up if you wanted to.
Iâm open to coming up with solutions for this, we already pass hints in the match requests with one of those being the filename so if the information is in the actual file then youâre already set. If itâs in some other place then Iâm open to finding ways to accomodate this.
Thanks for the great questions, Iâd really love to start making a list of community suggestions for changes and improvements so we can start prioritizing them.
That is the problem, I canât really say. My MyAnimelist Metadata Agent will hit up an API that has a rate limit of 60/minute. But I would need to do one request for searching, one for the general information, one for the pictures, one for episodes (and that just for one page of 100) and one for characters and then for each of those characters one as well. So this would be 5 already without each individual character/staff/VA etc. If I now wanted to get the episode synopsis as well, I would have to trigger each episode. This wouldnât be that bad for Anime with 12 episodes (but even that could be more than 30 requests with all of the staff), but shows that have hundreds or even One Piece with over 1100 episodes at the moment. This will take a while with 1 request every second. So yeah, I will need a request queue and cache the requests so that the season request to the Provider will simply timeout unless that metadata was already cached.
That isnât much of a problem that Plex will timeout; it just is something that would be nice to have somewhere in the developer documentation.
Okay, good to know that the refresh resets that.
That is too bad, but also unavoidable, going the âseparate applicationâ kind of way.
However, this raises a question. In the fireside chats, it was stated that you are looking into bringing NFO support to the Plex Metadata Agents. Are you considering them as part of the Plex Series/Plex Movie Agents or rather as something more standalone?
I ask this because someone might only want to rely on local metadata through the created NFO files and not have to use the Plex Agents that might request some data from an online source. With the new Metadata Agents settings and being able to order and prioritise the metadata sources through the Agents, I think it would make sense to have it as a separate Agent to specifically only allow or prioritise NFO metadata. If a user now wants to only provide some metadata through an NFO file and fill the rest up from the Plex sources, they would only need to order them that way in the Agents Configuration.
I will have to play around with this a bit more to see what is actually going on there and what is passed to the Provider.
My idea would have been to convert my matching file to the .plexmatch and set the guid for MyAnimeList, which I would then use in the Provider to get the metadata. In the example project, I can already see that there is a request body of the match POST with the GUID for TVDB, so if that can also be provided or come from the .plexmatch file, this would be an acceptable solution.
