v4.0.0

BREAKING. This is a major release: the admin site becomes private by
default, on a listener of its own, households can be served at any hostname,
household hostnames refuse an untested Jellyfin version until it is confirmed,
and the legacy entry points are removed. An existing install must change its
configuration before it upgrades: follow "Upgrade from 3.9.x or later 3.x"
below, in order. With those changes, existing household addresses such as
https://jelly-<household>.<HOUSEHOLD_DOMAIN> keep working unchanged.
Breaking changes at a glance:

• Admin listener :8788, household listener :8787. The admin site, the
  administrator API, /metrics, /health and the Seerr webhook move to
  ADMIN_HOST:ADMIN_PORT (default 127.0.0.1:8788; the image sets
  ADMIN_HOST=0.0.0.0). HOST:PORT (:8787) serves household addresses
  only and answers any other host with 421. Health checks, the Seerr webhook
  URL and any admin proxy host move to :8788.
• TRUSTED_PROXIES is required with the household gateway on; JellyPass
  does not start without it.
• State file schema 8. A schema 7 file is migrated on the first start, and
  3.x refuses to start on the result: back up the state file first (see
  "Rollback to 3.x").
• Seerr webhook: Authorization: Bearer header only. ?token= and the
  reduced older payload templates are refused with 400; set the header and
  the full template on 3.x before upgrading.
• Untested Jellyfin versions are refused. The version gate's enforcement
  (JELLYFIN_VERSION_ENFORCEMENT) is now 'refuse': on a Jellyfin other than
  12.x or 10.11.x, household hostnames answer 503 until that exact version is
  confirmed (3.10.0 only warned). A confirmation made under 3.10.0 is kept.
• Legacy paths removed: the add-to-library page, webhook query-token
  authentication and reduced webhook templates, direct upgrades from 2.x, and
  the open-ended relay of household paths (household routes now deny by
  default; see Security).

The household app API stays v1 and gains hidden titles (apiVersion 3);
older clients keep working. The iPhone, iPad and Android app ships separately;
its changes are in mobile/CHANGELOG.md.

Removed

• Removed the legacy add-to-library page. Use Get this in the household app.
• Removed webhook query-token authentication. Production impact: earlier docs
  explicitly offered ?token=; installations using it will receive
  400 webhook_query_token_removed_use_authorization_header. Remove the query
  parameter and configure Seerr's authorization header as
  Bearer YOUR_WEBHOOK_TOKEN before upgrading.
• Availability webhooks require the full current Seerr template in docs/server-reference.md
  (event, media, request and requestedBy). Reduced older templates receive
  400 webhook_payload_removed_use_current_seerr_template; replace the template
  in Seerr's webhook UI. Empty Jellyfin IDs still resolve through the Seerr API.
• Upgrade from 2.x via 3.9.x first, with a state backup.
  1.x state (schema v1–v6) files fail startup with that instruction.
  Schema v7 is retained for 3.x;
  2.x also wrote v7 without a release marker, so that provenance cannot be
  detected. Rollback to 2.x is unsupported; use a matching pre-upgrade backup.

Before upgrading, on 3.9.x or later 3.x:

1. In Seerr → Settings → Notifications → Webhook, set Authorization Header to Bearer <WEBHOOK_TOKEN>.
2. Remove ?token=… from the URL.
3. Check the payload has request.requestedBy with jellyfinUserId and username.
4. Press Test and expect 202 ignored (401 means the header is wrong).
5. After upgrading, watch jfa_webhooks_total{result="removed_form"} and the admin dashboard warning.

Refused availability webhooks are not retried; missed titles rely on the request backfill.

Changed (breaking): listeners, household addresses and Jellyfin versions

