f98b995050ff388f001fc8bb9dc9630ea10d6581
3
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
f98b995050 |
Beiwerk im Medienordner, und eine Zuordnung lässt sich korrigieren
Plakate, Hintergründe und NFO-Dateien landen jetzt neben dem Film — und eine
falsche Zuordnung lässt sich richtigstellen, ohne dass der nächste Scan sie
wieder überschreibt.
Der Untergang (2004)/
├── Der Untergang (2004).mkv
├── poster.jpg
├── fanart.jpg
└── movie.nfo
Bei Serien liegt `tvshow.nfo` eine Ebene über dem Staffelordner, je Folge
kommen NFO und Standbild daneben. Liegen mehrere Filme in einem Ordner, heisst
das Beiwerk `Titel (Jahr)-poster.jpg` — sonst überschrieben sie sich
gegenseitig.
**Die Erlaubnisliste ist der ganze Schutz.** Damit das geht, muss die
Medieneinhängung ohne `:ro` auskommen, und damit könnte der Server dort alles
anstellen. Dass er es nicht tut, hängt an `SidecarNames`: sechs Arten von
Datei, nichts sonst. Ein Name, der nicht daraufsteht, wirft — laut, nicht
still, denn das wäre ein Fehler im Programm. Mediendateien werden nie
geändert, umbenannt oder gelöscht; es gibt keine Stelle, die das könnte.
Geprüft an echten Dateien, einschliesslich der Versuche mit `../`, mit
absoluten Pfaden und mit einer Mediendatei als Ziel.
Standardmässig **aus**. In fremde Medienordner zu schreiben ist nichts, was
ein Server ungefragt tun sollte.
**Gelesen wird auch ohne Schreiberlaubnis.** Eine vorhandene NFO ist eine
Zuordnung, die jemand getroffen hat — Halo nimmt sie und sucht gar nicht
erst. Dasselbe gilt für Ordnernamen der Form `[tmdbid-613]`. Halo liest sie
und benennt **nichts** um: Umbenennen ist der einzige Eingriff, der eine
Bibliothek wirklich zerlegen kann.
Nebenbei: eine NFO aus dem Medienordner hat Halo nicht geschrieben. DTDs sind
beim Lesen abgeschaltet — eine untergeschobene Datei mit externer Entität
könnte sonst den Server dazu bringen, `/config/halo.db` einzulesen und als
Titel auszuliefern. Mit Prüfung.
---
**Der Fehler, den erst der echte Lauf zeigte** — und er ist die zweite
Auflage eines schon einmal behobenen:
Nach der Korrektur stand im Ordner „Dark (2017)", in der Datenbank aber 2004.
Der nächste Scan suchte nach *(Dark, 2017)*, fand nichts, legte den Film neu
an und löschte den korrigierten als verwaist. Überlebt hat die Zuordnung nur,
weil sie in der NFO stand — das System hat sich selbst gerettet, aber der
Eintrag war ein anderer und das Jahr wieder falsch.
Dieselbe Klasse wie bei `ParsedTitle`: zugeordnet wurde über einen Wert, den
die Metadatenquelle verändert. Jetzt gibt es `ParsedYear`, und das ändert sich
nie. Mit Prüfung, die genau diesen Ablauf festhält.
---
Dazu von TMDB: die IMDb-Kennung wird nachgeschlagen, damit sie in der NFO
steht — wer später auf ein anderes Werkzeug wechselt, findet denselben Titel
wieder, auch wenn das TMDB gar nicht kennt.
308 Tests grün. Im Container nachgewiesen: Zuordnung falsch, korrigiert,
zweiter Scan — derselbe Eintrag, dieselbe Kennung, Jahr bleibt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
|
||
|
|
79b6001f86 |
Metadaten ohne Einrichtung — mit Lese-Token statt API-Schlüssel
Halo bringt einen TMDB-Zugang mit. Wer den Server startet, bekommt Titel, Beschreibungen und Plakate, ohne irgendwo ein Konto anzulegen. Am echten Dienst nachgewiesen: „Der Untergang" (2004) mit deutscher Beschreibung, „Blade Runner 2049" (2017), Plakate als JPEG aus Halos eigener Ablage. **Warum überhaupt die Frage stand.** Jellyfin liefert ebenfalls einen Schlüssel mit — fest im Quellcode, offen im Repository, Konstante `ApiKey` in `TmdbUtils.cs`. Ein Abkommen mit TMDB dazu liess sich nicht belegen: deren Bedingungen erwähnen das Teilen von Schlüsseln mit keinem Wort, und die einzige Äusserung eines Moderators zu genau dieser Frage im TMDB-Forum ging nicht darauf ein, sondern wies nur darauf hin, dass Missbrauch zur Sperrung führt. Geduldet also, nicht gesegnet. Deshalb **mit Ausweg**: wer einen eigenen Zugang hinterlegt, benutzt den. Würde der mitgelieferte je gesperrt, steht damit nicht jede Installation still. **Ein Lese-Token, kein API-Schlüssel.** TMDBs eigene Dokumentation bestätigt, dass er auch an den v3-Endpunkten gilt. Zwei Gründe, und beide zählen bei einem Zugang, der öffentlich im Repo steht: er kann nur lesen, und er geht als `Authorization`-Kopfzeile hinaus statt als `?api_key=` in der Adresse — und eine Adresse steht in jedem Zugriffsprotokoll und jedem Reverse Proxy. Der ältere Schlüssel wird weiterhin angenommen; er kann nur in die Adresse. **Der Hinweis auf TMDB ist Bedingung.** Logo und ein fester Satz, so verlangt es deren Lizenz. `system/info` liefert beides ohne Anmeldung, damit ein Client es auch auf dem Anmeldebildschirm zeigen kann. Das fehlte bisher. --- **Zwei Funde, beide nur durch einen echten Lauf sichtbar:** *„Dark" wurde zu „Dark Shadows" von 1966.* TMDB sortiert nach Beliebtheit, und ohne Jahresangabe führt das in die Irre. Jetzt sticht ein Treffer mit genau diesem Namen den beliebteren — danach: „Dark" (2017), deutsche Beschreibung, Folgentitel „Geheimnisse" und „Lügen". Nur bei Gleichheit, nicht bei Ähnlichkeit: eine eigene Bewertung wäre TMDBs Rangfolge nachgebaut, mit weniger Daten. *Die Tests griffen plötzlich übers Netz zu.* Sobald ein Schlüssel mitgeliefert wird, fragt jeder Scan wirklich bei TMDB nach — und prompt hiess „Der Untergang" im Test „Downfall", weil die Voreinstellung Englisch ist. Genau das, was ein Testwerk nicht tun darf: am WLAN hängen und an fremden Daten. Der Anbieter ist jetzt für alle Tests abgeschaltet, ausser ein Test schiebt ausdrücklich einen eigenen nach. 238 Tests grün, keiner davon geht ins Netz. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |
||
|
|
acfe2668a8 |
Stufe 2b: Metadaten von TMDB — und ein Testlauf, der 19-mal schneller ist
Titel, Beschreibungen und Bilder kommen jetzt von TMDB. Dazu zwei Fehler, die erst das Zusammenspiel zeigte. **Der Anbieter steckt hinter einer Schnittstelle, und das ist kein Vorrat für einen zweiten.** Es geht darum, dass alles, was darauf aufbaut, *ohne Netz und ohne Schlüssel* prüfbar bleibt. Ein Projekt, dessen Tests einen fremden Dienst brauchen, hat am Ende keine Tests: sie scheitern, wenn das WLAN hakt, und irgendwann schaltet sie jemand ab. **Ein Fehlschlag bei TMDB ist kein Abbruch.** Kein Netz, Kontingent erschöpft, ein Anmeldeportal im Hotel-WLAN, das HTML mit Status 200 schickt — in allen Fällen bleibt der Titel beim Dateinamen und der Scan läuft durch. Die eine Ausnahme ist ein zurückgewiesener Schlüssel: „nichts gefunden" und „dein Schlüssel ist falsch" sehen in der Mediathek gleich aus, und ohne diese Unterscheidung sucht jemand stundenlang. Der Schlüssel steht im Scanbericht. **Der Schlüssel kommt nie wieder heraus.** Abgefragt wird nur, ob einer da ist — sonst gäbe die Oberfläche jedem Angemeldeten das TMDB-Kontingent des Betreibers in die Hand. Geprüft, dass er nicht einmal versehentlich im Antwortkörper steht. **Bilder holt die App bei Halo, nicht bei TMDB.** Sonst bräuchte sie Internet für ein Plakat, das zehn Zentimeter weiter auf der Platte liegt — und TMDB erführe, wer wann was ansieht. Der Schlüssel ist der Hash der Quelladresse, also lädt dasselbe Plakat nie zweimal. Dass daraus kein Weg ins Dateisystem wird, ist eigens geprüft: ohne die Formprüfung wäre `/api/v1/images/../../config/halo.db` ein Weg, die Datenbank samt aller Token-Fingerabdrücke herunterzuladen. --- **Der erste Fehler: nach dem Eintragen der Metadaten legte der nächste Scan den Film erneut an.** Zugeordnet wurde über den Titel — und den hatte TMDB gerade von „The Matrix" auf „Matrix" geändert. Beim übernächsten Lauf dasselbe noch einmal. Das ist die Sorte Fehler, die man erst nach Wochen bemerkt, wenn jeder Film fünfmal dasteht. Jetzt gibt es `ParsedTitle`: den Titel aus dem Dateinamen, der sich nie ändert, und nur der entscheidet beim Zuordnen. **Der zweite Fehler kostete 15 Minuten je Testlauf.** Zwei Tests löschen die Pfadvariablen, um den Rückfall auf die Voreinstellung zu prüfen — und liessen sie gelöscht zurück. Jeder danach gestartete Testserver fiel dann auf `<Projektverzeichnis>/data` zurück, und Dutzende Server teilten sich **eine** SQLite-Datei, auf die sie der Reihe nach warteten. Dazu wartete jeder Host beim Herunterfahren die vollen fünf Sekunden. Gefunden durch Halbieren, nicht durch Raten: einzeln war jede Testklasse schnell, zusammen nicht. Der Beweis lag am Ende als leeres Verzeichnis `src/Halo.Api/data` auf der Platte. **15 Minuten 32 → 49 Sekunden.** 180 Tests grün. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> |