Jellyfin-Anbindung: Bestand und Sichtungen abgleichen #1

New Issue

2026-09-01T20:50:04Z

florian.wilde commented

2026-09-01 20:50:04 +00:00

Worum es geht

Wer seine Mediathek selbst hostet, pflegt Bestand und Gesehen-Status meist schon in Jellyfin. Beides doppelt zu führen macht auf Dauer niemand — die Stände laufen auseinander. Flimmer kennt seit 0.7.0 „hab ich", weiß aber nicht, was tatsächlich auf dem Server liegt und was dort schon gelaufen ist.

Ziel: Jellyfin einmal verbinden, danach hält sich Flimmer von selbst auf Stand.

Warum das sauber geht

Jellyfin liefert zu jedem Item die ProviderIds mit — darunter die TMDB-ID. Das ist genau der Schlüssel, auf dem Flimmers Katalog ohnehin aufbaut. Es braucht also keine unscharfe Suche über Titel und Jahr:

Jellyfin	Flimmer
Movie, `ProviderIds.Tmdb`	`Title.tmdbId` (Typ `MOVIE`)
Series, `ProviderIds.Tmdb`	`Title.tmdbId` (Typ `SERIES`)
Episode, `ParentIndexNumber` / `IndexNumber`	`Episode.seasonNumber` / `episodeNumber`
`UserData.Played`, `PlayCount`, `LastPlayedDate`	`Watch`

Gelesen wird über
GET /Items?Recursive=true&IncludeItemTypes=Movie,Episode&Fields=ProviderIds&enableUserData=true&userId=…

Zwei Haken, vorab geprüft

