What happened?
Every updater fills its search list like this:
int attempts = 100;
while (attempts > 0 && resources.size() < searchAmount) {
attempts--;
WeightedMovie m = random.selectOne();
...attempts-- runs on every iteration, including the ones that succeed. So a successful selection costs an attempt exactly like a filtered-out one does, and resources.size() can never exceed 100 no matter what SEARCH_AMOUNT says.
Observed on a live Whisparr instance configured with WHISPARR_0_SEARCH_AMOUNT=280:
SEARCH_AMOUNT: 280
selected: 100
skipped: 0
Nothing was filtered - it simply ran out of attempts at exactly 100. The log line still says Updating up to 280 items for WHISPARR_0, and nothing afterwards indicates it stopped at 100.
The filtering case makes it worse rather than causing it. On a Radarr instance with SEARCH_AMOUNT=20 and most of the library unmonitored, 53 candidates were skipped and 20 selected - 73 attempts to fill 20 slots. That one still completed, but at roughly an 80% skip rate even a SEARCH_AMOUNT of 20 would start coming up short.
All five updaters:
What did you expect to happen?
SEARCH_AMOUNT=280 searches 280 items, or the log says why it couldn't.
Steps to reproduce
Set any SEARCH_AMOUNT above 100 on an instance with more than 100 eligible items. Count the "Updating ..." lines - it stops at 100.
Shape of the fix
The cap is there to stop the loop spinning forever when everything is filtered out, which is a real thing to guard against - it just shouldn't be counting successes. Only decrementing on a skip fixes the ceiling while keeping the guard, though it needs the budget to scale with searchAmount rather than being a flat 100, or a large SEARCH_AMOUNT on a heavily-filtered library hits the same wall for the original reason.
Either way a log line when the loop exits on attempts rather than on a full list turns the silent shortfall into something a user can see.
What happened?
Every updater fills its search list like this:
attempts--runs on every iteration, including the ones that succeed. So a successful selection costs an attempt exactly like a filtered-out one does, andresources.size()can never exceed 100 no matter whatSEARCH_AMOUNTsays.Observed on a live Whisparr instance configured with
WHISPARR_0_SEARCH_AMOUNT=280:Nothing was filtered - it simply ran out of attempts at exactly 100. The log line still says
Updating up to 280 items for WHISPARR_0, and nothing afterwards indicates it stopped at 100.The filtering case makes it worse rather than causing it. On a Radarr instance with
SEARCH_AMOUNT=20and most of the library unmonitored, 53 candidates were skipped and 20 selected - 73 attempts to fill 20 slots. That one still completed, but at roughly an 80% skip rate even aSEARCH_AMOUNTof 20 would start coming up short.All five updaters:
App/src/main/java/me/egg82/fetcharr/api/model/update/radarr/RadarrUpdater.java:70App/src/main/java/me/egg82/fetcharr/api/model/update/sonarr/SonarrUpdater.java:74App/src/main/java/me/egg82/fetcharr/api/model/update/lidarr/LidarrUpdater.java:71App/src/main/java/me/egg82/fetcharr/api/model/update/readarr/ReadarrUpdater.java:77App/src/main/java/me/egg82/fetcharr/api/model/update/whisparr/WhisparrUpdater.java:70What did you expect to happen?
SEARCH_AMOUNT=280searches 280 items, or the log says why it couldn't.Steps to reproduce
Set any
SEARCH_AMOUNTabove 100 on an instance with more than 100 eligible items. Count the "Updating ..." lines - it stops at 100.Shape of the fix
The cap is there to stop the loop spinning forever when everything is filtered out, which is a real thing to guard against - it just shouldn't be counting successes. Only decrementing on a skip fixes the ceiling while keeping the guard, though it needs the budget to scale with
searchAmountrather than being a flat 100, or a largeSEARCH_AMOUNTon a heavily-filtered library hits the same wall for the original reason.Either way a log line when the loop exits on attempts rather than on a full list turns the silent shortfall into something a user can see.