0.13.0

Added

• The relays stand in for a service that fails. When TMDB, TheTVDB or
  AniList cannot be reached or does not answer in time, answers 429 or a
  500, 502, 503 or 504 — or, for AniList, 403, its API switched
  off; for TheTVDB, will not sign this server in — the last good answer
  to the same request is served, with an Age header and the locks written
  in: up to a week old for TMDB and TheTVDB, a day for AniList. TMDB's and
  TheTVDB's reference lists — TMDB's configuration, genres and
  certifications, TheTVDB's languages, genres, types and statuses — are kept
  in the database too (migration 0047, relay_document), up to 180 days, and
  answer when the memory holds nothing, after a restart for instance. Nothing
  asked with a client's own key, nothing about somebody's account and no feed
  of changes ever stands in. relays.staleIfError, on by default and set on
  Opening & APIs, turns it off; ams_relay_stale_total counts what was
  served so.
• Requests a relay is asked the same at once share one exchange with the
  service.
• TMDB's pictures can come from this server: with tmdb.images = server on
  Opening & APIs, the media store on and AMS_PUBLIC_URL set,
  /3/configuration gives {AMS_PUBLIC_URL}/tmdb-images/ as the address of
  TMDB's pictures, and Jellyfin, Kodi, Kometa and Emby fetch them there; the
  page says which is missing when server cannot take effect. The gate,
  GET /tmdb-images/{size}/{file}, serves a picture the store keeps from the
  store, and hands any other on from image.tmdb.org without keeping it; it
  takes TMDB's sizes and its site's crops alone, and names of TMDB's pictures
  alone. It is guarded as the TMDB relay is, AMS_TMDB_AUTH=apikey reading
  as allowlist there since a picture's address carries no key; an address
  it lets in is not held to AMS_RATE_LIMIT_PER_MINUTE, and a picture is not
  counted as a call to TMDB's API. tmdb stays the default; see
  docs/relays.md.
• The relays' feeds of changes name the works changed here — a lock put on
  or lifted, something added or taken out by hand, a refresh that changed a
  value — after the service's own, on their first page: TMDB's
  /3/movie/changes and /3/tv/changes by TMDB id, in the window asked;
  TheTVDB's updates by TheTVDB id, as TheTVDB writes a record of it, since
  the instant asked and fourteen days back at the most. A client that keeps in
  step by them — Yamtrack by TMDB's, Jellyfin's plugin by TheTVDB's — fetches
  a work corrected here at once rather than at its next full refresh. When
  the service fails, the feed fails with it, so that the client asks the same
  window again.
• The NFO export writes an anime's AniList and MyAnimeList ids, as
  <uniqueid type="anilist"> and <uniqueid type="mal">, after the others
  and never as the default: Jellyfin's AniList plugin then reads that entry
  rather than searching by title. A work filed under several entries is
  given the oldest of each, the first season far more often than not, since
  a reader keeps one id of a type. Episodes carry neither.
• .github/workflows/watch.yml: every Monday, and on demand, what this
  server imitates, relays or downloads is read against a snapshot kept in
  scripts/watch/snapshots/ — AniList's schema (every field, argument and
  value of the types this server's queries, its relay and six known clients
  read, and all of Query and Page), the keys of Skyhook's documents under
  /v1/tvdb, /v2/tvdb and /v2/tmdb and the last change to Sonarr's
  client of it, the version of TheTVDB's swagger with the last commit and the
  open pull requests of thetvdb/v4-api, the date and the OpenAPI definition
  of each page of TMDB's reference, and the keys of the anime list's entries.
  A run fails when one of them moved, or when the anime list or the database
  it is made from has not been updated for 21 days, and its summary says
  which, with the deprecated fields still read (Media.averageScore,
  today). It reads with no secret, GitHub's API with the run's own token, and
  writes nothing. python3 scripts/watch/watch.py runs it from a checkout;
  CONTRIBUTING.md, "Upstream watch", says how to take a snapshot again.
• The TMDB relay can answer the works this server holds itself
  (tmdb.relayMode = local-first, on Opening & APIs): a film's or a
  series' document and what is appended to it — the older releases,
  trailers and casts included — each part asked on its own, a series'
  seasons and episodes in TMDB's own numbering, each episode with the
  guests, director and writers the catalogue keeps of it, find, and the
  catalogue's works first on a search's first page, in TMDB's shape, from
  the catalogue with its locks and translations, and from TMDB's own
  document of the work for what the catalogue does not keep. No TMDB key is
  needed for them.
  Where to watch, reviews and the like are still asked of TMDB where it
  knows the work. relay stays the default.
• TheTVDB's relay can answer the works the catalogue holds itself
  (tvdb.relayMode = local-first): a series' record, its translations, its
  pictures, a page of its episodes in any order it holds, its seasons and
  episodes, a film's record — written in TheTVDB's shape from the catalogue
  and from TheTVDB's own record of the work, as last fetched, without asking
  TheTVDB or needing its key. A series TheTVDB does not know — one TMDB
  alone lists, a Fan-Kai, one entered by hand — is answered under the number
  Sonarr keeps it under, its seasons and episodes under negative ids. A
  search lists the works the catalogue finds before TheTVDB's results.
  ams_relay_local_total counts what both relays answered so.
