What problem are you trying to solve?
Every updater fetches the entire library to choose a handful of items, then filters client-side - WhisparrUpdater.java:45, SonarrUpdater.java:52, LidarrUpdater.java:49, ReadarrUpdater.java:55.
The list endpoints don't paginate, but the wanted/* endpoints do, and they answer the question fetcharr is actually asking. Measured against real instances:
| Endpoint |
Whisparr |
Sonarr |
Radarr |
/movie or /series |
flat - 31,053 |
flat - 235 |
flat - 410 |
wanted/missing |
paged - 28,842 |
paged - 1,282 eps |
paged - 65 |
wanted/cutoff |
paged - 80 |
paged - 1,158 |
paged - 48 |
Every field WhisparrUpdater reads is present on a real wanted/missing record - id, title, monitored, hasFile, tags, lastSearchTime - 36 keys against the full DTO's 48. Only movieFile is absent, and only the cutoff path uses it. sortKey=lastSearchTime returns 200, so staleness ordering can be delegated to the server.
What would you like Fetcharr to do?
Select candidates from the paged wanted/missing and wanted/cutoff endpoints rather than pulling the full library and filtering client-side.
What that buys: memory bounded by page size rather than library size - the 65 MB cache blob stops existing. Sonarr's episode-per-series N+1 collapses into one paged call returning the missing episodes directly. Whisparr's upgrade candidates go from parsing 31,053 records to reading 80.
What alternatives have you considered, if any?
The selection distribution changes. Weighted-random over the whole library is deliberately not "the N stalest" - paging means either paging a window and randomising within it, or keeping a local index.
wanted/* uses the arr's notion of missing and cutoff, not fetcharr's. MONITORED_ONLY, MISSING_STATUS and USE_CUTOFF are fetcharr's own semantics, and #24, #30 and #31 were all about getting those exactly right - including unmonitored episodes not counting, and cutoff meaning "not met". Delegating to the server makes some of that logic redundant and some of it contradictory. That's a decision about whose definition of "wanted" fetcharr implements.
SKIP_TAGS stays client-side either way, though tags is on the record.
What problem are you trying to solve?
Every updater fetches the entire library to choose a handful of items, then filters client-side -
WhisparrUpdater.java:45,SonarrUpdater.java:52,LidarrUpdater.java:49,ReadarrUpdater.java:55.The list endpoints don't paginate, but the
wanted/*endpoints do, and they answer the question fetcharr is actually asking. Measured against real instances:/movieor/serieswanted/missingwanted/cutoffEvery field
WhisparrUpdaterreads is present on a realwanted/missingrecord -id,title,monitored,hasFile,tags,lastSearchTime- 36 keys against the full DTO's 48. OnlymovieFileis absent, and only the cutoff path uses it.sortKey=lastSearchTimereturns 200, so staleness ordering can be delegated to the server.What would you like Fetcharr to do?
Select candidates from the paged
wanted/missingandwanted/cutoffendpoints rather than pulling the full library and filtering client-side.What that buys: memory bounded by page size rather than library size - the 65 MB cache blob stops existing. Sonarr's episode-per-series N+1 collapses into one paged call returning the missing episodes directly. Whisparr's upgrade candidates go from parsing 31,053 records to reading 80.
What alternatives have you considered, if any?
The selection distribution changes. Weighted-random over the whole library is deliberately not "the N stalest" - paging means either paging a window and randomising within it, or keeping a local index.
wanted/*uses the arr's notion of missing and cutoff, not fetcharr's.MONITORED_ONLY,MISSING_STATUSandUSE_CUTOFFare fetcharr's own semantics, and #24, #30 and #31 were all about getting those exactly right - including unmonitored episodes not counting, and cutoff meaning "not met". Delegating to the server makes some of that logic redundant and some of it contradictory. That's a decision about whose definition of "wanted" fetcharr implements.SKIP_TAGSstays client-side either way, thoughtagsis on the record.