Deploy the plugin to dionysus and verify on the Pixel #6

Closed
opened 2026-08-09 20:59:06 +00:00 by aiko · 3 comments
Owner

Parent

#1 — PRD: Kurageyomi

What to build

Nothing. This is the human-and-Hermes half of #2, split out because it cannot be verified by an
agent working on dex-win: it needs shell on dionysus and someone holding the phone.

#2 produces a built Kurageyomi.dll that serves an authenticated page. This issue gets it
running on the real server and confirms it works from the Pixel.

Hand docs/deploy-brief-hermes.md to the agent with shell on dionysus. The brief is
discovery-first — it finds the container, the plugin path, the ownership, and who actually owns
restarts, rather than assuming any of them. It also names ABI mismatch as the expected first
failure and says to report that back rather than patching around it on the box.

The ABI risk looks smaller than ADR 0001 feared: Jellyfin 10.11.11 targets net9.0 and
Jellyfin.Controller 10.11.11 is published on NuGet with a matching net9.0 dependency group,
so the plugin can be built against the exact running version rather than the template's 10.9.

Acceptance criteria

  • Plugin installed on dionysus following the deploy brief
  • Jellyfin restarts cleanly and still reports 10.11.11
  • GET /Plugins lists Kurageyomi as Active
  • The plugin's page loads on the Pixel over the tailnet
  • The page can be installed to the home screen and opens standalone
  • Jellyfin behaves normally with the plugin idle — playback and the web client unaffected
  • The working deploy steps are recorded back into docs/deploy-brief-hermes.md so later
    deploys are mechanical

Blocked by

## Parent #1 — PRD: Kurageyomi ## What to build Nothing. This is the human-and-Hermes half of #2, split out because it cannot be verified by an agent working on dex-win: it needs shell on dionysus and someone holding the phone. #2 produces a built `Kurageyomi.dll` that serves an authenticated page. This issue gets it running on the real server and confirms it works from the Pixel. Hand `docs/deploy-brief-hermes.md` to the agent with shell on dionysus. The brief is discovery-first — it finds the container, the plugin path, the ownership, and who actually owns restarts, rather than assuming any of them. It also names ABI mismatch as the expected first failure and says to report that back rather than patching around it on the box. The ABI risk looks smaller than ADR 0001 feared: Jellyfin 10.11.11 targets `net9.0` and `Jellyfin.Controller 10.11.11` is published on NuGet with a matching `net9.0` dependency group, so the plugin can be built against the exact running version rather than the template's 10.9. ## Acceptance criteria - [ ] Plugin installed on dionysus following the deploy brief - [ ] Jellyfin restarts cleanly and still reports 10.11.11 - [ ] `GET /Plugins` lists Kurageyomi as Active - [ ] The plugin's page loads on the Pixel over the tailnet - [ ] The page can be installed to the home screen and opens standalone - [ ] Jellyfin behaves normally with the plugin idle — playback and the web client unaffected - [ ] The working deploy steps are recorded back into `docs/deploy-brief-hermes.md` so later deploys are mechanical ## Blocked by - #2
Author
Owner

This was generated by AI during triage.

main is ready to deploy — #2 through #5 are merged at c8440ee. 73 tests pass (37 C#, 36
TypeScript), Release build clean with warnings as errors.

Building the artifact

Requires .NET SDK 9 and Node. From a clone of main:

cd web && npm install && npm run build
cd .. && dotnet build -c Release

That produces, in src/Jellyfin.Plugin.Kurageyomi/bin/Release/net9.0/:

  • Jellyfin.Plugin.Kurageyomi.dll
  • meta.json — declares targetAbi 10.11.11.0

Both go into the plugin directory together. The web assets are compiled into the dll as
embedded resources, so there is nothing else to copy.

The npm run build step is not optional: it compiles the phone app into the folder the C#
build embeds. Skipping it ships whatever was compiled last.

What to check once it is running

Beyond the acceptance criteria above, these are the first things likely to be wrong, in order:

  1. Plugin loads at all. GET /Plugins should list Kurageyomi as Active. If not, the server
    log names the reason — ABI mismatch is the usual one, though we now compile against
    Jellyfin.Controller 10.11.11, the exact version this server runs.
  2. The shell loads anonymously. GET /Kurageyomi should return HTML with no token. If it
    401s, plugin controllers are not honouring [AllowAnonymous] in this server's pipeline, and
    the app cannot load at all.
  3. Sign-in works from the phone. The page posts to /Users/AuthenticateByName. A 400 here
    usually means the Authorization header we build is malformed.
  4. GET /Kurageyomi/api/Sessions returns your sessions while something is playing, and the
    JSON is PascalCase (DeviceName, PositionTicks). The phone now expects PascalCase; if
    this server somehow serves camelCase for plugin controllers, every field reads as undefined
    and the page renders blank with no error. This is the single most likely silent failure.
  5. GET /Kurageyomi/api/Cues?itemId=…&mediaSourceId=…&streamIndex=… returns cues for a
    Japanese text track.

Report back what breaks with the exact response, rather than working around it on the box.