• Two listeners. The admin site (/admin/, /auth/*), the administrative
  API (/v1/*), /metrics, the Seerr webhook (/webhooks/seerr) and
  /health move to the new admin listener, ADMIN_HOST:ADMIN_PORT
  (default 127.0.0.1:8788; the container image sets ADMIN_HOST=0.0.0.0 and
  the Compose files publish 127.0.0.1:8788). HOST:PORT (default
  0.0.0.0:8787) is now the member listener: household addresses only, and
  it starts only with the household gateway on. On it a Host that is no
  household's gets a fixed 421 {"error":"unknown_host"} on every path
  (WebSocket upgrades are dropped) instead of the admin site: before 4.0.0 any
  host that was not a household's reached the admin site, the API, the webhook
  and health. ADMIN_PORT must differ from PORT while the gateway is on.
• TRUSTED_PROXIES is required with the household gateway on. Startup
  stops with TRUSTED_PROXIES is required when the household gateway is on
  without it. Its meaning is unchanged (whose X-Forwarded-For is believed for
  rate limits); X-Forwarded-Host still never selects a household.
• Health checks must use the admin port: /health is no longer answered on
  PORT. The image's built-in HEALTHCHECK and the Compose files are updated;
  a health check of your own on :8787/health now fails.
• The Seerr webhook URL moves to the admin port, for example
  http://jellypass:8788/webhooks/seerr, and authenticates with the
  Authorization: Bearer <WEBHOOK_TOKEN> header only (see Removed).
  LEGACY_WEBHOOK_ON_MEMBER_PORT=true keeps the old URL on PORT working
  while you change it (it answers POST /webhooks/seerr there for a Host
  that is no household's, never on a household address, with the same Bearer
  check, and logs a warning at startup).
• Untested Jellyfin versions are refused. 3.10.0 only warned: on a
  Jellyfin version outside the supported releases (12.x and 10.11.x, plain
  numeric versions only), household hostnames now answer every request and
  WebSocket with a fixed 503 until an administrator confirms that exact
  version (Allow Jellyfin X in the admin site, or
  JELLYFIN_UNTESTED_VERSION_OK), and also while the version cannot be read.
  The admin listener is never refused. A version confirmed under 3.10.0 is
  kept by the upgrade, so a household already running on a confirmed version
  keeps serving. On a supported version nothing changes.
• State file schema 8. 4.0.0 migrates a schema 7 file on its first start
  (only the version changes, and a stored Jellyfin version confirmation is
  kept; the new householdAddresses map is added when an address is first
  saved, and appHiddenTitles when a member first hides a title). 3.x
  refuses to start on a schema 8 file
  (unsupported state schema version): see Rollback.
• HOUSEHOLD_APP_ENABLED requires the household gateway (on by
  HOUSEHOLD_GATEWAY_ENABLED=true or by HOUSEHOLD_DOMAIN) rather than
  HOUSEHOLD_DOMAIN itself; the startup error names both.
• Legacy addresses match exactly. A legacy generated address is matched
  only without a port (or with :443/:80); before 4.0.0 any port was
  ignored. Map an address with another port explicitly.
• GET /v1/groups gains householdAddresses, and householdUrl is a
  household's mapped canonical address when it has one, else its legacy one.

Security

• Household gateway routes now deny by default: explicit Jellyfin 10.11.11/12.4 OpenAPI templates, legacy client routes and vetted plugin compatibility entries replace open-ended relay. Unknown plugin namespaces return fixed JSON 404 over HTTP and WebSocket; only the session socket can upgrade. Existing refusals and household scope checks remain. Jellyfin Enhanced public-config is preserved byte-identically.
• Additional plugin endpoints require deliberate exact-path HOUSEHOLD_PLUGIN_ROUTES configuration and a privacy audit; see "Deployment self-check and plugin routes" in docs/server-reference.md. Previously unrecognised paths (including inactive TV and removed bridge paths) no longer relay.
• Household hosts read a backslash (\ or %5C) as a slash when refusing paths with empty segments, so /\ and /\evil.example get 404 not_found as // does, instead of 502 Invalid URL. The admin listener refuses a path starting with two slashes or backslashes (//, /\, /\evil.example) with the same 404; it answered 502 Invalid URL or read the rest as a host name. Neither reaches Jellyfin.
• 3.10.0's one-Host check (400 {"error":"invalid_host"}, connection
  closed) and the // / /\ refusal run first on both listeners, before the
  member listener's 421, the version check or any other routing.

Added

• Household address map. Each household (group) can be given a canonical
  HTTPS origin and aliases, any hostname and an optional port (for example
  https://media.example.com and https://films.example.net:8443), with
  GET/PUT/DELETE /v1/groups/{id}/addresses on the admin API (bearer or
  same-origin session, JSON bodies only). Changes take effect at once. Matching
  is exact (case and default ports aside), the same for HTTP and WebSocket
  requests; an address another household or the legacy rule already has is
  refused (409 address_conflict), and a stored map that conflicts stops
  startup. The household app's Play links stay on the address the request came
  in on. The map is kept in the state file and removed with its group. The
  admin UI's Groups tab lists each household's addresses.
• Hidden titles ("Not interested"). A household member can hide a title
  from their own Discover lists, See all, service and studio pages (all three
  tabs), in that household only, and unhide it again; it still appears in
  their search results and on its title page, flagged hidden, and My
  requests, "Get this", playback and the library are unchanged. Hiding never
  cancels, withdraws, holds or blocks anything. The household app API gains
  POST and `DELETE /jellypass/app/v1/hidde...

JellyPass app 1.4.0

A minor release: a member can mark a title Not interested to hide it from
their own Discover, with Undo and a new Hidden tab in My requests, and a
tap anywhere on a Home row's heading opens its See all page. It still works
with JellyPass server 3.2.0 or later (app API v1), as 1.0.0 to 1.3.0 do.
Not interested (hiding titles) needs JellyPass server 4.0.0 or later
(apiVersion 3 in GET /jellypass/app/v1/me); on an older server the app
shows none of it, with no error, and everything else works as in 1.3.0. As in
1.1.0, Cancel request and the day each title was requested need JellyPass
server 3.5.0 or later (apiVersion 2). Members update by installing the new
TestFlight build, or the new APK over the old one.

Added

• Not interested. A member can hide a title from their own Discover: from the title page's Not interested
  button, or by pressing and holding any poster or backdrop card (Home's rows and hero, See all, a service's or
  studio's page, Search), which opens a sheet with Not interested and Close. VoiceOver and TalkBack get the same
  as an action on the card. Hiding is one call (POST /hidden/{type}/{id}); the title leaves every list on screen at
  once, with no list read again, the title page stays open and says Unhide, and a toast over the tab bar says
  "Hidden … from Discover" with Undo (one DELETE). The toast goes after eight seconds, but stays while a screen
  reader is on. Hiding is only for that member in that household: it does not cancel requests or take anything out of
  the library, and the other members never see it.
• Search keeps hidden titles, marked Hidden (and "Hidden from Discover" for screen readers), with Unhide
  under the card.
• My requests → Hidden. Requests | Hidden tabs at the top of My requests; Hidden lists the member's hidden titles,
  newest first, each with its poster, title, the day it was hidden and Unhide, named ten at a time like My requests
  (GET /hidden, then GET /movie or /tv per title), with Load more. The filters stay on Requests.
• Every failure has one fixed message, and hiding a 2,001st title says "You've hidden 2,000 titles, the most there can
  be. Unhide some to hide more." Nothing is retried by itself; a 401 signs out.
• What was hidden or unhidden in the app is kept in memory for the session only, never on the device, and forgotten on
  sign-out, a refused sign-in or any change of household or member.

Changed

• The API client knows the server's hidden titles (server 4.0.0, apiVersion 3): it reads each card's and title's
  hidden (false from an earlier server), and can hide, unhide and list the member's hidden titles. Titles a member
  hid with another client are already left out of this app's Discover lists and service pages by the server.
• A See all, service or studio page whose page came back with no titles (every one hidden) still offers Load more.
• Home: the whole row heading opens its See all page. On a list row and on a service row, a tap anywhere on the
  heading line (the title, the service's logo or the space beside them) opens the same page the chevron does, with the
  same filter and New only choice and no extra call. The line is at least 44 pt tall, and a press on the title or on the chevron dims the whole line. Screen
  readers are unchanged: the heading is still a heading, and the one "See all " link is still the chevron.
  Rows without a See all page (Studios) stay plain headings.

v3.10.0

This is a minor release. JellyPass now has a written Jellyfin support policy:
it supports the current Jellyfin release and the one before it, Jellyfin
12.x and 10.11.x, and tests both against a real Jellyfin in CI and before
every release; on any other Jellyfin version, JellyPass warns until an
administrator confirms that exact version, and household hostnames keep
serving as before. Requests that name more or fewer than one host, and
household paths with empty segments, are now refused (see Security), and
every HTML page is marked no-transform so a CDN that honours it adds no
scripts. The state file (schema v7, plus one optional field), the app API
(v1, apiVersion 2), webhook payloads, and every existing setting and
administrator API endpoint are as in 3.9.0. This is a minor release because a
setting, administrator API endpoints and metrics are added; the refusals fall
under the rule at the top of this file. On a supported Jellyfin, nothing needs
doing. Read these before upgrading:

• Check your Jellyfin version first. On Jellyfin 12.x or 10.11.x nothing
  changes and nothing needs configuring. On any other version (an older 10.x,
  a future 13.0 or later, or any build whose version has a suffix: a
  pre-release such as 12.5.0-rc1, build metadata such as 12.4.0+abc, or
  any other non-numeric part), the version is unconfirmed: JellyPass logs
  a warning (once per version), the admin site shows it with Allow
  Jellyfin X, and household hostnames keep serving exactly as in 3.9.0.
  Confirm that exact version in the admin site, or set
  JELLYFIN_UNTESTED_VERSION_OK to it, to clear the warning.
• JellyPass 4.0.0 will refuse household requests on an unconfirmed
  version: household hostnames will answer 503 until that exact version is
  confirmed, and also while the version cannot be read. 3.10.0 only warns,
  because refusing requests that worked in 3.9.0 is not a security or privacy
  fix.
• Upgrading Jellyfin to an untested version later warns again, within
  five minutes, until that version is confirmed in turn. A confirmation
  covers one exact version.
• Jellyfin unreachable when JellyPass starts: JellyPass starts anyway,
  household hostnames serve as before, and the admin site shows that the
  version cannot be read until Jellyfin reports it (read again every 30
  seconds).
• On Jellyfin 12, clients that give their token only the legacy way
  (X-Emby-Token, X-Emby-Authorization, X-MediaBrowser-Token, the Emby
  scheme or api_key) get 401 on household hostnames, as Jellyfin 12 itself
  refuses them. JellyPass checks a client's credentials exactly as given and
  never translates them into a form Jellyfin 12 reads. On 10.11 they work as
  before.
• A reverse proxy that sends one Host is unaffected by the new Host
  checks; only requests that name more or fewer than one host, or a malformed
  one, get 400 invalid_host. See Security.
• Behind a CDN: HTML pages now carry no-transform, so a CDN that honours
  it (Cloudflare, for example) no longer injects its Web Analytics script into
  them, and Web Analytics' automatic setup stops reporting visits to these
  pages. JellyPass compresses the pages itself instead. No CDN purge is needed
  unless your CDN caches HTML pages (Cloudflare does not by default); a cached
  copy keeps any injected script until it expires or is purged.
• The state file keeps schema v7. A confirmation is stored in a new
  optional field, jellyfinVersionConfirmed, which 3.9.0 keeps as it is
  without reading it, so rolling back needs no state change (3.9.0 does not
  check the version at all).
• To roll back, set JELLYPASS_IMAGE back to
  ghcr.io/nicklongmore86/jellypass:3.9.0 and recreate the container. No
  state-file or setting change is needed (JELLYFIN_UNTESTED_VERSION_OK is
  ignored by 3.9.0).
• The iPhone, iPad and Android app ships separately; its changes (mobile
  1.3.0) and its App Store screenshot workflow are described in
  mobile/CHANGELOG.md.

Security

• A request must name exactly one host. Until now, a request with two
  Host headers was answered for the first of them, so a client reaching the
  JellyPass port directly could have it read a different host from a proxy
  that routed on another one: another household's hostname, or the admin
  site, API and webhook. JellyPass now refuses, with a fixed
  400 {"error":"invalid_host"} and the connection closed, before a household
  is chosen or anything is relayed: more or fewer than one Host header, a
  Host that is not a plain host[:port] (userinfo, whitespace, a path or
  other characters, or empty), and an absolute-form request target
  (GET http://host/path) whose authority is not the Host. WebSocket
  upgrades get the same 400, and the connection is closed on JellyPass's
  side even if the client keeps its own side open. A reverse proxy that sets
  one Host (Nginx Proxy Manager's proxy_set_header Host $host, for
  example) is unaffected. An HTTP/1.0 request may still leave Host out: with
  an ordinary path it is answered as no household's, as before; with an
  absolute-form target it is refused.
• Household hosts refuse paths with empty segments. HTTP requests and
  WebSocket upgrades whose raw or once-decoded path contains // receive a
  fixed 404 not_found before any relay. This is precautionary hardening; no
  disclosure was observed against a real Jellyfin.

Added

• Supported Jellyfin versions. JellyPass reads Jellyfin's version from
  /System/Info/Public at startup and every five minutes, and logs a warning,
  once per version, on a version outside the supported releases (12.x and
  10.11.x, with plain numeric versions only; a suffixed build is outside
  them) until an administrator confirms that exact version. Household
  hostnames keep serving on it. See README, "Supported Jellyfin versions".
• Admin site: a banner shows an unconfirmed or unreadable Jellyfin
  version, with Allow Jellyfin X (and Withdraw once allowed); the
  connection status reads "Jellyfin version not confirmed" until it is.
• Administrator API: GET /v1/jellyfin/version (with confirmation:
  not_needed, confirmed or unconfirmed, and enforcement: warn in
  3.x), PUT /v1/jellyfin/version/confirmation ({"version": "..."},
  exactly the version Jellyfin reports now) and
  DELETE /v1/jellyfin/version/confirmation.
• Setting: JELLYFIN_UNTESTED_VERSION_OK, one exact untested version that
  counts as confirmed without confirming it in the admin site.
• Metrics: jfa_jellyfin_version_info{version,supported,confirmed},
  jfa_jellyfin_version_supported and jfa_household_hosts_refusing (always
  0 in 3.x).

Changed

• No CDN adds scripts to JellyPass's pages. Every HTML page JellyPass serves
  or relays (the household app at /jellypass/app/, Jellyfin web under /web/
  with or without the TV add-on, /jellypass/add, any other HTML Jellyfin
  sends on a household hostname, and the admin site) now has no-transform
  added to its Cache-Control (no-store, no-transform, no-cache, no-transform, or no-transform alone where there was none), so a CDN such
  as Cloudflare, whose Web Analytics automatic setup injects a
  static.cloudflareinsights.com script, leaves it alone. Caching is
  unchanged. Because such a CDN also stops compressing these pages, JellyPass
  compresses them itself (br or gzip, as the client accepts, with
  Vary: Accept-Encoding); a page Jellyfin already encoded is passed through
  as it is. A HEAD gets the same headers as the GET. A page JellyPass
  compresses carries Jellyfin's ETag made weak (W/"…"), and still
  revalidates: JellyPass asks Jellyfin with the strong tag, and the 304
  carries the weak one back. A client that accepts no coding of a page at all,
  not even unencoded (Accept-Encoding: *;q=0, for example), gets a 406.
  Scripts, styles, images, JSON, video and HLS are not touched, so the CDN
  keeps compressing them. Nothing to configure.
• CI and the release workflow test every supported Jellyfin release: the
  real-Jellyfin suite runs once against jellyfin/jellyfin:12.4.20261026-211555
  (12.4.0) and once against jellyfin/jellyfin:10.11.11, instead of 10.11.3
  only; no image is published unless both pass. pnpm test:real runs both in
  turn. The images are pinned in scripts/jellyfin-versions.json.
• README: the requirement is now "Jellyfin 12.x (current) or 10.11.x
  (previous)" instead of "Jellyfin 10.11 or newer".
• docs/tv-addon.md: the TV add-on is matched to the supported Jellyfin
  releases.

JellyPass app 1.3.0

A minor release, and the first build sent for App Store review: each list row
on Home gains a See all page, the app takes any HTTPS household
address (not only https://jelly-<household>.<domain>), and Account →
About & credits links to the privacy policy and support pages on
jellypass.app. It still works with JellyPass server 3.2.0 or later (app API
v1), as 1.0.0 to 1.2.1 do; none of these changes needs a server change. See
all uses the list addresses Home already reads (GET /discover/<list>?page=n),
which every supported server answers. As in 1.1.0, Cancel request and the
day each title was requested need JellyPass server 3.5.0 or later
(apiVersion 2 in GET /jellypass/app/v1/me); on an older server the app
shows neither, with no error. Members update by installing the new TestFlight
build, or the new APK over the old one.

Added

• Home: See all on every list row. Trending, Popular movies, Popular series, New movie releases, Upcoming movies
  and Upcoming series (and Trending movies / Trending series under the Movies and TV filters) have the same chevron
  after their heading as the service rows, a link named "See all " (for example "See all Trending"). It opens
  the row's full list as a poster grid on Home's stack, like a service's page: New only (the same choice as Home's),
  the short corner badges, Load more, and Back to Home with the filter as it was. Opened from its row it makes no
  call; Load more asks for one page. It uses the server's existing GET /discover/<list>?page=n, as the TV add-on's
  See all pages (server 3.9.0) do.
• Account → About & credits says the app is an unofficial companion, not affiliated with Jellyfin or Seerr.
• About, Privacy policy and Support links to jellypass.app: Privacy policy
  (https://jellypass.app/privacy/) and Support (https://jellypass.app/support/) in Account → About & credits,
  and What is JellyPass? (https://jellypass.app/) on the address screen. They are set in the app config
  (extra.privacyPolicyUrl, supportUrl, aboutUrl), and a link whose URL is unset or not a plain https URL stays
  hidden. They open in the system browser, are allow-listed, and carry no member data.
• The address screen says what the app is: a companion for a JellyPass household server, whose address comes from
  whoever runs your Jellyfin.
• A production-aab EAS profile that builds an Android App Bundle for Google Play. The APK builds and their
  signing key are unchanged, so the new APK still installs over the old one.

Changed

• Any HTTPS household address works. The app no longer requires https://jelly-<household>.<domain>: it takes
  whatever HTTPS address the household's administrator gives out, such as https://media.example.com or
  https://films.example.net:8443 (a port is kept, :443 is dropped), typed or in a setup link. It still refuses
  http://, IP addresses, .local names, and anything around the address (a name or password, a path, a query or a
  fragment), and says which when a typed address is refused. A name with non-ASCII letters must be entered in its
  xn-- form. A sign-in kept on a jelly- address keeps working. App versions up to
  1.2.1 take only the jelly- form, so a household on any other address needs this version or later.
• Cancelling a request no longer mentions a "download": an approved title "may still be added to the server, but it
  won't be added for your household."
• The app icons are 1024 × 1024 (the App Store's size), the same drawing as before. The Android adaptive icon's
  foreground is scaled to sit inside the launcher's safe zone, so a round or squircle mask no longer clips the ticket.

v3.9.0

This is a minor release for the TV add-on, which is still experimental and off
by default: unless TV_ADDON_ENABLED is set, nothing changes on any host.
Each list row of the Discover page gains a See all page, a full grid of
that list, and in the desktop layout every JellyPass page gains a Back
button. No setting is added, removed or renamed, and the server itself is
unchanged: the state file (schema v7), the app API (v1, apiVersion 2),
webhook payloads, the administrator API, the admin UI, the household app and
the gateway are as in 3.8.1. The pages use only app API calls that already
exist. The add-on's pages are not part of the public interface described at
the top of this file. This is a minor release because the add-on gains pages.
Read these before upgrading:

• Nothing to configure. No setting is new, and nothing in .env needs to
  change. Only households the TV add-on is on for (TV_ADDON_ENABLED and
  TV_ADDON_HOUSEHOLDS) see anything new.
• The state file is unchanged (schema v7, with the same fields as 3.8.1),
  so 3.8.1 reads a state file written by 3.9.0.
• No CDN purge is needed. The add-on's script and stylesheet are named for
  a hash of their content, and both names change in this release. The
  household address's /web/ page that carries the add-on's tag and the
  Samsung app's manifest are sent no-store, so they name the new files at
  once.
• It has been tested in a real Jellyfin 12.3 container, in the TV layout
  and the desktop layout, in a desktop browser. The See all pages have not
  been seen on a physical TV; check them on a TV before relying on them
  (docs/tv-addon.md describes them). The Back button is
  not drawn in the TV layout.
• The Samsung app picks it up by itself. Its loader reads the manifest
  each time it starts, so a Samsung TV with the JellyPass build of the app
  gets the new add-on at its next start. Nothing is reinstalled on the TV.
• To roll back, set JELLYPASS_IMAGE back to
  ghcr.io/nicklongmore86/jellypass:3.8.1 and recreate the container. No
  state-file or setting change is needed. The Discover rows lose their See all
  buttons, a See all page's address says "Not found", and the desktop layout
  has no Back button on JellyPass pages.
• The iPhone, iPad and Android app ships separately; its changes are
  described in mobile/CHANGELOG.md.

Added

• TV add-on: See all on the Discover rows. Trending, Popular movies,
  Popular series, New movie releases, Upcoming movies and Upcoming series (and
  the Trending rows of the Movies and TV chips) have a "See all" button beside
  their heading, named for example "Trending, see all". It opens a full grid
  page at #/jellypass/list/<list> with Load more, "New only" (the shared
  setting, on by default), the short corner badges and Jellyfin-sized cards.
  Opening one from its row costs no call, Load more one call, Back none. The
  calls are written in docs/app-api/fetch-budget.json (tv-discover-list).
• TV add-on: a Back button on JellyPass pages in the desktop layout, where
  Jellyfin 12.3's toolbar has none. It goes back in history, or to Jellyfin's
  Home when there is nothing to go back to. The history it goes back through
  belongs to the session: after a sign-out, another member's sign-in or a new
  token, Back goes to Home. The TV layout is unchanged.

v3.8.1

This is a patch release for the TV add-on, which is still experimental and off
by default: unless TV_ADDON_ENABLED is set, nothing changes on any host.
It renames one toggle and adds nothing. No setting is added, removed or
renamed, and the server itself is unchanged: the state file (schema v7), the
app API (v1, apiVersion 2), webhook payloads, the administrator API, the
admin UI, the household app and the gateway are as in 3.8.0. Only the add-on's
script changes. Read these before upgrading:

• Nothing to configure. No setting is new, and nothing in .env needs to
  change. Only households the TV add-on is on for (TV_ADDON_ENABLED and
  TV_ADDON_HOUSEHOLDS) see anything new.
• The state file is unchanged (schema v7, with the same fields as 3.8.0),
  so 3.8.0 reads a state file written by 3.8.1.
• No CDN purge is needed. The add-on's script and stylesheet are named for
  a hash of their content: the script's name changes in this release and the
  stylesheet, which is unchanged, keeps its name. The household address's
  /web/ page that carries the add-on's tag and the Samsung app's manifest
  are sent no-store, so they name the new script at once.
• The Samsung app picks it up by itself. Its loader reads the manifest
  each time it starts, so a Samsung TV with the JellyPass build of the app
  gets the new add-on at its next start. Nothing is reinstalled on the TV.
• To roll back, set JELLYPASS_IMAGE back to
  ghcr.io/nicklongmore86/jellypass:3.8.0 and recreate the container. No
  state-file or setting change is needed. The toggle is called Hide what I
  have again and otherwise works as in 3.8.1.
• The iPhone, iPad and Android app ships separately; its changes are
  described in mobile/CHANGELOG.md.

Changed

• TV add-on: the "Hide what I have" toggle is now called "New only". The
  Discover page and the service and studio pages show the shorter label, so it
  matches the household app. A screen reader hears the visible words first: "New only:
  show only titles you don't have or haven't requested". What it does, and that
  it is on when a page opens, is unchanged.

v3.8.0

This is a minor release for the TV add-on, which is still experimental and off
by default: unless TV_ADDON_ENABLED is set, nothing changes on any host.
The Discover page's service headings and studio tiles now open a page for
each service and studio, Hide what I have is on when the page opens and
also applies to the hero, and the add-on's cards are the size of Jellyfin
web's own, with a smaller status badge. No setting is added, removed or
renamed, and the server itself is unchanged: the state file (schema v7), the
app API (v1, apiVersion 2), webhook payloads, the administrator API, the
admin UI, the household app and the gateway are as in 3.7.0. The pages use
only app API calls that already exist. The add-on's pages are not part of the
public interface described at the top of this file. This is a minor release
because the add-on gains pages. Read these before upgrading:

• Nothing to configure. No setting is new, and nothing in .env needs to
  change. Only households the TV add-on is on for (TV_ADDON_ENABLED and
  TV_ADDON_HOUSEHOLDS) see anything new.
• The state file is unchanged (schema v7, with the same fields as 3.7.0),
  so 3.7.0 reads a state file written by 3.8.0.
• Hide what I have is now on when the Discover page opens. A member who
  wants to see the titles the household already has or has asked for switches
  it off; the choice lasts until a sign-out or another member's sign-in.
• No CDN purge is needed. The add-on's script and stylesheet are named for
  a hash of their content, and both names change in this release. The
  household address's /web/ page that carries the add-on's tag and the
  Samsung app's manifest are sent no-store, so they name the new files at
  once.
• It has been tested in a real Jellyfin 12.3 container, in the TV layout
  and the desktop layout, in a desktop browser. On real Samsung TVs only
  what 3.7.0 added has been seen: the service and studio pages, Hide what I
  have on by default and the new card sizes have not been seen on a physical
  TV. The card sizes change every add-on row, Home's and Search's included,
  so check Home, Search, the Discover page and a service's and a studio's page
  on a TV before relying on them; docs/tv-addon.md lists
  what to check.
• The Samsung app picks it up by itself. Its loader reads the manifest
  each time it starts, so a Samsung TV with the JellyPass build of the app
  gets the new add-on at its next start. Nothing is reinstalled on the TV.
• To roll back, set JELLYPASS_IMAGE back to
  ghcr.io/nicklongmore86/jellypass:3.7.0 and recreate the container. No
  state-file or setting change is needed. The add-on loses the service and
  studio pages, Hide what I have is off when the page opens, and the cards and
  badges are as in 3.7.0.
• The iPhone, iPad and Android app ships separately. Its 1.2.0 (Hide what
  I have on Home) is described in mobile/CHANGELOG.md. The app is not in the
  image, and 1.2.0 needs nothing from 3.8.0: it works with 3.8.0 as with 3.7.0.

Added

• TV add-on: service and studio pages. A service row's heading on the
  Discover page ("Popular on Netflix ›") is now a link, and each studio's logo
  in the foot is a tile you can choose; either opens that service's or
  studio's own page in Jellyfin web (#/jellypass/service/<id>,
  #/jellypass/studio/<id>), as in the household app. A service's page opens
  on the list its row showed (All on All, Films on Movies, Series on TV). Each
  page has the logo and name; for a service, the All / Series / Films tabs
  (a service whose films the API does not list has its series only, with no
  tabs; a studio's page lists its movies); Hide what I have (the same
  choice as on Discover); a grid of 20 titles with a Load more button that
  asks for the next 20; the JustWatch credit under a service's All and Films;
  and the TMDB notice. Back from a title returns to the same title on the same
  tab with the pages that were showing, without asking again, and a service
  opened from a row it already loaded costs no new call. Only the services and
  studios the app lists have a page: any other address says "Not found". A
  heading stays a heading for a screen reader (the control inside is named
  "Popular on Netflix, see all"). The calls are written in
  docs/app-api/fetch-budget.json (tv-discover-network,
  tv-discover-studio).

Changed

• TV add-on: Hide what I have is on when the Discover page opens, and on
  the service and studio pages, and it now also applies to the hero: with
  it on, the hero's slides skip titles in the library or already requested (a
  title just asked for too) and are filled from the next titles of the same
  answer that have a wide picture; if none is left, the hero is not shown.
  Switch it off and the hero is as in 3.7.0. The choice is kept in memory only,
  for the member signed in, and is back on after a sign-out or for another
  member. It makes no extra call.
• TV add-on: the add-on's cards are the size of Jellyfin web's own in both
  layouts. Every add-on row (Home, Search and the Discover page) and the
  service and studio grids use Jellyfin's card classes and the class its TV
  sizes depend on (itemsContainer-tv) instead of widths of the add-on's own,
  so on a TV a poster is the width of Jellyfin's Latest row (15.6vw, up from
  about 10vw), the Discover page's wide cards are 23.5vw, and the grids are
  Jellyfin's portrait-card grid. Loading cards use the same markup, and the
  sizes follow Jellyfin web if it changes them.
• TV add-on: the Discover page's status badge is a small pill in the
  poster's top right corner, in the style of Jellyfin's own indicators, with
  short words: In library, Requested, Get this or Can't get
  (in 3.7.0, In your library, Requested, Available to get and Can't
  request). The card's accessible name still says the whole sentence, and
  white on each badge colour is above 5:1.

v3.7.0

This is a minor release for the TV add-on, which is still experimental and off
by default: unless TV_ADDON_ENABLED is set, nothing changes on any host.
The add-on gains a Discover page, the household app's Home inside Jellyfin
web, and the compass button in Jellyfin's header that opens it. Everything is
additive. No setting is added, removed or renamed, and the server itself is
unchanged: the state file (schema v7), the app API (v1, apiVersion 2),
webhook payloads, the administrator API, the admin UI, the household app and
the gateway are as in 3.6.1. The page uses only app API calls that already
exist. The add-on's pages are not part of the public interface described at
the top of this file. This is a minor release because the add-on gains a page.
Read these before upgrading:

• Nothing to configure. No setting is new, and nothing in .env needs to
  change. Only households the TV add-on is on for (TV_ADDON_ENABLED and
  TV_ADDON_HOUSEHOLDS) see anything new.
• The state file is unchanged (schema v7, with the same fields as 3.6.1),
  so 3.6.1 reads a state file written by 3.7.0.
• The Discover page is reached only from the compass button that the
  add-on puts in Jellyfin's header, immediately before Search. On Jellyfin web
  12.3 it is drawn in both the TV layout and the desktop layout. Jellyfin web
  10.11 in a desktop browser gets no button (the Samsung app's 10.11 runs the
  TV layout, whose header has it). If a Jellyfin update changes its header so
  that the button cannot be placed, the button does not appear, and there is
  no other way in: no link on Home, no card at the end of a row, no menu
  entry. Only an address typed into a browser opens it then.
• The services' headings and the studios' tiles are not links yet. They
  show what is there; their own pages come in a later release.
• No CDN purge is needed. The add-on's script and stylesheet are named for
  a hash of their content, and both names change in this release. The
  household address's /web/ page that carries the add-on's tag and the
  Samsung app's manifest are sent no-store, so they name the new files at
  once.
• It has been tested in a real Jellyfin 12.3 container, in the TV layout
  and the desktop layout, in a desktop browser, but not on a real TV.
  Check the button, the page, its rows and Back in a desktop browser on that
  household's address, then on a TV, before relying on it;
  docs/tv-addon.md lists what to check. Memory on a
  2019 Samsung is a real-TV check: the page keeps pictures only for the rows
  near the screen, but how much memory such a TV holds for them has not been
  measured. Scroll the whole page down and up a few times, switch chips and
  open and leave a title, and look for a crash, a reload or rows that stay
  blank.
• The Samsung app picks it up by itself. Its loader reads the manifest
  each time it starts, so a Samsung TV with the JellyPass build of the app
  gets the new add-on at its next start. Nothing is reinstalled on the TV.
• To roll back, set JELLYPASS_IMAGE back to
  ghcr.io/nicklongmore86/jellypass:3.6.1 and recreate the container. No
  state-file or setting change is needed. The add-on loses the Discover page
  and its header button, and is otherwise as in 3.7.0.

Added

• TV add-on: the Discover page. On the households the TV add-on is on
  for, Jellyfin web gains a Discover page (#/jellypass/discover, a page
  of Jellyfin web's own under its real header and Back, in the TV and the
  desktop layout, with no key handling of its own), opened from a compass
  button in Jellyfin's header, right before Search (see the upgrade notes
  for where it appears). It is the household app's Home on the TV:

  • a hero of up to five titles (the first row's first titles with a
    wide picture), with ‹, View and › buttons and dots, and no
    auto-advance; View opens the title;
  • the All / Movies / TV chips and a Hide what I have toggle, which
    hides the row titles in the library or already requested (the hero's
    slides are unchanged) and asks for nothing;
  • on All, the Trending, Popular movies, Popular series, New
    movie releases, Upcoming movies and Upcoming series rows and
    the eight Popular on … service rows (Movies and TV show their own
    rows, as the app does), at most 14 titles a row;
  • a badge in words on each title, not only in colour: In your library,
    Requested, Available to get or Can't request;
  • at the foot, the studios (All and Movies), the JustWatch line (All and
    Movies) and the TMDB notice (every chip), reachable by the remote.

  Choosing a title opens the JellyPass title page, and Back returns to the
  same title on the Discover page with no Discover call (within ten minutes
  of opening it; after that the page asks again and focus may land on the
  hero's View). The page asks
  for 5 things when it opens on All and 10 more as the remote scrolls down to
  the rows that need them; a row's pictures are set only while it is near the
  screen, to spare a 2019 Samsung's memory. Its answers are kept in memory
  for ten minutes and forgotten on a sign-out, another member or a new
  sign-in, and an answer that comes back for a session that has ended is
  dropped. A row that fails says why, with Try again (a refused sign-in
  shows Sign in to continue instead, with no Try again); nothing is asked
  again by itself, and after a "too many requests" answer nothing is asked
  until the time the server gave (or 30 seconds) is over. Home's and
  Search's Discover rows are unchanged. The calls the page makes are written
  in docs/app-api/fetch-budget.json (tv-discover).

JellyPass app 1.2.1

A patch release: Home's filter chips and the poster badges are no longer cut
off, and "Hide what I have" is now called "New only". It still works with
JellyPass server 3.2.0 or later (app API v1), as 1.0.0 to 1.2.0 do; none
of these changes needs a server change. As in 1.1.0, Cancel request and the
day each title was requested need JellyPass server 3.5.0 or later
(apiVersion 2 in GET /jellypass/app/v1/me); on an older server the app
shows neither, with no error. Members update by installing the new TestFlight
build, or the new APK over the old one.

Fixed

• Home: the last filter chip is no longer cut off. The chip row scrolls
  sideways with the screen's side padding inside it, so the last chip can be
  scrolled fully into view at any screen width and text size.
• Poster badges are short and never cut off. A badge on a poster says "In
  library", "Requested", "Get this" or "Can't get" (the words the TV add-on
  uses) in a small corner pill, at least 11 pt, instead of wrapping over the
  poster. The badge text follows the system text size like all other text. When
  the app estimates that the pill would not fit on one line inside a poster at
  your text size, it shows the same badge under the picture instead, where it
  can wrap. The full wording stays in each card's accessible name and on title
  pages.

Changed

• "Hide what I have" is now "New only" on Home and on the service and
  studio pages. A screen reader hears the visible words first: "New only: show
  only titles you don't have or haven't requested". It still works the same
  way and is on at every sign-in.

JellyPass app 1.2.0

A minor release: Home can hide what the household already has, and signing in
and out is safer when two of them overlap. It still works with JellyPass
server 3.2.0 or later (app API v1), as 1.0.0 and 1.1.0 do, so it can be
installed before the household's server is upgraded. Hide what I have needs no
server change: it only filters what the app has already loaded, so it works on
any supported server. As in 1.1.0, Cancel request and the day each title was
requested need JellyPass server 3.5.0 or later (apiVersion 2 in
GET /jellypass/app/v1/me); on an older server the app shows neither, with no
error. Members update by installing the new TestFlight build, or the new APK
over the old one.

Added

• Home: Hide what I have. A chip after All | Movies | TV, on by default at
  every sign-in. On, the rows and the hero leave out the titles in your library
  and the ones already requested (including one you just asked for), and the
  hero fills from the next titles; with none left it isn't shown. Turning it on
  or off makes no call to the server. The choice is kept only while you're
  signed in, never stored on the device, and starts on again after a sign-out,
  an expired sign-in or a change of household or member. The network and
  studio pages have the same chip and share the choice. My requests and Search
  are unchanged.

Fixed

• Home's hero keeps the title you were on when Hide what I have is
  turned on or off, or a request removes a title: the dots, the scroll
  position and the slide you see always agree, and if the title is gone it
  moves to the nearest slide. It also stays on that title when its width
  changes (turning an iPad), instead of sitting between slides.
• A late sign-out no longer touches a newer sign-in. Signing out (or
  changing household) that finishes late no longer signs you out of, or
  erases the credentials of, the household you signed in to meanwhile, and a
  setup link waits until the sign-out has finished. A late "signed out"
  answer (a 401) from a previous sign-in no longer signs you out of, or resets
  Hide what I have for, the sign-in you made after it.
• The stored sign-in is read, written and deleted one step at a time, and
  only ever deleted if it is still the one that ended, whatever order two
  sign-ins finish in.