fix(jellyfin): anchor the provider-key write on the file’s real root #121

2026-11-02T04:41:14-08:00

dank commented

2026-11-02 04:41:14 -08:00

install could never place the TVDB key. TheTVDB writes its own configuration
file and its serializer omits a null-valued setting entirely, so a fresh install
carries no <ApiKey> element at all — and the fallback insertion was anchored on
a hardcoded </Configuration>, a root that file does not have: the plugin names
its own root <PluginConfiguration>. The writer fell through to its own guard:

$ scripts/jellyfin-providers.sh install
/home/dank/Containers/jellyfin/config/plugins/configurations/Jellyfin.Plugin.Tvdb.xml: no place to write <ApiKey>

The key has been sitting in provider-keys (mode 600) on Dankserver since
October and has never been installable. verify has been reporting MISSING key
because of this, not because the secret was absent.

Change

xml_secret now takes its anchor from the document's own root element, so both
shapes Jellyfin actually produces work: the core plugins' <Configuration> and
a plugin's <PluginConfiguration>.
The refusal is kept for a file with no root at all — a refusal naming the file
still beats inventing a document shape.
The create-when-absent template is untouched (its own root closes what it
opens), and nothing about the pinned-artifact checks moves.

Evidence

New seam test reproduces the plugin-written file — its own root, no <ApiKey>,
settings beside it — and is red before this commit, green after; it also
asserts every other setting survives, because Jellyfin owns that file.
A second test pins the refusal that must survive the fix.
tests/jellyfin_providers.bats: 25 ok / 0 failed. ./tests/run.sh: 814/814.

After merge

./scripts/deploy.sh dankserver --service jellyfin places the key (the deployer
runs this installer before it restarts Jellyfin) and verify stops reporting
MISSING key. No library behaviour changes by itself: Shows fetches from
TMDb/OMDb, and adding TVDB as a fetcher is a separate decision.

cwd: /home/blank/.omp/wt/wt-20261030-163847-6d1fc1f · session: 01a18f2e-18b1-7573-bcd5-ac99636f8bcb (build worktree: /tmp/wt-jf-prov)

`install` could never place the TVDB key. TheTVDB writes its own configuration file and its serializer omits a null-valued setting entirely, so a fresh install carries no `<ApiKey>` element at all — and the fallback insertion was anchored on a hardcoded `</Configuration>`, a root that file does not have: the plugin names its own root `<PluginConfiguration>`. The writer fell through to its own guard: ``` $ scripts/jellyfin-providers.sh install /home/dank/Containers/jellyfin/config/plugins/configurations/Jellyfin.Plugin.Tvdb.xml: no place to write <ApiKey> ``` The key has been sitting in `provider-keys` (mode 600) on Dankserver since October and has never been installable. `verify` has been reporting `MISSING key` because of this, not because the secret was absent. ## Change - `xml_secret` now takes its anchor from the document's own root element, so both shapes Jellyfin actually produces work: the core plugins' `<Configuration>` and a plugin's `<PluginConfiguration>`. - The refusal is kept for a file with no root at all — a refusal naming the file still beats inventing a document shape. - The create-when-absent template is untouched (its own root closes what it opens), and nothing about the pinned-artifact checks moves. ## Evidence - New seam test reproduces the plugin-written file — its own root, no `<ApiKey>`, settings beside it — and is **red before this commit, green after**; it also asserts every other setting survives, because Jellyfin owns that file. - A second test pins the refusal that must survive the fix. - `tests/jellyfin_providers.bats`: 25 ok / 0 failed. `./tests/run.sh`: **814/814**. ## After merge `./scripts/deploy.sh dankserver --service jellyfin` places the key (the deployer runs this installer before it restarts Jellyfin) and `verify` stops reporting `MISSING key`. No library behaviour changes by itself: `Shows` fetches from TMDb/OMDb, and adding TVDB as a fetcher is a separate decision. --- cwd: /home/blank/.omp/wt/wt-20261030-163847-6d1fc1f · session: 01a18f2e-18b1-7573-bcd5-ac99636f8bcb (build worktree: /tmp/wt-jf-prov)

dank added 1 commit 2026-11-02 04:41:14 -08:00

fix(jellyfin): anchor the provider-key write on the file's real root e9314ea1ee

TheTVDB writes its own configuration file and its serializer omits a
null-valued setting entirely, so a fresh install has no <ApiKey> element to
fill, under a root element called <PluginConfiguration>. xml_secret's
fallback insertion was hardcoded to </Configuration>, matched nothing, and
install refused with "no place to write <ApiKey>" — measured on Dankserver
2026-11-02, where the TVDB key has been present in the secret file since
October and has never been installable.

The anchor now comes from the document's own root, so both shapes Jellyfin
actually produces work (the core plugins' <Configuration> and a plugin's
<PluginConfiguration>), and the refusal is kept for a file with no root at
all. Tests: the plugin-written shape is red before this commit and green
after; every other setting in the file is asserted preserved.

dank referenced this issue from a commit

2026-11-02 04:50:42 -08:00

docs(jellyfin): Shows is on providers, and the per-library door stays dead anyway

You are not authorized to merge this pull request.

This pull request can be merged automatically.

View command line instructions

Checkout

From your project repository, check out a new branch and test the changes.

git fetch -u origin chore/jellyfin-tvdb-key:chore/jellyfin-tvdb-key

git checkout chore/jellyfin-tvdb-key

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: dank/serverAppConfigs#121