> *This was generated by AI during triage.* `main` is ready to deploy — #2 through #5 are merged at `c8440ee`. 73 tests pass (37 C#, 36 TypeScript), Release build clean with warnings as errors. ## Building the artifact Requires .NET SDK 9 and Node. From a clone of `main`: ``` cd web && npm install && npm run build cd .. && dotnet build -c Release ``` That produces, in `src/Jellyfin.Plugin.Kurageyomi/bin/Release/net9.0/`: - `Jellyfin.Plugin.Kurageyomi.dll` - `meta.json` — declares `targetAbi 10.11.11.0` Both go into the plugin directory together. The web assets are compiled into the dll as embedded resources, so there is nothing else to copy. The `npm run build` step is not optional: it compiles the phone app into the folder the C# build embeds. Skipping it ships whatever was compiled last. ## What to check once it is running Beyond the acceptance criteria above, these are the first things likely to be wrong, in order: 1. **Plugin loads at all.** `GET /Plugins` should list Kurageyomi as Active. If not, the server log names the reason — ABI mismatch is the usual one, though we now compile against `Jellyfin.Controller 10.11.11`, the exact version this server runs. 2. **The shell loads anonymously.** `GET /Kurageyomi` should return HTML with no token. If it 401s, plugin controllers are not honouring `[AllowAnonymous]` in this server's pipeline, and the app cannot load at all. 3. **Sign-in works from the phone.** The page posts to `/Users/AuthenticateByName`. A 400 here usually means the `Authorization` header we build is malformed. 4. **`GET /Kurageyomi/api/Sessions` returns your sessions** while something is playing, and the JSON is **PascalCase** (`DeviceName`, `PositionTicks`). The phone now expects PascalCase; if this server somehow serves camelCase for plugin controllers, every field reads as undefined and the page renders blank with no error. This is the single most likely silent failure. 5. **`GET /Kurageyomi/api/Cues?itemId=…&mediaSourceId=…&streamIndex=…`** returns cues for a Japanese text track. Report back what breaks with the exact response, rather than working around it on the box.
Author
Owner

This was generated by AI during triage.

Deploy brief updated with the real fetch and verification steps — docs/deploy-brief-hermes.md at 943c4ab, also served at https://dex-win.tail1ee5d.ts.net/kurageyomi/deploy-brief-hermes.md

Nothing needs building on dionysus. Prebuilt artifacts are on the tailnet:

curl -fsSLO https://dex-win.tail1ee5d.ts.net/kurageyomi/Jellyfin.Plugin.Kurageyomi.dll
curl -fsSLO https://dex-win.tail1ee5d.ts.net/kurageyomi/meta.json
curl -fsSLO https://dex-win.tail1ee5d.ts.net/kurageyomi/SHA256SUMS
sha256sum -c SHA256SUMS

dll is 56,832 bytes with all seven web assets embedded (verified). meta.json declares targetAbi 10.11.11.0. Both files go in a Kurageyomi_0.1.0.0 directory under the plugins path.

Caveat: the share is tailnet-only from dex-win, so that machine has to be awake. It currently reports a Tailscale DNS health warning — if the name fails, it is 100.117.235.109, but the cert is for the MagicDNS name.

> *This was generated by AI during triage.* Deploy brief updated with the real fetch and verification steps — `docs/deploy-brief-hermes.md` at `943c4ab`, also served at https://dex-win.tail1ee5d.ts.net/kurageyomi/deploy-brief-hermes.md Nothing needs building on dionysus. Prebuilt artifacts are on the tailnet: ``` curl -fsSLO https://dex-win.tail1ee5d.ts.net/kurageyomi/Jellyfin.Plugin.Kurageyomi.dll curl -fsSLO https://dex-win.tail1ee5d.ts.net/kurageyomi/meta.json curl -fsSLO https://dex-win.tail1ee5d.ts.net/kurageyomi/SHA256SUMS sha256sum -c SHA256SUMS ``` dll is 56,832 bytes with all seven web assets embedded (verified). `meta.json` declares `targetAbi 10.11.11.0`. Both files go in a `Kurageyomi_0.1.0.0` directory under the plugins path. Caveat: the share is tailnet-only from dex-win, so that machine has to be awake. It currently reports a Tailscale DNS health warning — if the name fails, it is 100.117.235.109, but the cert is for the MagicDNS name.
Author
Owner

This was generated by AI during triage.

Deployed and working on dionysus: plugin Active, shell served anonymously, sign-in from the Pixel, sessions followed, transcript rendering from a real Japanese track.

Closed at the owner's call. Remaining and owned by aiko: putting Jellyfin behind https (tailscale serve --bg 8096 on dionysus) so the page runs in a secure context — that restores Screen Wake Lock and makes the app installable to the home screen, neither of which is possible over http://dionysus:8096.

> *This was generated by AI during triage.* Deployed and working on dionysus: plugin Active, shell served anonymously, sign-in from the Pixel, sessions followed, transcript rendering from a real Japanese track. Closed at the owner's call. Remaining and owned by aiko: putting Jellyfin behind https (`tailscale serve --bg 8096` on dionysus) so the page runs in a secure context — that restores Screen Wake Lock and makes the app installable to the home screen, neither of which is possible over `http://dionysus:8096`.
aiko closed this issue 2026-08-10 08:10:20 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
mobrule/kurageyomi#6
No description provided.