fix: queue pageSize to get more than 10 downloading items in Servarr

[Mavyre]

Allows to get all processing Series when entire seasons are downloded on Sonarr

Description

When downloading Season packs, Jellyseerr wasn't displaying all the downloading episodes due to Servarr default pageSize set to 10. 1000 should be a safe number to display correctly the processing items while downloading multiple Seasons (or season with >10 episodes) in parallel.

Screenshot (if UI-related)

Not UI related

To-Dos

• Successful build pnpm build
• Translation keys pnpm i18n:extract
• Database migration (if required)

Issues Fixed or Closed

None

[gauthier-th]

Please fix the typing issue

[gauthier-th]

Tests are still failing.
Looks like prettier hasn't been executed: pnpm run format

[gauthier-th]

I've just spoken to Fallenbagel about it, and we think this should be a setting. As he said:

Requesting excessive data from a slow CPU or a system that may experience I/O bottlenecks could cause performance degradation

meaning that it can potentially cause problems if hundreds of downloads are in progress (retrieved from a seedbox, for example).

Could you please refactor this so it's an option in the Radarr/Sonarr settings?

[Mavyre]

I've just spoken to Fallenbagel about it, and we think this should be a setting. As he said:

Requesting excessive data from a slow CPU or a system that may experience I/O bottlenecks could cause performance degradation

meaning that it can potentially cause problems if hundreds of downloads are in progress (retrieved from a seedbox, for example).

Could you please refactor this so it's an option in the Radarr/Sonarr settings?

Sure, but I'd have to check out Jellyseerr code a litttle bit more than just adding easily this option, to get things done properly. I'll need a more few weeks to have time to get into it.

Any help appreciated :)

[gauthier-th]

I've just spoken to Fallenbagel about it, and we think this should be a setting. As he said:

Requesting excessive data from a slow CPU or a system that may experience I/O bottlenecks could cause performance degradation

meaning that it can potentially cause problems if hundreds of downloads are in progress (retrieved from a seedbox, for example).
Could you please refactor this so it's an option in the Radarr/Sonarr settings?

Sure, but I'd have to check out Jellyseerr code a litttle bit more than just adding easily this option, to get things done properly. I'll need a more few weeks to have time to get into it.

Any help appreciated :)

You'd want to add a number in the DVRSetting interface, then you can go in src/components/Settings/RadarrModal.tsx and src/components/Settings/SonarrModal.tsx to add the setting, and then get the pageSize setting from the place getQueue is called and pass it to the function.

[fallenbagel]

@Mavyre are you able to continue with the PR with the changes requested or should I take over?

[Mavyre]

Hey @fallenbagel,

Sorry, life has been busy lately! I'll do it next week-end and keep you posted!

[github-actions]

This pull request has merge conflicts. Please resolve the conflicts so the PR can be successfully reviewed and merged.

[github-actions]

This PR is stale because it has been open 30 days with no activity. Please address the feedback or provide an update to keep it open.

[github-actions]

This PR was closed because it has been stalled for 30 days with no activity. You can reopen it once you address the feedback or provide the requested changes.

[fallenbagel]

Re-opening since this would be a good QOL feature (needs to be updated to let the user configure the limit)

[Mavyre]

Wow it's been a year already... I've got to rework it for the new seerr. I'm putting a reminder to get it done this month

[github-actions]

This PR is stale because it has been open 30 days with no activity. Please address the feedback or provide an update to keep it open.

[github-actions]

This PR was closed because it has been stalled for 30 days with no activity. You can reopen it once you address the feedback or provide the requested changes.

[github-actions]

Hey @Mavyre, thanks for submitting this PR! However, it looks like the PR template hasn't been fully filled out.

Issues found:

• How Has This Been Tested? section is empty.
• Checklist section is missing or has been removed.
• The contribution guidelines checkbox has not been checked.
• The AI disclosure checkbox has not been checked.

---

Please update your PR description to follow the PR template.
Incomplete or missing PR descriptions may indicate insufficient review of the changes, and PRs that do not follow the template may be closed without review.
See our Contributing Guide for more details.

This check will automatically re-run when you edit your PR description.

[constbogdan]

Hello @Mavyre! I want tobuild on the idea you've proposed and offer my help.

I implemented and tested the queue synchronization changes in #3473. I saw the earlier feedback here about making the queue size configurable per Sonarr/Radarr server.

I'd be happy to update my implementation to add downloadQueueSize to the DVR settings, default it to 10, expose it in both server settings, and use it as a bounded maximum while retaining pagination.

My implementation also waits for RefreshMonitoredDownloads to complete and prevents overlapping Download Sync runs.

Would you be open to a new feat: PR implementing this, or would you prefer the work to continue through #1055?

[constbogdan]

Hi @Mavyre 👋, as @fallenbagel suggested I created a separate branch from develop and rebuilt #1055 on top keeping your original commit authorship.
Included the configurable Sonarr/Radarr download queue limit with default 10 + the changes from my previous PR #3473.

Passed all tests (207/207), Eslint and build.

How do we want to include these commits? I can give you the branch to cherry-pick if you want or if you have other preferences let me know!

[constbogdan]

Pushed the completed branch pr-1055-current so you can take a look when you get a chance: compare

[constbogdan]

Hi @Mavyre, any update on this, would be a shame for this to be closed for lack of activity.

@fallenbagel

[Mavyre]

Hi @Mavyre, any update on this, would be a shame for this to be closed for lack of activity.

@fallenbagel

I thought it was fixed through another PR. It totally slipped my mind to redo that. Feel free to open a new PR (and reference this one for traceability), if you already did everything. Thanks for taking the time to do it 😃

[constbogdan]

Thanks @Mavyre. I opened #3535 with the completed implementation, preserving your original commit authorship and referencing #1055 for traceability. It also incorporates the queue-sync fixes from #3473 and the configurable per-server limit requested in the earlier review.

@fallenbagel @gauthier-th