Zwei Namen für denselben Titel brachen den ganzen Lauf ab

Der Eindeutigkeitsindex aus Punkt 3 stellte die Regel auf, dichtete aber
den einen Weg nicht ab, auf dem sie verletzt wird: der Enricher setzt die
TMDB-Kennung, und sobald zwei Einträge derselben Mediathek dieselbe
bekamen, brach EF die gesamte Speicherung ab — mit "An error occurred
while saving the entity changes", einer Meldung, die den Grund nicht nennt
und den ganzen Scan mitnimmt.

Jetzt wird die Kennung nicht blind gesetzt, sondern vorgemerkt und nach
der Schleife zusammengelegt. Zwei Tests halten den Fall fest: der Anbieter
antwortet auf jede Anfrage mit demselben Film beziehungsweise derselben
Serie, also genau die Lage, die vorher den Lauf zerriss.

Dazu der wahrscheinliche Grund für die siebenhundert Serien: der
Serientitel kam ausschliesslich aus dem Dateinamen. Heisst eine Datei nur
"S01E01.mkv", steht vor der Folgennummer nichts, und der ganze Dateiname
wurde zum Serientitel — zwanzig Folgen ergaben zwanzig Serien namens
"S01E01", "S01E02", und so weiter. Jetzt sagt der Ordner den Namen, wenn
die Datei ihn nicht nennt; der Staffelordner wird dabei übersprungen, sonst
hiesse die Serie "Staffel 1". Plex und Jellyfin lesen ihn seit je so.

Dazu die Prüfliste: Folgen werden nach Serie gebündelt, weil zwanzig neue
Folgen eine Entscheidung sind und nicht zwanzig. Mit Mehrfachauswahl —
anhaken und gemeinsam freigeben oder auf einen Zeitpunkt legen. Und der
Zeitpunkt ist ein datetime-local statt eines Textfelds mit Formvorschrift,
bei dem jeder Tippfehler erst nach dem Absenden auffiel.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

server/Dockerfile

@@ -48,7 +48,7 @@ FROM mcr.microsoft.com/dotnet/aspnet:10.0 AS runtime
 ARG TARGETARCH
 RUN apt-get update \
  && apt-get install -y --no-install-recommends \
-      ffmpeg libva2 libva-drm2 mesa-va-drivers \
+      ffmpeg libva2 libva-drm2 mesa-va-drivers curl \
  && if [ "$TARGETARCH" = "amd64" ]; then \
       apt-get install -y --no-install-recommends intel-media-va-driver i965-va-driver; \
     fi \
@@ -67,10 +67,13 @@ RUN mkdir -p /config /cache /transcode && chown -R 1000:1000 /config /cache /tra
 # braucht weder ein Startskript noch root im Container.
 USER 1000:1000
 
+# **Kein eigenes ASPNETCORE_URLS.** Das Basisimage setzt seit .NET 8 selbst
+# ASPNETCORE_HTTP_PORTS=8080; beides zusammen ergab bei jedem Start die
+# Warnung „Overriding HTTP_PORTS '8080'". Zwei Wege zum selben Port sind
+# einer zu viel.
 ENV FLARO_DATA=/config \
     FLARO_CACHE=/cache \
     FLARO_TRANSCODE=/transcode \
-    ASPNETCORE_URLS=http://+:8080 \
     DOTNET_gcServer=0
 
 WORKDIR /app
@@ -78,6 +81,20 @@ COPY --from=build /app .
 COPY --from=web /web/dist ./wwwroot
 
 EXPOSE 8080
+
+# **Eine Gesundheitsprüfung, die den Server fragt — nicht die Laufzeit.**
+#
+# Ohne sie weiss Docker nur, dass ein Prozess läuft. Die Oberfläche eines NAS
+# zeigt dann minutenlang „wird bereitgestellt", während der Server längst
+# antwortet, und niemand kann unterscheiden, ob er noch wandert oder hängt.
+#
+# `/health` und nicht `dotnet --info`: letzteres sagt nur, dass die Laufzeit
+# da ist, und das war sie auch, als der Server noch migrierte.
+#
+# 60 Sekunden Anlaufzeit, weil die Migrationen beim ersten Start einer
+# gefüllten Datenbank länger brauchen als ein Startvorgang sonst.
+HEALTHCHECK --interval=30s --timeout=5s --start-period=60s --retries=3 \
+    CMD curl -fsS http://localhost:8080/health || exit 1
 VOLUME ["/config", "/cache", "/transcode"]
 
 ENTRYPOINT ["dotnet", "Flaro.Api.dll"]