• A series' tvdb_id in TMDB's ids is the number Sonarr keeps it under,
  made up where TheTVDB has none: Seerr hands a series entered by hand, or
  one TMDB alone lists, to Sonarr under a number Sonarr's metadata answers.
  The relay fills a tvdb_id TMDB leaves null for a series held here.
• TMDB's picture gate serves a picture of another source, or one uploaded,
  kept in the media store, under its key: what a document written in TMDB's
  shape names it by when TMDB's clients are sent to this server for
  pictures.
• TMDB's own numbering of a series is kept beside TheTVDB's, as an order,
  tmdb-aired ("TMDB (aired)"), written at every refresh that reads TMDB's
  seasons, and read from TMDB the first time a client asks for a series in
  it that no refresh has kept it for. Each of its places names the episode
  the series holds for it — the one of the same TMDB id when the two aired
  the same day, else the one episode held that aired that day — or carries
  TMDB's record of it. It is offered on the site and to Plex, as Plex's
  TMDB agent offers "TheMovieDB (Aired)", not among the season types of
  TheTVDB's documents, and can be frozen as the aired numbering as any
  order can. Who numbers a series does not change: TMDB does in TheTVDB's
  place only after numbering.fallbackAfter silent refreshes.
• Skyhook's TMDB edition, /v2/tmdb/shows/{language}/{id}/{seasonType} and
  /v2/tmdb/search, which the real service serves and Sonarr v5 does not
  call yet: a series by TMDB's id — a Fan-Kai or a series entered by hand by
  the id Sonarr knows it by — numbered by TMDB (default), each episode by
  its TMDB id, TMDB's episode groups as season types under their bare ids,
  in the real service's shape. A type the series has not is answered in
  default, where the real service sends no episode; a series TheTVDB
  numbers whose TMDB numbering cannot be read is a 502, which Sonarr asks
  again on. scripts/e2e-skyhook-v2.sh and the weekly parity run compare
  it with the real service.
• The model keeps what TMDB's and TheTVDB's answers carried all along
  (migration 0048): networks and companies, and TMDB's keywords, as things
  of their own with their ids, logos and countries; every video, the chosen
  trailer unchanged; the whole crew, each credit with TMDB's department and
  job, up to tmdb.crewLimit (30) — the crew beyond directing, writing and
  production without portraits; TMDB's pictures with their language, size
  and votes, up to tmdb.imageLimit (5) of each kind, the best of each
  useful language first; a season's title and synopsis, and a person's
  biography, in every language TMDB has them in. Works held gain them at
  their next refresh. Radarr is given each crew member's department and job.
• The season chart shows the AniList and MyAnimeList entry that premieres in
  the quarter beside the season it belongs to — the second half of a split
  season among the series carrying on — placed on the season's episodes by
  the anime identifier list and described from them: its part, episodes,
  days, status and next episode. describe=true adds MyAnimeList's
  description of each, which the site asks for only when the reader opens
  it.
• A work's page lists its whole crew a department at a time, every video its
  sources list — the trailer chosen first, a YouTube one played in place only
  once asked for — and its networks and companies with their logos and their
  countries. Each company and each of TMDB's keywords has a page of its own,
  /company/{id} and /keyword/{id} (GET /api/v1/companies/{id},
  /keywords/{id}, open to visitors where the catalogue is), and the
  catalogue is filtered by them (company=, keywordId=). A person known
  only for their crew work has a tab of it.
• Opening & APIs chooses what the TMDB and TheTVDB relays answer themselves
  (tmdb.relayMode, tvdb.relayMode), and the settings take how much of
  TMDB's crew and pictures a work keeps (tmdb.crewLimit, tmdb.imageLimit).
• The task refresh.replay fills into every work, from the answers kept with
  it and without asking anybody, what this version keeps that earlier ones
  let go: networks and companies, TMDB's keywords and videos, the pictures'
  languages and sizes, the crew's departments and jobs.
• MyAnimeList is asked for how many episodes an entry is to have, how far it
  has aired, its type, what it was adapted from and the entries related to
  it, which describe each season and cour of an anime series.

Changed

• The relays go through the server's own door to each service: as many
  calls at once between them and the server's own fetches — sixteen to TMDB,
  eight to TheTVDB, four to AniList — and one pause for all when the service
  answers 429, or 503 with Retry-After, whoever met it. A relay never
  waits that pause out: it answers with what it kept, or 429 with the
  seconds left in Retry-After, where it asked the service again. A
  client's AniList query is never spaced out as the source's fetches are.
• The relay space keeps a document a week, where it kept a day, so that it
  can stand in for its service. What it serves as fresh is unchanged, but
  for TMDB's feeds of changes, kept for hours by mistake and now a quarter of
  an hour, and AniList's genre and tag lists asked alone, half a day where
  they were an hour. A relayed document kept on the cache server by 0.12 is
  forgotten at the upgrade.
