Repository navigation
chore: Update docker.io/linuxserver/jellyfin Docker tag to v10.11.10 - #76
Merged
Merged
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
ivan-pinatti
added a commit
that referenced
this pull request
Aug 19, 2026
`ensure_jellyfin_connection` was called with `|| true` in `wire_arr_app`, so a failure left an arr app without its Jellyfin connection while `make wire_connections` still reported success. The Prowlarr path in the same file already collects failures into `PROWLARR_FAILED` for exactly this reason; the Jellyfin path now does the same. `wire_arr_app` returns whether its own Jellyfin connection actually succeeded, and the dispatch loop collects the arr apps that missed it into a new `JELLYFIN_FAILED` array, reported once every job has finished. The legitimate skips inside `ensure_jellyfin_connection` (Jellyfin disabled, no API key yet, connection already there, app doesn't support it) still return 0 on purpose and are not reported as failures. Pulling the actual logs from both CI runs that hit test_jellyfin_connection_matches_what_the_app_supports[lidarr] (GitHub Actions runs 32176749677 on #72 and 32179005406 on #77, both shortly after the Jellyfin 10.11.10 bump merged unattended in #76) shows the same failure both times: lidarr gets through its WebUI login and both download clients, then jellyfin_host_for logs "WARNING: Jellyfin is running but not reachable from this container" and gives up. That function tried each candidate host once, with a 5 second cap each, unlike almost every other first boot readiness check in this file, which retries for up to 180s. It is now wrapped in this file's own retry helper the same way, up to 120s, following detect_jellyfin_base_url's existing pattern of setting a variable as a side effect since retry() only checks exit status, not output. docs/TODO.md is rewritten rather than closed: the fix has not yet been checked against a real run, since marking this pull request ready and commenting /run-tests is left to a person.
ivan-pinatti
added a commit
that referenced
this pull request
Aug 20, 2026
….2's login response (#91) * Record that a rate limited review reports green Three pull requests merged with no review on 2026-08-19. CodeRabbit reports through the legacy commit status API, which offers only error, failure, pending and success, so an exhausted quota resolves to success with the description "Review rate limited". Nothing reading the status can tell that apart from success with "Review completed". #86, #87 and #88 all ended there with no "Review completed" in their status histories, while #82, #85 and #90 have one. Also drops the "3/hour" quota figure from the bullet above it, which the review on #90 contradicts with "up to 10 included reviews per hour; 5 remain", and points that bullet at the new item rather than restating the same observation twice. * Report missed Jellyfin connections, and retry the probe that races it `ensure_jellyfin_connection` was called with `|| true` in `wire_arr_app`, so a failure left an arr app without its Jellyfin connection while `make wire_connections` still reported success. The Prowlarr path in the same file already collects failures into `PROWLARR_FAILED` for exactly this reason; the Jellyfin path now does the same. `wire_arr_app` returns whether its own Jellyfin connection actually succeeded, and the dispatch loop collects the arr apps that missed it into a new `JELLYFIN_FAILED` array, reported once every job has finished. The legitimate skips inside `ensure_jellyfin_connection` (Jellyfin disabled, no API key yet, connection already there, app doesn't support it) still return 0 on purpose and are not reported as failures. Pulling the actual logs from both CI runs that hit test_jellyfin_connection_matches_what_the_app_supports[lidarr] (GitHub Actions runs 32176749677 on #72 and 32179005406 on #77, both shortly after the Jellyfin 10.11.10 bump merged unattended in #76) shows the same failure both times: lidarr gets through its WebUI login and both download clients, then jellyfin_host_for logs "WARNING: Jellyfin is running but not reachable from this container" and gives up. That function tried each candidate host once, with a 5 second cap each, unlike almost every other first boot readiness check in this file, which retries for up to 180s. It is now wrapped in this file's own retry helper the same way, up to 120s, following detect_jellyfin_base_url's existing pattern of setting a variable as a side effect since retry() only checks exit status, not output. docs/TODO.md is rewritten rather than closed: the fix has not yet been checked against a real run, since marking this pull request ready and commenting /run-tests is left to a person. * Accept qBittorrent 5.2.2's login response, not just 5.1.4's test_qbittorrent_api_login and test_qbittorrent_web_session_login asserted status_code == 200 and a body of "Ok.", which is what qBittorrent 5.1.4 answers. 5.2.2 answers a successful login with 204 and an empty body instead, so both assertions failed and PR #83 was correctly red, but that left open whether authentication still worked at all under 5.2.2. Checked directly rather than guessing: ran standalone qBittorrent containers of both 5.1.4 and 5.2.2 with podman, using the same image reference PR #83 proposes, and posted to /api/v2/auth/login from inside each container's own network namespace, bypassing nginx entirely. Both versions set a real session cookie and both let that cookie through to an authenticated GET /api/v2/app/version afterward, so login still works under 5.2.2. Two things changed: the status (200 to 204, empty body) and the cookie's own name, from a bare "SID" on 5.1.4 to a port suffixed "QBT_SID_<port>" on 5.2.2, confirmed by running the WebUI on a non-default port and watching the cookie name track it. test_auth.py now accepts any 2xx status and requires a cookie whose name contains "SID" with a real value, dropping only the exact 200 and the "Ok." body that upstream is free to change. The status check stays, since a cookie check alone would let an error response that happened to set a cookie pass. This passes against both versions, confirmed with the same two probe containers. scripts/rotate-passwords.sh's qbittorrent_api_ok had the same literal "200" check, used to confirm a rotated password logs in; it now accepts any 2xx for the same reason. Grepped the rest of tests/ and scripts/ for other places asserting on the qBittorrent login status or its body; nothing else does, so nothing else needed changing. Removed the probe containers and the digest only image pulled for this afterward, verified with podman ps -a. docs/TODO.md's qBittorrent item is resolved and removed. * Stop a failed download client wiring reporting as Jellyfin's wire_arr_app returned its Jellyfin status directly, and the dispatch loop read any non-zero job status as a missing Jellyfin connection. The three calls before it (ensure_arr_host_prereqs, ensure_qbittorrent_client, ensure_sabnzbd_client) are unguarded, so under set -e any one of them failing kills the job before the Jellyfin call is reached, and the summary would then name that app under Jellyfin and tell the reader to re-run once Jellyfin is up, which would not fix it. The Jellyfin case now returns a dedicated status, so the loop can tell the two apart, and a job that died earlier is collected in ARR_JOB_FAILED and reported as what it is. Claude-Session: https://claude.ai/code/session_01X8GXVNcBeFbVPQtLSbCUGH * Address the review, and fix the port Jellyfin's own setup dialled Three findings from the review, all real: qbittorrent_api_ok accepted any 2xx without looking at the session cookie. Confirmed live against 5.1.4: a refused login also answers 200, with the body "Fails." and no cookie, so a status-only check passed a password qBittorrent had just rejected. The old exact-200 check had the same hole. Require the cookie, whose name is SID on 5.1.4 and QBT_SID_<port> on 5.2.2. rotate_qbittorrent's own login and setPreferences calls ignored their status entirely, so the rotation could rewrite every consumer's credential after qBittorrent refused it; both are checked now and abort instead. ensure_jellyfin_connection waited up to 120s for reachability before asking whether the app supports a MediaBrowser connection at all. Readarr does not, so an unreachable Jellyfin made it sit through the wait and then get reported as having missed a connection it was never going to make. The capability question is answered first now. Its two API reads were unguarded. The function is called in an || list, which suspends set -e inside it, so a failed read carried on with an empty value and returned a confident looking skip, the exact silent success this branch exists to remove. Both are checked. Separately, detect_jellyfin_base_url dialled JELLYFIN_HTTP_PORT from inside the jellyfin container, but the compose file publishes the service as ${JELLYFIN_HTTP_PORT}:8096, so that variable is the host side and the server listens on 8096. They coincide at the default and the bug stays invisible; with a remapped published port it dialled a port nothing listens on, so first-run setup burned the 180s retry and was skipped on every start. Confirmed live: it now completes the wizard and creates the API key. Claude-Session: https://claude.ai/code/session_01X8GXVNcBeFbVPQtLSbCUGH * Encode the stored qBittorrent password on the rotation login This password is read back from Sonarr's database, so it is whatever a person once typed rather than a generated value. A raw -d body let an `&` split it into extra parameters, a `+` arrive as a space, and a literal `%26` decode to `&`, each of which sends a password that is not the stored one and fails the login for a reason nothing in the output explains. The validation request is left alone deliberately: it only ever sees a generated password from a restricted character set. Claude-Session: https://claude.ai/code/session_01X8GXVNcBeFbVPQtLSbCUGH
3 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
10.10.3→10.11.1010.11.11Warning
Some dependencies could not be looked up. Check the warning logs for more information.
Configuration
📅 Schedule: (in timezone America/Toronto)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.