ScarriffleandClaude Opus 5
f98b995050
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>
74 lines
2.8 KiB
YAML
74 lines
2.8 KiB
YAML
# Beispiel, kein fertiger Betrieb. Jeder Pfad hier gehört angepasst.
|
|
#
|
|
# Übernommen aus einem laufenden Plex-Container auf einem UGREEN-NAS — die
|
|
# Form ist bewährt, die Werte sind es nur dort.
|
|
|
|
services:
|
|
halo:
|
|
image: ghcr.io/scarriffle/halo:latest
|
|
container_name: halo
|
|
restart: unless-stopped
|
|
|
|
ports:
|
|
- "8080:8080"
|
|
|
|
environment:
|
|
- TZ=Europe/Zurich
|
|
|
|
# Plakate, Hintergründe und NFO-Dateien neben den Film legen.
|
|
#
|
|
# **Standardmässig aus.** Dafür muss die Medieneinhängung unten ohne
|
|
# `:ro` stehen — und damit kann der Server dort im Grundsatz schreiben.
|
|
# Dass er nur Beiwerk anlegt, hängt an einer Erlaubnisliste im Code
|
|
# (`SidecarNames`): poster.jpg, fanart.jpg, logo.png, movie.nfo,
|
|
# tvshow.nfo, je Folge eine NFO und ein Standbild. Alles andere lehnt er
|
|
# ab, auch Mediendateien — die werden nie geändert, umbenannt oder
|
|
# gelöscht.
|
|
#
|
|
# Der Gewinn: dein Bestand wird tragbar. Ein Umzug, ein Neuaufbau der
|
|
# Datenbank oder ein zweiter Server finden Zuordnungen und Bilder wieder.
|
|
- HALO_WRITE_SIDECARS=true
|
|
|
|
# Wem die Dateien auf dem Wirt gehören. 1000:1000 ist die Voreinstellung
|
|
# im Image; wer andere Kennungen hat, trägt sie hier ein — `id -u` und
|
|
# `id -g` auf dem Wirt sagen, welche.
|
|
user: "1000:1000"
|
|
|
|
volumes:
|
|
# Datenbank und Einstellungen. **Das Einzige, was gesichert werden muss.**
|
|
- /volume4/CRITICAL/Docker/Halo/config:/config
|
|
|
|
# Bilder und Zwischenstände. Darf verlorengehen, baut sich neu auf.
|
|
- /volume4/CRITICAL/Docker/Halo/cache:/cache
|
|
|
|
# Kratzplatz fürs Umrechnen. Am besten auf eine SSD und nicht dorthin,
|
|
# wo die Medien liegen — hier wird viel und kurzlebig geschrieben.
|
|
- /volume1/Transcode:/transcode
|
|
|
|
# Die Medien.
|
|
#
|
|
# **Ohne `:ro`, weil HALO_WRITE_SIDECARS oben an ist.** Wer das nicht
|
|
# will, setzt die Variable auf `false` und hängt wieder mit `:ro` ein —
|
|
# dann bleiben Bilder und Metadaten nur in Halos Cache, und der Bestand
|
|
# ist gegen jeden Zugriff des Servers geschützt.
|
|
#
|
|
# Transcode-Zwischenstände kommen hier **nie** her; die liegen auf dem
|
|
# eigenen Volume darüber.
|
|
#
|
|
# Was hier eingehängt wird, ist der Pfad, den du später in der Oberfläche
|
|
# als Bibliothek anlegst — also `/media`, nicht `/volume4/MYFLIX`.
|
|
- /volume4/MYFLIX:/media
|
|
|
|
# Hardware fürs Umrechnen. Intel wie AMD laufen über VAAPI an derselben
|
|
# Stelle. Fehlt die Zeile, rechnet Halo in Software — langsamer, aber es
|
|
# läuft. Zum blossen Umpacken wird sie ohnehin nicht gebraucht.
|
|
devices:
|
|
- /dev/dri:/dev/dri
|
|
|
|
healthcheck:
|
|
test: ["CMD", "dotnet", "--info"]
|
|
interval: 30s
|
|
timeout: 5s
|
|
retries: 3
|
|
start_period: 20s
|