UserData fehlt, wenn man nur einen API-Key benutzt (jellyfin#11408). Man bekommt den Bestand, aber ohne Gesehen-Status — und zwar ohne Fehlermeldung. Deshalb: Anmeldung über AuthenticateByName mit echtem Zugangstoken statt eines API-Keys, und die Einrichtung muss aktiv prüfen, dass UserData ankommt. Sonst wundert man sich über einen stillen Leerlauf.
Der Endpunkt zum Zurückschreiben ist umgezogen — von /Users/{userId}/PlayedItems/{itemId} auf /UserPlayedItems/{itemId}?userId=, mit bekannten Problemen bei API-Key-Anmeldung (jellyfin#11501). Deshalb liegt das Zurückschreiben in einer eigenen, abschaltbaren Stufe mit Versionsweiche.

Grenze, die man kennen muss

Jellyfin kennt PlayCount und LastPlayedDate, aber keine Liste einzelner Sichtungen. Rewatch-Durchläufe lassen sich daraus nicht rekonstruieren — übernommen wird der letzte Termin. Ein dreimal geschauter Film erscheint in Flimmers Statistik also mit einem Termin, nicht mit dreien. Das ist eine Eigenschaft der Quelle, kein Umsetzungsfehler; es gehört in die Anleitung.

Ausbaustufen

Stufe 1 — Bestand übernehmen

Verbindung einrichten: Adresse, Anmeldung, Jellyfin-Nutzer auswählen, Testknopf
Bestand einlesen, über TMDB-ID zuordnen
Treffer bekommen owned = true, ownedSource = "Jellyfin"
Titel, die noch nicht in der Bibliothek sind: wahlweise aufnehmen (Status Watchlist) oder nur im Bericht auflisten
Bericht: zugeordnet / nicht zuzuordnen (mit Grund)

Stufe 2 — Sichtungen übernehmen

Gespielte Filme und Episoden werden zu Watch-Einträgen mit LastPlayedDate
Doppelte werden über (userId, episodeId, run) verhindert
Läuft im vorhandenen täglichen Abgleich mit, nur Neues seit lastSyncAt
Einbahnstraße: Jellyfin ergänzt, löscht aber nie etwas, das in Flimmer steht

Stufe 3 — Zurückschreiben (abschaltbar, standardmäßig aus)

Häkchen in Flimmer markiert das Item auch in Jellyfin als gesehen
Versionsweiche für den umgezogenen Endpunkt

Datenmodell

model MediaServerConnection {
  id            String   @id @default(cuid())
  userId        String
  kind          MediaServerKind   // JELLYFIN | EMBY
  baseUrl       String
  token         String            // verschlüsselt mit AUTH_SECRET
  serverUserId  String
  enabled       Boolean  @default(true)
  syncOwned     Boolean  @default(true)
  syncWatched   Boolean  @default(true)
  writeBack     Boolean  @default(false)
  lastSyncAt    DateTime?
}

model MediaServerItem {
  id           String  @id @default(cuid())
  connectionId String
  externalId   String            // Jellyfin-Item-ID
  titleId      String?
  episodeId    String?
  @@unique([connectionId, externalId])
}

Dazu auf Watch ein Feld source (FLIMMER | JELLYFIN) — sonst lässt sich später nicht mehr sagen, was woher kam, und ein Zurücknehmen des Abgleichs wird unmöglich.

MediaServerItem ist kein Luxus: es macht Folgeläufe billig und ist die Voraussetzung fürs Zurückschreiben.

Sicherheit

Der Zugangstoken liegt in der Datenbank und muss mit AUTH_SECRET verschlüsselt werden — im Klartext hat er dort nichts verloren. Selbstsignierte Zertifikate und Adressen im lokalen Netz müssen funktionieren.

Abnahme

Verbindung lässt sich einrichten und testen; fehlt UserData, sagt die Oberfläche das deutlich statt stumm nichts zu tun
Bestand wird zugeordnet, „hab ich" gesetzt, Unzuordenbares landet im Bericht
Gesehene Episoden und Filme erscheinen als Sichtungen mit dem Termin aus Jellyfin
Ein zweiter Lauf legt nichts doppelt an
Der Abgleich läuft im täglichen Job mit und fasst nur Neues an
Nichts, was in Flimmer steht, wird durch den Abgleich gelöscht
Token verschlüsselt abgelegt
Tests laufen ohne echten Jellyfin-Server, gegen nachgebildete Antworten
Grenze zu den Rewatch-Durchläufen steht in docs/ANLEITUNG.md

Aufwand

Stufe 1 und 2 zusammen etwa im Umfang der TMDB-Anbindung: Client, Zuordnung, Job, Einstellungsseite, Tests. Stufe 3 ist klein, braucht aber die Versionsweiche.

Emby spricht praktisch dieselbe API — deshalb ist kind im Datenmodell schon vorgesehen. Plex hätte eine andere Schnittstelle, aber dasselbe Prinzip über die Provider-IDs.

Angelegt auf ausdrücklichen Wunsch direkt in Gitea. Nicht mit einem Nebula-Task verknüpft — der Status müsste dort von Hand nachgezogen werden.

## Worum es geht Wer seine Mediathek selbst hostet, pflegt Bestand und Gesehen-Status meist schon in Jellyfin. Beides doppelt zu führen macht auf Dauer niemand — die Stände laufen auseinander. Flimmer kennt seit 0.7.0 „hab ich", weiß aber nicht, was tatsächlich auf dem Server liegt und was dort schon gelaufen ist. Ziel: Jellyfin einmal verbinden, danach hält sich Flimmer von selbst auf Stand. ## Warum das sauber geht Jellyfin liefert zu jedem Item die `ProviderIds` mit — darunter die TMDB-ID. Das ist genau der Schlüssel, auf dem Flimmers Katalog ohnehin aufbaut. Es braucht also **keine** unscharfe Suche über Titel und Jahr: | Jellyfin | Flimmer | |---|---| | Movie, `ProviderIds.Tmdb` | `Title.tmdbId` (Typ `MOVIE`) | | Series, `ProviderIds.Tmdb` | `Title.tmdbId` (Typ `SERIES`) | | Episode, `ParentIndexNumber` / `IndexNumber` | `Episode.seasonNumber` / `episodeNumber` | | `UserData.Played`, `PlayCount`, `LastPlayedDate` | `Watch` | Gelesen wird über `GET /Items?Recursive=true&IncludeItemTypes=Movie,Episode&Fields=ProviderIds&enableUserData=true&userId=…` ## Zwei Haken, vorab geprüft 1. **`UserData` fehlt, wenn man nur einen API-Key benutzt** ([jellyfin#11408](https://github.com/jellyfin/jellyfin/issues/11408)). Man bekommt den Bestand, aber ohne Gesehen-Status — und zwar ohne Fehlermeldung. Deshalb: Anmeldung über `AuthenticateByName` mit echtem Zugangstoken statt eines API-Keys, und die Einrichtung muss aktiv prüfen, dass `UserData` ankommt. Sonst wundert man sich über einen stillen Leerlauf. 2. **Der Endpunkt zum Zurückschreiben ist umgezogen** — von `/Users/{userId}/PlayedItems/{itemId}` auf `/UserPlayedItems/{itemId}?userId=`, mit bekannten Problemen bei API-Key-Anmeldung ([jellyfin#11501](https://github.com/jellyfin/jellyfin/issues/11501)). Deshalb liegt das Zurückschreiben in einer eigenen, abschaltbaren Stufe mit Versionsweiche. ## Grenze, die man kennen muss Jellyfin kennt `PlayCount` und `LastPlayedDate`, aber **keine Liste einzelner Sichtungen**. Rewatch-Durchläufe lassen sich daraus nicht rekonstruieren — übernommen wird der letzte Termin. Ein dreimal geschauter Film erscheint in Flimmers Statistik also mit einem Termin, nicht mit dreien. Das ist eine Eigenschaft der Quelle, kein Umsetzungsfehler; es gehört in die Anleitung. ## Ausbaustufen ### Stufe 1 — Bestand übernehmen - Verbindung einrichten: Adresse, Anmeldung, Jellyfin-Nutzer auswählen, Testknopf - Bestand einlesen, über TMDB-ID zuordnen - Treffer bekommen `owned = true`, `ownedSource = "Jellyfin"` - Titel, die noch nicht in der Bibliothek sind: wahlweise aufnehmen (Status Watchlist) oder nur im Bericht auflisten - Bericht: zugeordnet / nicht zuzuordnen (mit Grund) ### Stufe 2 — Sichtungen übernehmen - Gespielte Filme und Episoden werden zu `Watch`-Einträgen mit `LastPlayedDate` - Doppelte werden über `(userId, episodeId, run)` verhindert - Läuft im vorhandenen täglichen Abgleich mit, nur Neues seit `lastSyncAt` - **Einbahnstraße:** Jellyfin ergänzt, löscht aber nie etwas, das in Flimmer steht ### Stufe 3 — Zurückschreiben (abschaltbar, standardmäßig aus) - Häkchen in Flimmer markiert das Item auch in Jellyfin als gesehen - Versionsweiche für den umgezogenen Endpunkt ## Datenmodell ```prisma model MediaServerConnection { id String @id @default(cuid()) userId String kind MediaServerKind // JELLYFIN | EMBY baseUrl String token String // verschlüsselt mit AUTH_SECRET serverUserId String enabled Boolean @default(true) syncOwned Boolean @default(true) syncWatched Boolean @default(true) writeBack Boolean @default(false) lastSyncAt DateTime? } model MediaServerItem { id String @id @default(cuid()) connectionId String externalId String // Jellyfin-Item-ID titleId String? episodeId String? @@unique([connectionId, externalId]) } ``` Dazu auf `Watch` ein Feld `source` (`FLIMMER` | `JELLYFIN`) — sonst lässt sich später nicht mehr sagen, was woher kam, und ein Zurücknehmen des Abgleichs wird unmöglich. `MediaServerItem` ist kein Luxus: es macht Folgeläufe billig und ist die Voraussetzung fürs Zurückschreiben. ## Sicherheit Der Zugangstoken liegt in der Datenbank und muss mit `AUTH_SECRET` verschlüsselt werden — im Klartext hat er dort nichts verloren. Selbstsignierte Zertifikate und Adressen im lokalen Netz müssen funktionieren. ## Abnahme - [ ] Verbindung lässt sich einrichten und testen; fehlt `UserData`, sagt die Oberfläche das deutlich statt stumm nichts zu tun - [ ] Bestand wird zugeordnet, „hab ich" gesetzt, Unzuordenbares landet im Bericht - [ ] Gesehene Episoden und Filme erscheinen als Sichtungen mit dem Termin aus Jellyfin - [ ] Ein zweiter Lauf legt nichts doppelt an - [ ] Der Abgleich läuft im täglichen Job mit und fasst nur Neues an - [ ] Nichts, was in Flimmer steht, wird durch den Abgleich gelöscht - [ ] Token verschlüsselt abgelegt - [ ] Tests laufen ohne echten Jellyfin-Server, gegen nachgebildete Antworten - [ ] Grenze zu den Rewatch-Durchläufen steht in `docs/ANLEITUNG.md` ## Aufwand Stufe 1 und 2 zusammen etwa im Umfang der TMDB-Anbindung: Client, Zuordnung, Job, Einstellungsseite, Tests. Stufe 3 ist klein, braucht aber die Versionsweiche. Emby spricht praktisch dieselbe API — deshalb ist `kind` im Datenmodell schon vorgesehen. Plex hätte eine andere Schnittstelle, aber dasselbe Prinzip über die Provider-IDs. --- *Angelegt auf ausdrücklichen Wunsch direkt in Gitea. Nicht mit einem Nebula-Task verknüpft — der Status müsste dort von Hand nachgezogen werden.*

florian.wilde added the in-arbeit label 2026-09-02 07:05:49 +00:00

florian.wilde started working 2026-09-02 07:05:54 +00:00

florian.wilde commented

2026-09-02 07:06:05 +00:00

🤖 Claude Code hat mit der Umsetzung begonnen.

Branch: feat/1-jellyfin-anbindung
Verstanden als: Jellyfin einmal verbinden, danach übernimmt Flimmer Bestand („hab ich") und Sichtungen über die TMDB-ID — als Einbahnstraße, die nur ergänzt und nie löscht.
Geplantes Vorgehen:
- Datenmodell wie beschrieben (MediaServerConnection, MediaServerItem, Watch.source), Token mit AUTH_SECRET verschlüsselt
- Jellyfin-Client mit AuthenticateByName; der Verbindungstest prüft ausdrücklich, ob UserData mitkommt — genau der stille Leerlauf aus Haken 1
- Zuordnung über die TMDB-ID, Bestand und Sichtungen, Bericht über Unzuordenbares; Einhängen in den täglichen Abgleich
- Tests gegen nachgebildete Jellyfin-Antworten, ohne echten Server

Zum Umfang: Ich setze Stufe 1 und 2 um. Die Abnahmeliste deckt genau diese ab — Stufe 3 (Zurückschreiben nach Jellyfin) kommt dort nicht vor, ist laut Beschreibung standardmäßig aus und bräuchte eine Versionsweiche, die ich ohne echten Server nicht verlässlich prüfen kann. Das Feld writeBack lege ich wie beschrieben an, die Logik dahinter bleibt aber leer. Sag Bescheid, wenn Stufe 3 mit hineinsoll — dann als eigener Durchgang, wenn du eine Instanz zum Testen bereitstellen kannst.

Zeiterfassung läuft.

🤖 **Claude Code hat mit der Umsetzung begonnen.** - Branch: `feat/1-jellyfin-anbindung` - Verstanden als: Jellyfin einmal verbinden, danach übernimmt Flimmer Bestand („hab ich") und Sichtungen über die TMDB-ID — als Einbahnstraße, die nur ergänzt und nie löscht. - Geplantes Vorgehen: - Datenmodell wie beschrieben (`MediaServerConnection`, `MediaServerItem`, `Watch.source`), Token mit `AUTH_SECRET` verschlüsselt - Jellyfin-Client mit `AuthenticateByName`; der Verbindungstest prüft ausdrücklich, ob `UserData` mitkommt — genau der stille Leerlauf aus Haken 1 - Zuordnung über die TMDB-ID, Bestand und Sichtungen, Bericht über Unzuordenbares; Einhängen in den täglichen Abgleich - Tests gegen nachgebildete Jellyfin-Antworten, ohne echten Server **Zum Umfang:** Ich setze **Stufe 1 und 2** um. Die Abnahmeliste deckt genau diese ab — Stufe 3 (Zurückschreiben nach Jellyfin) kommt dort nicht vor, ist laut Beschreibung standardmäßig aus und bräuchte eine Versionsweiche, die ich ohne echten Server nicht verlässlich prüfen kann. Das Feld `writeBack` lege ich wie beschrieben an, die Logik dahinter bleibt aber leer. Sag Bescheid, wenn Stufe 3 mit hineinsoll — dann als eigener Durchgang, wenn du eine Instanz zum Testen bereitstellen kannst. Zeiterfassung läuft.

florian.wilde worked for 18 minutes

2026-09-02 07:24:45 +00:00

florian.wilde referenced this issue from a commit

2026-09-02 07:25:00 +00:00

Jellyfin anbinden: Bestand und Sichtungen uebernehmen

florian.wilde referenced a pull request that will close this issue

2026-09-02 07:25:24 +00:00

Feat #1: Jellyfin-Anbindung — Bestand und Sichtungen abgleichen #13

florian.wilde added zu-testen and removed in-arbeit labels 2026-09-02 07:25:29 +00:00

florian.wilde commented

2026-09-02 07:25:45 +00:00

✅ Umsetzung abgeschlossen — bereit zum Testen.

Was geändert wurde

Datenmodell wie beschrieben: MediaServerConnection, MediaServerItem, Watch.source, samt Migration
src/lib/jellyfin.ts (Client) und src/lib/mediaserver.ts (Zuordnung, Bestand, Sichtungen, Bericht)
src/lib/secrets.ts: Token mit AES-256-GCM verschlüsselt, Schlüssel aus AUTH_SECRET
Einstellungen → Medienserver: verbinden, prüfen, abgleichen, Bericht, Schalter je Verbindung
Läuft im täglichen Abgleich mit — dort ohne automatisches Aufnehmen
docs/ANLEITUNG.md: eigener Abschnitt samt der Rewatch-Grenze

Geänderte Dateien

prisma/schema.prisma, prisma/migrations/20260902070826_medienserver/
src/lib/jellyfin.ts, src/lib/mediaserver.ts, src/lib/secrets.ts, src/lib/sync.ts
src/components/settings/MediaServer.tsx, src/app/einstellungen/page.tsx, src/app/actions/settings.ts
tests/fixtures/jellyfin.ts, tests/mediaserver.test.ts, docs/ANLEITUNG.md

Zum Umfang: Stufe 1 und 2 sind drin, Stufe 3 (Zurückschreiben) nicht — sie steht nicht in der Abnahmeliste und bräuchte eine Versionsweiche, die ohne echten Server nicht verlässlich zu prüfen ist. writeBack ist als Feld angelegt.

Geprüft

Elf Tests gegen nachgebildete Antworten; 78 Tests grün, Typecheck sauber. Zusätzlich der ganze Klickweg gegen einen echten HTTP-Server im Produktionsbau:

Schritt	Ergebnis
Verbinden	„Heimserver" erkannt, ✓ Gesehen-Status kommt mit
Token in der Datenbank	verschlüsselt, nicht im Klartext
Abgleich	5 gelesen, 3× „hab ich", 1 nicht zuzuordnen
Sichtungen	2 angelegt, mit dem Termin aus Jellyfin
Zweiter Lauf	nichts doppelt
Server ohne `UserData`	deutliche Warnung statt Stille

Ein Zwischenergebnis war lehrreich: der erste Lauf gegen echte Seed-Daten ergab 0 Sichtungen. Kein Fehler, sondern korrektes Entdoppeln — die Episoden waren im Seed längst abgehakt. Erst mit offenen Inhalten zeigte sich der Import.

So testest du es

git switch feat/1-jellyfin-anbindung
npm run db:migrate — es kommt eine neue Migration
npm run dev, dann Einstellungen → Medienserver
Adresse deines Jellyfin eintragen, Benutzername und Passwort, „Verbinden"
Erwartet: Servername und Versionsnummer erscheinen, dazu ✓ „Der Gesehen-Status kommt mit"
„Jetzt abgleichen" — mit oder ohne Häkchen „Fehlende Titel dabei aufnehmen"
Erwartet: Bericht mit gelesenen Einträgen, gesetzten „hab ich" und übernommenen Sichtungen; Unzuordenbares aufklappbar darunter
Nochmal abgleichen: die Zahlen für Sichtungen und Aufnahmen müssen 0 sein

Aufgewendete Zeit: 00:19
Pull Request: #13

Nach Freigabe: /issue-freigabe 1

✅ **Umsetzung abgeschlossen — bereit zum Testen.**  **Was geändert wurde** - Datenmodell wie beschrieben: `MediaServerConnection`, `MediaServerItem`, `Watch.source`, samt Migration - `src/lib/jellyfin.ts` (Client) und `src/lib/mediaserver.ts` (Zuordnung, Bestand, Sichtungen, Bericht) - `src/lib/secrets.ts`: Token mit AES-256-GCM verschlüsselt, Schlüssel aus `AUTH_SECRET` - Einstellungen → Medienserver: verbinden, prüfen, abgleichen, Bericht, Schalter je Verbindung - Läuft im täglichen Abgleich mit — dort ohne automatisches Aufnehmen - `docs/ANLEITUNG.md`: eigener Abschnitt samt der Rewatch-Grenze **Geänderte Dateien** - `prisma/schema.prisma`, `prisma/migrations/20260902070826_medienserver/` - `src/lib/jellyfin.ts`, `src/lib/mediaserver.ts`, `src/lib/secrets.ts`, `src/lib/sync.ts` - `src/components/settings/MediaServer.tsx`, `src/app/einstellungen/page.tsx`, `src/app/actions/settings.ts` - `tests/fixtures/jellyfin.ts`, `tests/mediaserver.test.ts`, `docs/ANLEITUNG.md` **Zum Umfang:** Stufe 1 und 2 sind drin, **Stufe 3 (Zurückschreiben) nicht** — sie steht nicht in der Abnahmeliste und bräuchte eine Versionsweiche, die ohne echten Server nicht verlässlich zu prüfen ist. `writeBack` ist als Feld angelegt. **Geprüft** Elf Tests gegen nachgebildete Antworten; 78 Tests grün, Typecheck sauber. Zusätzlich der ganze Klickweg gegen einen echten HTTP-Server im Produktionsbau: | Schritt | Ergebnis | |---|---| | Verbinden | „Heimserver" erkannt, ✓ Gesehen-Status kommt mit | | Token in der Datenbank | verschlüsselt, nicht im Klartext | | Abgleich | 5 gelesen, 3× „hab ich", 1 nicht zuzuordnen | | Sichtungen | 2 angelegt, mit dem Termin aus Jellyfin | | Zweiter Lauf | nichts doppelt | | Server ohne `UserData` | deutliche Warnung statt Stille | Ein Zwischenergebnis war lehrreich: der erste Lauf gegen echte Seed-Daten ergab **0 Sichtungen**. Kein Fehler, sondern korrektes Entdoppeln — die Episoden waren im Seed längst abgehakt. Erst mit offenen Inhalten zeigte sich der Import. **So testest du es** 1. `git switch feat/1-jellyfin-anbindung` 2. `npm run db:migrate` — es kommt eine neue Migration 3. `npm run dev`, dann Einstellungen → Medienserver 4. Adresse deines Jellyfin eintragen, Benutzername und Passwort, „Verbinden" 5. Erwartet: Servername und Versionsnummer erscheinen, dazu ✓ „Der Gesehen-Status kommt mit" 6. „Jetzt abgleichen" — mit oder ohne Häkchen „Fehlende Titel dabei aufnehmen" 7. Erwartet: Bericht mit gelesenen Einträgen, gesetzten „hab ich" und übernommenen Sichtungen; Unzuordenbares aufklappbar darunter 8. Nochmal abgleichen: die Zahlen für Sichtungen und Aufnahmen müssen 0 sein **Aufgewendete Zeit:** 00:19 **Pull Request:** #13 Nach Freigabe: `/issue-freigabe 1`

florian.wilde closed this issue

2026-09-02 08:20:01 +00:00

florian.wilde referenced this issue from a commit

2026-09-02 08:20:02 +00:00

Merge #13: Jellyfin anbinden — Bestand und Sichtungen uebernehmen

florian.wilde commented

2026-09-02 08:20:16 +00:00

🚀 Freigegeben und nach main übernommen.

Merge-Commit: 2deb7e1
Pull Request: #13 (gemergt)
Gesamtaufwand: 00:19

Vor dem Merge noch einmal geprüft: Typecheck sauber, 78 Tests grün.

⚠️ Beim Aktualisieren der Instanz kommt eine neue Migration mit (20260902070826_medienserver). Zusammen mit der Passkey-Migration sind es damit zwei, die beim nächsten Update eingespielt werden.

Stufe 3 (Zurückschreiben nach Jellyfin) ist nicht Teil dieser Umsetzung — sie stand nicht in der Abnahmeliste. Das Feld writeBack liegt vorbereitet im Datenmodell.

Issue wird geschlossen.

🚀 **Freigegeben und nach `main` übernommen.**  - Merge-Commit: `2deb7e1` - Pull Request: #13 (gemergt) - Gesamtaufwand: 00:19 Vor dem Merge noch einmal geprüft: Typecheck sauber, 78 Tests grün. ⚠️ **Beim Aktualisieren der Instanz kommt eine neue Migration mit** (`20260902070826_medienserver`). Zusammen mit der Passkey-Migration sind es damit zwei, die beim nächsten Update eingespielt werden. Stufe 3 (Zurückschreiben nach Jellyfin) ist **nicht** Teil dieser Umsetzung — sie stand nicht in der Abnahmeliste. Das Feld `writeBack` liegt vorbereitet im Datenmodell. Issue wird geschlossen.

florian.wilde removed the zu-testen label 2026-09-02 08:20:21 +00:00

florian.wilde referenced this issue

2026-09-02 08:36:19 +00:00

Release 0.8.0 #14

florian.wilde referenced this issue

2026-09-02 09:47:20 +00:00

Jellyfin-Abgleich: unbekannte Titel aus TMDB nachladen statt zu überspringen #16

Sign in to join this conversation.