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/src/Flaro.Api/Program.cs

@@ -1,3 +1,4 @@
+using Microsoft.AspNetCore.DataProtection;
 using System.Threading.RateLimiting;
 using Flaro.Api;
 using Flaro.Api.Auth;
@@ -99,6 +100,22 @@ builder.Services.AddSingleton<PackageCoordinator>();
 // ueber den Augenblick. Nach einem Neustart lautet die Antwort: niemand.
 builder.Services.AddSingleton<PlaybackSessions>();
 builder.Services.AddSingleton<Tagebuch>();
+
+// **Die Schlüssel der Datenverschlüsselung gehören ins Volume.**
+//
+// Ohne diese Zeile legt ASP.NET sie unter `~/.aspnet/DataProtection-Keys` ab —
+// also im Container, der beim nächsten Update weg ist. Heute fällt das nicht
+// auf, weil Flaros Sitzungs-Cookie das Gerätetoken selbst trägt und nichts
+// davon verschlüsselt wird. Es fällt erst auf, wenn irgendwann etwas doch
+// darauf baut, und dann sieht es aus wie ein Fehler anderswo.
+//
+// Nebenbei verschwindet damit die Warnung, die bei jedem Start im Protokoll
+// stand und nach einem Problem aussah, das keines war.
+var schluesselOrdner = Path.Combine(pfade.Data, "keys");
+Directory.CreateDirectory(schluesselOrdner);
+builder.Services.AddDataProtection()
+    .PersistKeysToFileSystem(new DirectoryInfo(schluesselOrdner))
+    .SetApplicationName("Flaro");
 builder.Services.AddProblemDetails();
 
 var app = builder.Build();