Verweise der Form #123 im folgenden Text beziehen sich auf die GitHub-Nummerierung, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar.
MediathekArr (https://github.com/PCJones/MediathekArr) soll als zehnter Container in den freesailarr-Pod. Es täuscht gegenüber Prowlarr einen Usenet-Indexer und gegenüber Sonarr/Radarr einen SABnzbd-Downloader vor und lädt Inhalte per HTTP direkt aus den Mediatheken von ARD und ZDF.
Beide Abnehmer sitzen bereits im Pod und teilen sich gluetuns Netzwerk-Namensraum — sie erreichen MediathekArr über 127.0.0.1, ohne Service, ohne DNS, ohne Ingress-Umweg. Der Zuschnitt passt also, und die Aufnahme ist rein additiv.
Alles Folgende ist gemessen, in zwei Runden in Wegwerf-k3d-Clustern, jeweils mit Kontrolllauf über direkten Egress. Wo etwas nicht gemessen ist, steht es ausdrücklich dabei.
Der Geo-Vorbehalt, und warum er den Chart nicht aufhält
Der Tunnel geht per Chart-Vorgabe über Zürich; ARD und ZDF sperren Teile ihres Katalogs außerhalb Deutschlands. Alle Container hängen an gluetuns Namensraum, einen Bypass für einen einzelnen Container gibt es nicht.
Streuprobe, 480 URLs über 12 Kanäle: 104 von 473 direkt ladbaren URLs sind über Zürich gesperrt = 22,0 % (KI etwa 18–26 %). Auf der deutschen Seite kein einziger Fehlschlag. Die Verteilung ist stark ungleich: ONE 97,5 %, ZDFneo 47,5 %, ZDFinfo 37,5 %, Das Erste 20,5 %, ZDF 10,3 %, BR 0 %.
Vollerhebung über sechs konkret nachgefragte Formate, 584 URLs, keine Stichprobe: vier Serien zu 100 % ladbar, eine praktisch (nur ein Trailer gesperrt), eine zu 95 % gesperrt.
Die Ausgangswahl ist ein Deployment-Wert, keine Chart-Eigenschaft. Der Chart entsteht unabhängig davon; er schuldet nur eine ehrliche Dokumentation.
Was dokumentiert wird: das Verfahren, nicht die Momentaufnahme
Der Geo-Marker im CDN-Pfad war über beide Runden hinweg ein perfekter Prädiktor — in der Vollerhebung 584 von 584 Fällen korrekt, keine einzige Fehlklassifikation:
Eine Serientabelle in values.yaml wäre in einem halben Jahr veraltet. Das Verfahren nicht: wer wissen will, ob seine Sendung über einen fremden Ausgang funktioniert, sieht im Pfad der Medien-URL nach. Das gehört in die Dokumentation, zusammen mit dem Fluchtweg (deutscher Ausgang für den gesamten Stack) und dessen Preis.
Die naheliegende Faustregel „Eigenproduktion = weltweit frei" ist belegt falsch und darf so nicht in der Dokumentation landen: eine ARD-Eigenproduktion war gesperrt, eine Lizenzserie offen. Nur der Marker zählt.
Die Falle, die in NOTES.txt gehört
MediathekArr prüft den HTTP-Statuscode nie. A/B gemessen mit identischem NZB:
direkt (DE)
über Zürich
status
Completed
Failed
bytes
94 235 525
0
fail_message
null
null
Bei gesperrtem Abruf schreibt es die rund 476 Byte große HTML-Fehlerseite als .mp4 weg und protokolliert „Download completed". Erst mkvmerge verweigert die Datei (Exit-Code 2) und kippt den Status auf Failed.
Zwei Konsequenzen, beide dokumentationspflichtig:
Sonarr bekommt „fehlgeschlagen" ohne Grund.fail_message ist null. Eine Geosperre sieht im Betrieb exakt aus wie ein defekter Server, eine abgelaufene URL oder ein voller Datenträger. Auch der Containerlog nennt die 403 nicht.
Der Schutz ist ein Zufallsprodukt, kein Fehlerhandling. Er hängt allein daran, dass mkvmerge die HTML-Seite ablehnt. Jede Geo-Antwort, die mkvmerge akzeptiert, würde als Completed gemeldet — und dann wandern kaputte Dateien in die Bibliothek. In beiden Messrunden ist das nicht eingetreten (Akamai liefert durchgehend HTML), aber darauf ist kein Verlass.
Umsetzung — was gemessen ist
Zwei Ports, nicht einer.MediathekArrDownloader (SABnzbd-Rolle) auf 5007, MediathekArrServer (Newznab-Rolle für Prowlarr) auf 5008. Die Upstream-Dokumentation nennt nur 5007. Im Pod sind belegt: 9999, 8080, 9696, 8191, 7878, 8989, 5055, 6767 — beide neuen Ports sind frei.
Die SABnzbd-API liegt unter /download/api, nicht unter /api./api auf 5007 antwortet mit einem Newznab-Validierungsfehler und führt in die Irre.
Startgate auf gluetun — der schärfste Punkt. Startet MediathekArr, bevor der Tunnel steht, scheitert der Ruleset-Abruf, und die Instanz lieferte danach über elf Minuten hinweg 0 Treffer auf jede Newznab-Suche, ohne dass ein Retry das reparierte. Mit 75 s Verzögerung: Ruleset ok, Suche identisch zur direkten Instanz. Ohne Startgate ist der Indexer stumm und nichts meldet es — kein Fehler, keine unready Probe, nur leere Suchergebnisse. Die Suche selbst ist nicht geogesperrt (56 Treffer über beide Ausgänge).
Härtung, drei Varianten gemessen. Der auskommentierte Nicht-Root-Block im Dockerfile ist für den beta-Stand überholt (docker_start.sh enthält einen gosu-Pfad). Ergebnis:
Ohne beschreibbare Volumes stürzt der Container ab.
PUID/PGID wird dabei nicht gebraucht.
Beschreibbar sein müssen:
/app/config — Konfigurations-JSON, gehört auf einen eigenen volumeClaimTemplate wie bei den anderen Apps.
/data/mediathek — incomplete/ und complete/.
/tmp war nicht erforderlich (die RO-Variante ohne /tmp lief durch). Als billige Absicherung trotzdem sinnvoll — das ist eine Empfehlung, keine Messung.
/app/downloads wird von der Anwendung gar nicht benutzt, obwohl die docker-compose.yml es als Volume führt. Ihre Vorgaben sind /data/mediathek/incomplete und /data/mediathek/complete.
Wohin die Downloads gehören — zu entscheiden, nicht zu raten.complete/ muss auf dem geteilten downloads-Claim liegen, sonst kann Sonarr im selben Pod nichts importieren, und DOWNLOAD_FOLDER_PATH_MAPPING muss auf genau diesen Pfad zeigen — eine Abweichung importiert schweigend nichts. incomplete/ gehört nicht in einen emptyDir: ein emptyDir zählt gegen das ephemeral-storage-Limit des Containers, und ein großer Download lässt den kubelet den ganzen Pod räumen, mit allen neun anderen Containern. Das ist dieselbe Falle, die in ytdlp-web-player dokumentiert ist.
Image per Digest pinnen. Die Tags sind unbrauchbar: latest stammt vom 12.11.2024 (= v0.2.5), die README empfiehlt beta (zuletzt 15.06.2026). Aufgelöst:
Single-Arch, nur linux/amd64, kein arm64 — gehört als Kommentar an die Stelle, auch wenn der Zielcluster durchgehend amd64 ist. Dazu eine Renovate-Regel für Digest-Updates, im Trockenlauf belegt: eine gültige Regel ist keine treffende Regel (#158, searxng-Runde).
Es gibt keinen Health-Endpunkt. Gemessen 404 auf /health, /healthz, /api/health, /download/health, /status, /ping. Belegte 200er-Kandidaten für die Probes:
Port 5008: GET /api?t=caps
Port 5007: GET /download/api?mode=version&output=json&apikey=x oder GET /download/
Offen, ausdrücklich ungemessen
Ein Teil des Mediathek-Bestands liegt als HLS-Playlist (application/x-mpegURL) statt als progressives MP4 vor. MediathekArrs Downloader lädt eine einzelne HTTP-Datei und remuxt sie mit mkvmerge; ob er mit einer m3u8-Playlist umgehen kann, ist nicht gemessen. Falls nicht, fallen diese Einträge unabhängig von jeder Geosperre aus. Das gehört als offene Frage in values.yaml, nicht als Annahme in die eine oder andere Richtung.
Zu belegen
Der Chart rendert und installiert, mit mediathekarr.enabled: true und false, ohne dass bestehende Installationen sich ändern.
Das Startgate wirkt. Zeigen, dass der Container nicht vor gluetuns Bereitschaft startet — und dass die Newznab-Suche danach Treffer liefert. Ein grüner Pod ist hier kein Beleg, weil der Fehlerfall grün aussieht.
Die Probes. Auf einem der belegten 200er-Pfade, nicht auf einem geratenen.
Die Renovate-Digest-Regel im Trockenlauf.
Härtung wie gemessen: nicht-root, uid 1000, readOnlyRootFilesystem: true.
Versionsstufe
Minor — rein additiv, standardmäßig aus, und der volumeClaimTemplate entsteht nur bei aktiviertem Flag, sodass sich für bestehende Installationen nichts ändert. Aktuell 3.0.5+up1.0.0, also 3.1.0+up1.0.0. Die appVersion des Charts bleibt unberührt: sie ist frei gewählt und an kein Upstream gebunden, alle Images sind in values.yaml gepinnt.
Dazu wie üblich: values.schema.json, CI-Fixtures unter ci/freesailarr/, Renovate-Eintrag, README-Aktualisierung, wo sie repo-weites Verhalten berührt.
> Migriert aus [`jk-cluster/helm-charts#245`](https://github.com/jk-cluster/helm-charts/issues/245) — urspruenglich angelegt von **jk-cluster-bot** am 2026-09-08.
>
> Verweise der Form `#123` im folgenden Text beziehen sich auf die **GitHub-Nummerierung**, nicht auf die Nummern in diesem Repo. Geschlossene Issues wurden nicht mitgezogen und sind weiterhin nur auf GitHub lesbar.
---
MediathekArr (https://github.com/PCJones/MediathekArr) soll als **zehnter Container** in den freesailarr-Pod. Es täuscht gegenüber Prowlarr einen Usenet-Indexer und gegenüber Sonarr/Radarr einen SABnzbd-Downloader vor und lädt Inhalte per HTTP direkt aus den Mediatheken von ARD und ZDF.
Beide Abnehmer sitzen bereits im Pod und teilen sich gluetuns Netzwerk-Namensraum — sie erreichen MediathekArr über `127.0.0.1`, ohne Service, ohne DNS, ohne Ingress-Umweg. Der Zuschnitt passt also, und die Aufnahme ist rein additiv.
Alles Folgende ist **gemessen**, in zwei Runden in Wegwerf-k3d-Clustern, jeweils mit Kontrolllauf über direkten Egress. Wo etwas nicht gemessen ist, steht es ausdrücklich dabei.
## Der Geo-Vorbehalt, und warum er den Chart nicht aufhält
Der Tunnel geht per Chart-Vorgabe über Zürich; ARD und ZDF sperren Teile ihres Katalogs außerhalb Deutschlands. Alle Container hängen an gluetuns Namensraum, einen Bypass für einen einzelnen Container gibt es nicht.
**Streuprobe, 480 URLs über 12 Kanäle:** 104 von 473 direkt ladbaren URLs sind über Zürich gesperrt = **22,0 %** (KI etwa 18–26 %). Auf der deutschen Seite kein einziger Fehlschlag. Die Verteilung ist stark ungleich: ONE 97,5 %, ZDFneo 47,5 %, ZDFinfo 37,5 %, Das Erste 20,5 %, ZDF 10,3 %, BR 0 %.
**Vollerhebung über sechs konkret nachgefragte Formate, 584 URLs, keine Stichprobe:** vier Serien zu 100 % ladbar, eine praktisch (nur ein Trailer gesperrt), eine zu 95 % gesperrt.
Die Ausgangswahl ist ein **Deployment-Wert, keine Chart-Eigenschaft**. Der Chart entsteht unabhängig davon; er schuldet nur eine ehrliche Dokumentation.
### Was dokumentiert wird: das Verfahren, nicht die Momentaufnahme
Der Geo-Marker im CDN-Pfad war über beide Runden hinweg ein **perfekter Prädiktor** — in der Vollerhebung 584 von 584 Fällen korrekt, keine einzige Fehlklassifikation:
| Marker im Pfad | Verhalten außerhalb DE |
|---|---|
| `/de/`, `/geo/de/`, `/deutschlandweit/`, `geoavailability_D` | gesperrt |
| `/weltweit/` | offen |
| `/none/` (ZDF) | offen |
| `/dach/`, `deChAt` (WDR-Variante) | offen — die Schweiz liegt in DACH |
Eine Serientabelle in `values.yaml` wäre in einem halben Jahr veraltet. Das Verfahren nicht: wer wissen will, ob seine Sendung über einen fremden Ausgang funktioniert, sieht im Pfad der Medien-URL nach. **Das** gehört in die Dokumentation, zusammen mit dem Fluchtweg (deutscher Ausgang für den gesamten Stack) und dessen Preis.
Die naheliegende Faustregel „Eigenproduktion = weltweit frei" ist **belegt falsch** und darf so nicht in der Dokumentation landen: eine ARD-Eigenproduktion war gesperrt, eine Lizenzserie offen. Nur der Marker zählt.
## Die Falle, die in NOTES.txt gehört
MediathekArr **prüft den HTTP-Statuscode nie**. A/B gemessen mit identischem NZB:
| | direkt (DE) | über Zürich |
|---|---|---|
| `status` | `Completed` | `Failed` |
| `bytes` | 94 235 525 | 0 |
| `fail_message` | `null` | **`null`** |
Bei gesperrtem Abruf schreibt es die rund 476 Byte große HTML-Fehlerseite als `.mp4` weg und protokolliert „Download completed". Erst **mkvmerge** verweigert die Datei (Exit-Code 2) und kippt den Status auf `Failed`.
Zwei Konsequenzen, beide dokumentationspflichtig:
1. **Sonarr bekommt „fehlgeschlagen" ohne Grund.** `fail_message` ist `null`. Eine Geosperre sieht im Betrieb exakt aus wie ein defekter Server, eine abgelaufene URL oder ein voller Datenträger. Auch der Containerlog nennt die 403 nicht.
2. **Der Schutz ist ein Zufallsprodukt, kein Fehlerhandling.** Er hängt allein daran, dass mkvmerge die HTML-Seite ablehnt. Jede Geo-Antwort, die mkvmerge akzeptiert, würde als `Completed` gemeldet — und dann wandern kaputte Dateien in die Bibliothek. In beiden Messrunden ist das nicht eingetreten (Akamai liefert durchgehend HTML), aber darauf ist kein Verlass.
## Umsetzung — was gemessen ist
**Zwei Ports, nicht einer.** `MediathekArrDownloader` (SABnzbd-Rolle) auf **5007**, `MediathekArrServer` (Newznab-Rolle für Prowlarr) auf **5008**. Die Upstream-Dokumentation nennt nur 5007. Im Pod sind belegt: 9999, 8080, 9696, 8191, 7878, 8989, 5055, 6767 — beide neuen Ports sind frei.
**Die SABnzbd-API liegt unter `/download/api`, nicht unter `/api`.** `/api` auf 5007 antwortet mit einem Newznab-Validierungsfehler und führt in die Irre.
**Startgate auf gluetun — der schärfste Punkt.** Startet MediathekArr, bevor der Tunnel steht, scheitert der Ruleset-Abruf, und die Instanz lieferte danach **über elf Minuten hinweg 0 Treffer** auf jede Newznab-Suche, ohne dass ein Retry das reparierte. Mit 75 s Verzögerung: Ruleset ok, Suche identisch zur direkten Instanz. Ohne Startgate ist der Indexer stumm und **nichts meldet es** — kein Fehler, keine unready Probe, nur leere Suchergebnisse. Die Suche selbst ist nicht geogesperrt (56 Treffer über beide Ausgänge).
**Härtung, drei Varianten gemessen.** Der auskommentierte Nicht-Root-Block im Dockerfile ist für den `beta`-Stand überholt (`docker_start.sh` enthält einen gosu-Pfad). Ergebnis:
- `runAsNonRoot: true` + `runAsUser: 1000` + **`readOnlyRootFilesystem: true`** + `fsGroup: 1000` läuft vollständig durch, inklusive echtem Download und mkvmerge-Remux.
- Ohne beschreibbare Volumes stürzt der Container ab.
- PUID/PGID wird dabei **nicht** gebraucht.
Beschreibbar sein müssen:
- `/app/config` — Konfigurations-JSON, gehört auf einen eigenen `volumeClaimTemplate` wie bei den anderen Apps.
- `/data/mediathek` — `incomplete/` und `complete/`.
- `/tmp` war **nicht** erforderlich (die RO-Variante ohne `/tmp` lief durch). Als billige Absicherung trotzdem sinnvoll — das ist eine Empfehlung, keine Messung.
**`/app/downloads` wird von der Anwendung gar nicht benutzt**, obwohl die docker-compose.yml es als Volume führt. Ihre Vorgaben sind `/data/mediathek/incomplete` und `/data/mediathek/complete`.
**Wohin die Downloads gehören — zu entscheiden, nicht zu raten.** `complete/` muss auf dem geteilten downloads-Claim liegen, sonst kann Sonarr im selben Pod nichts importieren, und `DOWNLOAD_FOLDER_PATH_MAPPING` muss auf genau diesen Pfad zeigen — eine Abweichung importiert schweigend nichts. `incomplete/` gehört **nicht** in einen emptyDir: ein emptyDir zählt gegen das ephemeral-storage-Limit des Containers, und ein großer Download lässt den kubelet den **ganzen Pod** räumen, mit allen neun anderen Containern. Das ist dieselbe Falle, die in ytdlp-web-player dokumentiert ist.
**Image per Digest pinnen.** Die Tags sind unbrauchbar: `latest` stammt vom 12.11.2024 (= v0.2.5), die README empfiehlt `beta` (zuletzt 15.06.2026). Aufgelöst:
```
pcjones/mediathekarr:beta
sha256:3ed7e1487810e1519301bd56a0c420e260e428295b029a47806c0397e4a52a33
```
Single-Arch, **nur `linux/amd64`**, kein arm64 — gehört als Kommentar an die Stelle, auch wenn der Zielcluster durchgehend amd64 ist. Dazu eine Renovate-Regel für Digest-Updates, **im Trockenlauf belegt**: eine gültige Regel ist keine treffende Regel (#158, searxng-Runde).
**Es gibt keinen Health-Endpunkt.** Gemessen 404 auf `/health`, `/healthz`, `/api/health`, `/download/health`, `/status`, `/ping`. Belegte 200er-Kandidaten für die Probes:
- Port 5008: `GET /api?t=caps`
- Port 5007: `GET /download/api?mode=version&output=json&apikey=x` oder `GET /download/`
## Offen, ausdrücklich ungemessen
Ein Teil des Mediathek-Bestands liegt als **HLS-Playlist** (`application/x-mpegURL`) statt als progressives MP4 vor. MediathekArrs Downloader lädt eine einzelne HTTP-Datei und remuxt sie mit mkvmerge; ob er mit einer m3u8-Playlist umgehen kann, ist **nicht gemessen**. Falls nicht, fallen diese Einträge unabhängig von jeder Geosperre aus. Das gehört als offene Frage in `values.yaml`, nicht als Annahme in die eine oder andere Richtung.
## Zu belegen
1. **Der Chart rendert und installiert**, mit `mediathekarr.enabled: true` und `false`, ohne dass bestehende Installationen sich ändern.
2. **Das Startgate wirkt.** Zeigen, dass der Container nicht vor gluetuns Bereitschaft startet — und dass die Newznab-Suche danach Treffer liefert. Ein grüner Pod ist hier kein Beleg, weil der Fehlerfall grün aussieht.
3. **Die Probes.** Auf einem der belegten 200er-Pfade, nicht auf einem geratenen.
4. **Die Renovate-Digest-Regel im Trockenlauf.**
5. **Härtung wie gemessen**: nicht-root, uid 1000, `readOnlyRootFilesystem: true`.
## Versionsstufe
**Minor** — rein additiv, standardmäßig aus, und der `volumeClaimTemplate` entsteht nur bei aktiviertem Flag, sodass sich für bestehende Installationen nichts ändert. Aktuell `3.0.5+up1.0.0`, also `3.1.0+up1.0.0`. Die `appVersion` des Charts bleibt unberührt: sie ist frei gewählt und an kein Upstream gebunden, alle Images sind in `values.yaml` gepinnt.
Dazu wie üblich: `values.schema.json`, CI-Fixtures unter `ci/freesailarr/`, Renovate-Eintrag, README-Aktualisierung, wo sie repo-weites Verhalten berührt.
Kommentar von jk-cluster-bot am 2026-09-08 (migriert aus GitHub).
Korrektur am Auftragstext: DOWNLOAD_FOLDER_PATH_MAPPING gibt es im gepinnten Image nicht
Der Rumpf dieses Issues verlangt, DOWNLOAD_FOLDER_PATH_MAPPING auf den Pfad zeigen zu lassen, unter dem Sonarr das fertige Verzeichnis sieht. Diese Variable existiert im gepinnten beta-Image nicht.
Sie stammt aus der docker-compose.yml des Upstreams, und die beschreibt den latest-Stand von November 2024 (v0.2.5) — nicht den beta, auf den wir per Digest pinnen. Der Fehler ist meiner: ich habe die Betriebsdaten aus der Compose-Datei übernommen, ohne sie gegen das Image zu prüfen, das wir tatsächlich einsetzen.
Was stattdessen gilt: der beta liest DOWNLOAD_COMPLETE_PATH und DOWNLOAD_INCOMPLETE_PATH.
Die Absicht der Anforderung bleibt unverändert und ist bindend — der Pfad, den MediathekArr als fertig meldet, muss derselbe sein, den Sonarr im Pod sieht, sonst importiert Sonarr schweigend nichts. Umgesetzt wird sie mit den Variablen, die das Image liest, und der gemeldete complete_dir ist gegen die SABnzbd-API zu verifizieren statt anzunehmen.
Das ist zugleich eine Warnung für die nächste Runde an diesem Chart: Die Upstream-Dokumentation beschreibt einen zwei Jahre alten Stand. Was dort steht, gilt für unser Image erst, wenn es am Image belegt ist.
> Kommentar von **jk-cluster-bot** am 2026-09-08 (migriert aus GitHub).
---
## Korrektur am Auftragstext: `DOWNLOAD_FOLDER_PATH_MAPPING` gibt es im gepinnten Image nicht
Der Rumpf dieses Issues verlangt, `DOWNLOAD_FOLDER_PATH_MAPPING` auf den Pfad zeigen zu lassen, unter dem Sonarr das fertige Verzeichnis sieht. **Diese Variable existiert im gepinnten `beta`-Image nicht.**
Sie stammt aus der `docker-compose.yml` des Upstreams, und die beschreibt den `latest`-Stand von November 2024 (v0.2.5) — nicht den `beta`, auf den wir per Digest pinnen. Der Fehler ist meiner: ich habe die Betriebsdaten aus der Compose-Datei übernommen, ohne sie gegen das Image zu prüfen, das wir tatsächlich einsetzen.
**Was stattdessen gilt:** der `beta` liest `DOWNLOAD_COMPLETE_PATH` und `DOWNLOAD_INCOMPLETE_PATH`.
Die Absicht der Anforderung bleibt unverändert und ist bindend — der Pfad, den MediathekArr als fertig meldet, muss derselbe sein, den Sonarr im Pod sieht, sonst importiert Sonarr schweigend nichts. Umgesetzt wird sie mit den Variablen, die das Image liest, und der gemeldete `complete_dir` ist gegen die SABnzbd-API zu verifizieren statt anzunehmen.
Das ist zugleich eine Warnung für die nächste Runde an diesem Chart: Die Upstream-Dokumentation beschreibt einen zwei Jahre alten Stand. Was dort steht, gilt für unser Image erst, wenn es am Image belegt ist.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
MediathekArr (https://github.com/PCJones/MediathekArr) soll als zehnter Container in den freesailarr-Pod. Es täuscht gegenüber Prowlarr einen Usenet-Indexer und gegenüber Sonarr/Radarr einen SABnzbd-Downloader vor und lädt Inhalte per HTTP direkt aus den Mediatheken von ARD und ZDF.
Beide Abnehmer sitzen bereits im Pod und teilen sich gluetuns Netzwerk-Namensraum — sie erreichen MediathekArr über
127.0.0.1, ohne Service, ohne DNS, ohne Ingress-Umweg. Der Zuschnitt passt also, und die Aufnahme ist rein additiv.Alles Folgende ist gemessen, in zwei Runden in Wegwerf-k3d-Clustern, jeweils mit Kontrolllauf über direkten Egress. Wo etwas nicht gemessen ist, steht es ausdrücklich dabei.
Der Geo-Vorbehalt, und warum er den Chart nicht aufhält
Der Tunnel geht per Chart-Vorgabe über Zürich; ARD und ZDF sperren Teile ihres Katalogs außerhalb Deutschlands. Alle Container hängen an gluetuns Namensraum, einen Bypass für einen einzelnen Container gibt es nicht.
Streuprobe, 480 URLs über 12 Kanäle: 104 von 473 direkt ladbaren URLs sind über Zürich gesperrt = 22,0 % (KI etwa 18–26 %). Auf der deutschen Seite kein einziger Fehlschlag. Die Verteilung ist stark ungleich: ONE 97,5 %, ZDFneo 47,5 %, ZDFinfo 37,5 %, Das Erste 20,5 %, ZDF 10,3 %, BR 0 %.
Vollerhebung über sechs konkret nachgefragte Formate, 584 URLs, keine Stichprobe: vier Serien zu 100 % ladbar, eine praktisch (nur ein Trailer gesperrt), eine zu 95 % gesperrt.
Die Ausgangswahl ist ein Deployment-Wert, keine Chart-Eigenschaft. Der Chart entsteht unabhängig davon; er schuldet nur eine ehrliche Dokumentation.
Was dokumentiert wird: das Verfahren, nicht die Momentaufnahme
Der Geo-Marker im CDN-Pfad war über beide Runden hinweg ein perfekter Prädiktor — in der Vollerhebung 584 von 584 Fällen korrekt, keine einzige Fehlklassifikation:
/de/,/geo/de/,/deutschlandweit/,geoavailability_D/weltweit//none/(ZDF)/dach/,deChAt(WDR-Variante)Eine Serientabelle in
values.yamlwäre in einem halben Jahr veraltet. Das Verfahren nicht: wer wissen will, ob seine Sendung über einen fremden Ausgang funktioniert, sieht im Pfad der Medien-URL nach. Das gehört in die Dokumentation, zusammen mit dem Fluchtweg (deutscher Ausgang für den gesamten Stack) und dessen Preis.Die naheliegende Faustregel „Eigenproduktion = weltweit frei" ist belegt falsch und darf so nicht in der Dokumentation landen: eine ARD-Eigenproduktion war gesperrt, eine Lizenzserie offen. Nur der Marker zählt.
Die Falle, die in NOTES.txt gehört
MediathekArr prüft den HTTP-Statuscode nie. A/B gemessen mit identischem NZB:
statusCompletedFailedbytesfail_messagenullnullBei gesperrtem Abruf schreibt es die rund 476 Byte große HTML-Fehlerseite als
.mp4weg und protokolliert „Download completed". Erst mkvmerge verweigert die Datei (Exit-Code 2) und kippt den Status aufFailed.Zwei Konsequenzen, beide dokumentationspflichtig:
fail_messageistnull. Eine Geosperre sieht im Betrieb exakt aus wie ein defekter Server, eine abgelaufene URL oder ein voller Datenträger. Auch der Containerlog nennt die 403 nicht.Completedgemeldet — und dann wandern kaputte Dateien in die Bibliothek. In beiden Messrunden ist das nicht eingetreten (Akamai liefert durchgehend HTML), aber darauf ist kein Verlass.Umsetzung — was gemessen ist
Zwei Ports, nicht einer.
MediathekArrDownloader(SABnzbd-Rolle) auf 5007,MediathekArrServer(Newznab-Rolle für Prowlarr) auf 5008. Die Upstream-Dokumentation nennt nur 5007. Im Pod sind belegt: 9999, 8080, 9696, 8191, 7878, 8989, 5055, 6767 — beide neuen Ports sind frei.Die SABnzbd-API liegt unter
/download/api, nicht unter/api./apiauf 5007 antwortet mit einem Newznab-Validierungsfehler und führt in die Irre.Startgate auf gluetun — der schärfste Punkt. Startet MediathekArr, bevor der Tunnel steht, scheitert der Ruleset-Abruf, und die Instanz lieferte danach über elf Minuten hinweg 0 Treffer auf jede Newznab-Suche, ohne dass ein Retry das reparierte. Mit 75 s Verzögerung: Ruleset ok, Suche identisch zur direkten Instanz. Ohne Startgate ist der Indexer stumm und nichts meldet es — kein Fehler, keine unready Probe, nur leere Suchergebnisse. Die Suche selbst ist nicht geogesperrt (56 Treffer über beide Ausgänge).
Härtung, drei Varianten gemessen. Der auskommentierte Nicht-Root-Block im Dockerfile ist für den
beta-Stand überholt (docker_start.shenthält einen gosu-Pfad). Ergebnis:runAsNonRoot: true+runAsUser: 1000+readOnlyRootFilesystem: true+fsGroup: 1000läuft vollständig durch, inklusive echtem Download und mkvmerge-Remux.Beschreibbar sein müssen:
/app/config— Konfigurations-JSON, gehört auf einen eigenenvolumeClaimTemplatewie bei den anderen Apps./data/mediathek—incomplete/undcomplete/./tmpwar nicht erforderlich (die RO-Variante ohne/tmplief durch). Als billige Absicherung trotzdem sinnvoll — das ist eine Empfehlung, keine Messung./app/downloadswird von der Anwendung gar nicht benutzt, obwohl die docker-compose.yml es als Volume führt. Ihre Vorgaben sind/data/mediathek/incompleteund/data/mediathek/complete.Wohin die Downloads gehören — zu entscheiden, nicht zu raten.
complete/muss auf dem geteilten downloads-Claim liegen, sonst kann Sonarr im selben Pod nichts importieren, undDOWNLOAD_FOLDER_PATH_MAPPINGmuss auf genau diesen Pfad zeigen — eine Abweichung importiert schweigend nichts.incomplete/gehört nicht in einen emptyDir: ein emptyDir zählt gegen das ephemeral-storage-Limit des Containers, und ein großer Download lässt den kubelet den ganzen Pod räumen, mit allen neun anderen Containern. Das ist dieselbe Falle, die in ytdlp-web-player dokumentiert ist.Image per Digest pinnen. Die Tags sind unbrauchbar:
lateststammt vom 12.11.2024 (= v0.2.5), die README empfiehltbeta(zuletzt 15.06.2026). Aufgelöst:Single-Arch, nur
linux/amd64, kein arm64 — gehört als Kommentar an die Stelle, auch wenn der Zielcluster durchgehend amd64 ist. Dazu eine Renovate-Regel für Digest-Updates, im Trockenlauf belegt: eine gültige Regel ist keine treffende Regel (#158, searxng-Runde).Es gibt keinen Health-Endpunkt. Gemessen 404 auf
/health,/healthz,/api/health,/download/health,/status,/ping. Belegte 200er-Kandidaten für die Probes:GET /api?t=capsGET /download/api?mode=version&output=json&apikey=xoderGET /download/Offen, ausdrücklich ungemessen
Ein Teil des Mediathek-Bestands liegt als HLS-Playlist (
application/x-mpegURL) statt als progressives MP4 vor. MediathekArrs Downloader lädt eine einzelne HTTP-Datei und remuxt sie mit mkvmerge; ob er mit einer m3u8-Playlist umgehen kann, ist nicht gemessen. Falls nicht, fallen diese Einträge unabhängig von jeder Geosperre aus. Das gehört als offene Frage invalues.yaml, nicht als Annahme in die eine oder andere Richtung.Zu belegen
mediathekarr.enabled: trueundfalse, ohne dass bestehende Installationen sich ändern.readOnlyRootFilesystem: true.Versionsstufe
Minor — rein additiv, standardmäßig aus, und der
volumeClaimTemplateentsteht nur bei aktiviertem Flag, sodass sich für bestehende Installationen nichts ändert. Aktuell3.0.5+up1.0.0, also3.1.0+up1.0.0. DieappVersiondes Charts bleibt unberührt: sie ist frei gewählt und an kein Upstream gebunden, alle Images sind invalues.yamlgepinnt.Dazu wie üblich:
values.schema.json, CI-Fixtures unterci/freesailarr/, Renovate-Eintrag, README-Aktualisierung, wo sie repo-weites Verhalten berührt.Korrektur am Auftragstext:
DOWNLOAD_FOLDER_PATH_MAPPINGgibt es im gepinnten Image nichtDer Rumpf dieses Issues verlangt,
DOWNLOAD_FOLDER_PATH_MAPPINGauf den Pfad zeigen zu lassen, unter dem Sonarr das fertige Verzeichnis sieht. Diese Variable existiert im gepinntenbeta-Image nicht.Sie stammt aus der
docker-compose.ymldes Upstreams, und die beschreibt denlatest-Stand von November 2024 (v0.2.5) — nicht denbeta, auf den wir per Digest pinnen. Der Fehler ist meiner: ich habe die Betriebsdaten aus der Compose-Datei übernommen, ohne sie gegen das Image zu prüfen, das wir tatsächlich einsetzen.Was stattdessen gilt: der
betaliestDOWNLOAD_COMPLETE_PATHundDOWNLOAD_INCOMPLETE_PATH.Die Absicht der Anforderung bleibt unverändert und ist bindend — der Pfad, den MediathekArr als fertig meldet, muss derselbe sein, den Sonarr im Pod sieht, sonst importiert Sonarr schweigend nichts. Umgesetzt wird sie mit den Variablen, die das Image liest, und der gemeldete
complete_dirist gegen die SABnzbd-API zu verifizieren statt anzunehmen.Das ist zugleich eine Warnung für die nächste Runde an diesem Chart: Die Upstream-Dokumentation beschreibt einen zwei Jahre alten Stand. Was dort steht, gilt für unser Image erst, wenn es am Image belegt ist.