ScarriffleandClaude Opus 5
532473b1f9
Sichern, Datenbank aufräumen, verwaiste Bilder wegwerfen — alle drei Tage, alle sieben Tage, von selbst. **Der erste Hintergrunddienst in diesem Server, und das mit Bedacht.** An drei Stellen steht sinngemäss, ein eigener Dienst wäre Aufwand ohne Gegenwert, und für das Wegräumen abgelaufener Gerätecodes stimmt das: solche Arbeit hängt an einem Aufruf, der ohnehin kommt. Eine Sicherung hängt an nichts. Sie soll alle drei Tage geschehen, auch wenn niemand etwas anklickt, und dafür gibt es eine Uhr. Alle fünfzehn Minuten eine Frage an eine Tabelle mit einer Handvoll Zeilen; ist nichts fällig — der Normalfall —, kostet es nichts. Der letzte Lauf steht in der Datenbank, nicht im Arbeitsspeicher. Ein Server, der jede Nacht neu startet, sicherte sonst jeden Morgen — oder, bei einem Zähler, der bei null anfängt, nie. Auch ein Fehlschlag wird vermerkt, sonst versuchte der Plan es alle fünfzehn Minuten wieder und eine volle Platte erzeugte ein volles Protokoll. **Die Sicherung ist `VACUUM INTO`, nicht Datei kopieren.** Die Datenbank läuft im WAL-Modus: neben `flaro.db` stehen `-wal` und `-shm`, und wer nur die erste Datei kopiert, bekommt einen Stand von vor Stunden oder einen halben. `VACUUM INTO` schreibt eine vollständige, aufgeräumte Kopie im laufenden Betrieb. Der Zielordner ist einstellbar und geht als gebundener Wert in die Anweisung — eine Einstellung soll keine SQL-Anweisung werden. Die Prüfung verlässt sich nicht darauf, dass eine Datei entstanden ist: sie öffnet die Kopie als Datenbank und zählt die Zeilen. Eine Sicherung, die sich nicht öffnen lässt, ist schlimmer als keine — man verlässt sich darauf und merkt es erst, wenn es zu spät ist. **Bilder nur, wenn verwaist.** Den ganzen Bildspeicher zu leeren gibt es als Knopf und ist gefahrlos, kostet danach aber tausende Abrufe bei TMDB. Hier fliegt nur, worauf kein Titel mehr zeigt — mit einer Stunde Schonfrist, weil ein Bild abgelegt wird, bevor der Verweis darauf gespeichert ist. Ohne diese Frist räumte ein Lauf mitten im Scan genau das weg, was gerade geholt wurde. **Eine eigene Seite „Wartung".** Die drei Kratzplatzzahlen standen unter „Wiedergabe" — dort ist ihr Anlass, aber nicht ihr Thema. Sie ziehen mit um: alles auf dieser Seite ist etwas, das der Server ohne Zutun erledigt, und man sieht es an einem Ort nach. Je Aufgabe steht da, wann sie zuletzt lief und was herauskam, dazu ein Knopf „Jetzt ausführen" — wer gleich etwas Grosses vorhat, will die Kopie jetzt und nicht in drei Tagen. 725 Tests grün, davon elf neue. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Flaro Web
Die Weboberfläche für Rechner, auf denen es keine App gibt — Windows vor allem.
Aufbau
| Ordner | Was |
|---|---|
app/ |
Das Frontend (Vite, TypeScript) |
server/ |
Ein Server ohne Abhängigkeiten, der die Anfragen weiterreicht und die gebauten Dateien ausliefert |
frontend/ |
Die erste Fassung als einzelne Datei. Läuft, wird abgelöst. |
jellyfin-theme/ |
Ein Kleid für Jellyfins eigene Oberfläche — die kleine Lösung von vorher |
Warum ein eigener Server?
Er löst zwei Dinge, an denen die einzelne Datei scheitert, und zwar unabhängig davon, wie gut das Frontend geschrieben ist:
- Herkunft. Anfragen laufen über
/apiund damit über dieselbe Adresse wie die Seite. Kein CORS, auch nicht beim Streamen. - Klartext und Verschlüsselung. Läuft der Medienserver über
httpund die Seite überhttps, blockiert der Browser den Stream. Dagegen kann keine Zeile im Frontend etwas tun — ein Server davor schon.
Nebenbei bleibt der Zugangsschlüssel beim Server, statt im Browser zu liegen.
Betreiben
cd app && npm install && npm run build
cd ../server && FLARO_SERVER=http://jellyfin:8096 node index.js
Dann auf http://localhost:8080. Der Port lässt sich über PORT ändern.
Entwickeln
cd app && FLARO_SERVER=http://jellyfin:8096 npm run dev
Vite übernimmt dabei das Weiterreichen, der eigene Server wird nicht gebraucht.