Server Version#: 1.41.6.9685
iOS Version#: 2025.11.1 (992)
In the new iOS app, when viewing a single item the app makes a GET /library/metadata/<key>?includeExtras=1&includeOnDeck=1&includeRelated=1&includeReviews=1 request. For a large library this is quite slow. If I intercept the request and exclude the includeRelated=1 parameter, then the view is almost instant. Inspecting the payloads, it looks like includeRelated=1 triggers a hub search, which for libraries with large collections can take 5-10s.
Contrast this to the old app behavior of requesting /library/metadata/<key>?asyncAugmentMetadata=1&checkFiles=1&includeChapters=1&includeConcerts=1&includeExternalMedia=1&includeExternalMetadata=1&includeExtras=1&includeGeolocation=0&includeMarkers=1&includeMeta=1&includeOnDeck=1&includePlexLinks=1&includePopularLeaves=1&includePreferences=0&includeRelated=0&includeRelatedCount=15&includeReviews=1 (notably does not have includeRelated=1) which is very performant, and then does an async fetch for related after the page loads. Splitting out those requests seems like the ideal way to support the related feature while creating a “snappier” app feel.
As a point of positive feedback, the browse behavior for large collections feels much smoother. In the old app, trying to view an item from a collection > 20k movies locks up the app for ~5s (suspect it has to do with re-rendering the list because it doesn’t seem to be issuing any network requests while the app is locked up).