• A path of TMDB's v4 API other than a public list — an account's lists,
  ratings and watchlist, which Radarr's TMDb User import list asks for — is
  refused in TMDB's own shape, {"success": false, "status_code": 3, "status_message": …}, the message naming this server, its version and its
  public address, where it was this server's bare 403. Nothing is made up
  in an account's place.
• A TheTVDB client signing in with its own key has TheTVDB asked with the
  key and its PIN alone: what Kodi's scraper writes beside them — its user's
  gender, year of birth and a device id — is no longer handed on.
• With no TheTVDB key of its own, the server still signs in a client that
  brings a key issued here, and answers the pages it answers itself — an
  order kept here or frozen, altdvd and alttwo from what was read — where
  it answered 503 to the sign-in and to every page. Whatever only TheTVDB
  can answer is still 503.
• The TheTVDB relay hands a client's If-None-Match and
  If-Modified-Since on only with the client's own token: a request asked
  with the server's, kept and shared, goes without them.
• AniList is asked for weightedScore, which replaces the deprecated
  averageScore it is the same figure as; averageScore is read when the
  first is missing. Should AniList stop knowing either field, the query it
  refuses for it is sent again without it, and so is every later one, where
  every AniList fetch would have failed.
• AniList's relations are asked for in their third version, which adds
  SAME_UNIVERSE: a work set in the same universe is kept under that kind,
  shown as Same universe after the works sharing a character and before
  the others.
• The MCP server stays off until an administrator switches it on, and now
  says why beside the switch: switched on, it hands agents — large language
  models — the catalogue, TMDB's titles, overviews and credits included,
  which TMDB's API terms forbid using in connection with an AI application
  (§1.C) and count as commercial use in an LLM chatbot (§2.A). While it is
  on, the server writes the same warning to its log at each start. The
  documentation no longer says that nothing is handed to a model.
• The documentation of the search says what the code does: a series search
  merges the catalogue's results and TMDB's every time, and asks TheTVDB,
  then Skyhook, only while nothing is found.
• The AniList relay writes more of what was corrected here: the titles
  hidden here leave an entry's other names, a locked adult flag and main
  studio are written, and an entry that is one cour of a work takes the
  dates, status and next episode its corrected schedule gives, and what the
  work's locked status and dates say of it. A locked title and synopsis go
  into the entry that is the whole work alone, where every entry of it took
  them: one of its seasons or cours keeps AniList's name, and a client lists
  each season under its own.
• Hiding a crew credit hides every crew job of that person on the work, in
  the TMDB relay's answers too; their directing, writing and producing
  credits stay.
• A season's title and synopsis are in the language asked where TMDB gave
  them in it or somebody wrote them for it: on the site, in Plex, and — its
  name — in Sonarr v5's Skyhook, whose TMDB edition now names a season
  wherever TMDB cuts it as the series is, where it named one only when the
  whole numbering was the series' own. A person's biography on the site is
  in the reader's language too.

Fixed

• A series TMDB numbers apart from TheTVDB — One Piece, many an anime split
  by cour — had TMDB's episodes paired with TheTVDB's by number. Past the
  first place they part, each episode took another's TMDB id, and with it
  that episode's synopsis, still, rating and runtime where TheTVDB had none,
  its texts in other languages, its place in TMDB's episode groups, and the
  locks the TMDB relay writes into it. TMDB's episodes are now paired by the
  day each aired where their numbers disagree with it: of One Piece's
  1,242 episodes, 1,201 take a TMDB id, every one the episode of its date,
  where 1,194 of TMDB's are numbered otherwise.
• The seasons of such a series fared the same: TMDB's sagas of One Piece
  lent TheTVDB's arc of the same number their name, synopsis, first day,
  TMDB id, pictures and names in other languages. A season of TMDB's lends
  them only where its episodes, paired by the day they aired, are that
  season's and no other's.
• Two works entered by hand before each was drawn a number of its own may
  make one. Skyhook's and TheTVDB's dialects answered the first alone under
  it, but TMDB's search and find listed both, so a client could add the
  later one under the first's number; they answer the first alone too.
• The seasons and episodes asked with a series' TMDB document
  (append_to_response=season/1,season/1/images,season/1/episode/2) take the
  locks and lose the posters hidden here, as the same documents asked on
  their own do: Kodi's TV scraper and Yamtrack read seasons that way, and
  were given TMDB's text.
• Seerr's TheTVDB option could not sign in through the relay: it names its
  key apiKey, which was refused with 400. Either name is taken; a
  sign-in that names both is refused.
• A page of episodes answered here linked to itself as /v4/v4/…; its
  self is the path and query asked, less a key for this server.
• The AniList relay kept an hour, and served to every caller, what AniList
  answered about somebody when nobody signed the query: a page of users,
  mutual followers, likes, activity replies, forum threads and comments,
  reviews, a user's AniChart settings, who submitted a staff entry, and what
  a user recommended or a viewer's own list picked. Checked against AniList's
  schema, none of it is kept, shared with another caller or served stale any
  more.