235 Commits
Author SHA1 Message Date
HitonabiandClaude Fable 5 d21332e3c7 docs: SAVEPOINT — Einstellungen-Karten und Version 5.1.0
Ampel / ampel (push) Successful in 1m44s
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-31 22:10:10 +02:00
HitonabiandClaude Fable 5 b64ddf5f06 feat(v5): Einstellungen als erklärende Karten-Seite — Version 5.1.0
Ampel / ampel (push) Successful in 1m35s
Der Einstellungs-Tab im Kino-Mix, statt magerer Feldliste: links eine
Sektions-Navigation, rechts Karten mit je einem Satz Einordnung —
Ablage (mit Struktur-Vorschau Filme/Musik/ISO/roh), Kompression
(Schalter, gemessene Encoder als Badges, Empfehlungs-Erklärung),
Metadaten (Key-Quellen im Klartext, hinterlegt/fehlt-Punkte), MakeMKV
(eigene Karte: Live-Schlüsselstand, Update- und Prüf-Knopf,
Dauerlizenz), Medienserver, Programm (Schalter, Update-Stand,
Versionszeile) und Werkzeuge — NEU mit den drei „Eigener
Pfad'-Feldern (werkzeug.*, vom Katalog seit je unterstützt, bisher
ohne UI).

Dazu: #einstellungen/#bibliothek als Startanker (RIPPY_START_BEREICH),
RIPPY_SMOKE_WARTE_MS für Bild-Beweise, die auf späte Kern-Antworten
warten (Einstellungen+Encoder-Messung kommen nach den 750 ms).
Version 5.1.0 — erste Fassung ohne Vorab-Suffix, der Bau erzeugt
damit erstmals latest.yml (der Update-Kanal aus § 6.8).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-31 22:06:38 +02:00
HitonabiandClaude Fable 5 c12b1be448 docs: SAVEPOINT — Kino-Mix-Design durchgängig eingebaut
Ampel / ampel (push) Successful in 1m28s
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-31 21:56:39 +02:00
HitonabiandClaude Fable 5 b9de2ba729 feat(v5): Kino-Mix-Design durchs ganze Fenster (Commander-Entscheid)
Ampel / ampel (push) Successful in 1m54s
Der auf dem Design-Canvas gewählte Mix aus Kinosaal und Schaltpult,
durchgängig über Übersicht, Einstellungen, Bibliothek, Erst-Einrichtung
und Dialoge: warmes Bühnen-Schwarz mit Saallicht und Filmkorn, Gold als
Akzent, Poster mit Goldkante, Plakat-Titel (Bricolage Grotesque) — dazu
die Schaltpult-Präzision: REC-Glühen bei laufendem Rip, Info-Kacheln
(Medium/Größe/Erkennung/Preset inkl. der echten Preset-Kette),
20-Segment-Aussteuerungsanzeige mit großer Mono-Prozentzahl,
Mono-Protokoll, LED-Systemleiste statt Status-Kacheln (Systemfehler
werden zur roten Karte, R4). Schriften gebündelt via fontsource
(OFL, bau/lizenzen) — zur Laufzeit lädt Rippy nichts aus dem Netz.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-31 21:54:23 +02:00
HitonabiandClaude Fable 5 98ca2855e9 docs: SAVEPOINT — MakeMKV-Selbst-Update und Kino-Look
Ampel / ampel (push) Successful in 1m27s
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-31 20:20:13 +02:00
HitonabiandClaude Fable 5 d5ea48cd1e feat(v5): MakeMKV-Selbst-Update (§ 9) und Kino-Look fürs Fenster
Ampel / ampel (push) Successful in 1m34s
Update-Strecke: Quellenkette (Hersteller 525 → Forum → Archiv, höchste
gewinnt, 31.08. nachgemessen), MZ- + Versions-Ressourcen-Prüfung
(GuinpinSoft inc, gemessen), Download in .neu, Start übers Haupt
(shell/UAC — Installer hängt bewusst NICHT an der Leine), Warte-Poll
bis die EXE-Version wechselt, dann Schlüssel neu prüfen. Ehrlicher
Zweig: installierte == neueste Fassung → kein sinnloser Download.

Fenster: Laufwerks-Kachel als Bühne (TMDb-Backdrop, Poster, Beschreibung,
Phasen-Label, Restzeit, aufklappbares Protokoll), Bibliothek als
Poster-Regal (DB-Schema 3: poster_pfad, Migration), Schlüssel-Karte mit
Update-Knopf und Beschaffungs-Balken, MakeMKV-Version als Badge.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-31 20:18:08 +02:00
HitonabiandClaude Fable 5 5622d8e47d docs: SAVEPOINT — erster Commander-Test, drei Funde behoben
Ampel / ampel (push) Successful in 1m28s
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 20:23:55 +02:00
HitonabiandClaude Fable 5 c5dd90cc18 fix(v5): Die drei Funde aus dem ersten Commander-Test
Ampel / ampel (push) Successful in 1m25s
FUND 1 — 'Key korrekt, aber als ungueltig angezeigt': Stimmt beides.
Live gemessen: Der aktuelle Forum-Key ist in Ordnung, aber MakeMKV
1.18.4 ist ZU ALT fuer ihn — makemkvcon meldet 5020 UND 5021 zusammen,
und die alte Pruefung brach beim ersten Code ab und beschuldigte den
Schluessel. urteilAusAusgabe sammelt jetzt ALLE Codes (5021 schlaegt
5020, MakeMKV-Version aus MSG 1005 wird mitgelesen) und die Kachel
sagt den wahren Satz: 'Der Key ist in Ordnung — MakeMKV 1.18.4 ist zu
alt. Rippy hat ihn entfernt, damit der Beta-Modus weiterlaeuft (Rips
klappen trotzdem). Abhilfe: MakeMKV aktualisieren.' Neues Feld
weiterBetrieb: Beta-Modus ist GELB (Warnung), nicht rot. Test mit der
echten Ausgabe als Fixture.

FUND 2 — 'Komprimieren auf CPU statt GPU': Der Default 'H.265 MKV
1080p30' ist ein CPU-Preset. Neue GEMESSENE Empfehlung
(gemeinsam/preset-empfehlung.ts): aus den echten Backends und der
echten Preset-Liste des eigenen HandBrake — VCN vor NVENC vor QSV vor
CPU, nur Namen die WIRKLICH in der Liste stehen, HandBrake-Presets
deckeln die Aufloesung nur (DVD bleibt SD). Kette: eigene Wahl >
allgemeines Preset > Empfehlung > CPU-Default. Auf dem Commander-PC:
bluray/dvd -> 'H.265 VCN 1080p', uhd -> 'H.265 VCN 2160p 4K'. Die
Preset-Auswahl zeigt 'automatisch: <Empfehlung>' als Leer-Option.

FUND 3 — 'keine Alternative waehlbar': 'Aendern …'-Dialog an der
Laufwerks-Kachel (§ 5 Schritt 4): TMDb-Suche (Film + Serie, mit
Postern), Klick uebernimmt — Nutzer-Wahl gilt als 100 % und steuert
Ablage-Ordner, NFO und Poster. Neue Nachrichten metadaten-suchen /
zuordnung-setzen / metadaten-vorschlaege.

Dazu: Poster in der Laufwerks-Kachel (CSP um image.tmdb.org
erweitert), Restzeit-Schaetzung am Fortschritt.

192 Tests gruen, Smoke gruen.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 20:20:10 +02:00
HitonabiandClaude Fable 5 0e1c927e7b docs: SAVEPOINT — Rippy v5 komplett (W-0 bis W-7), Beweise und offene Hand-am-Geraet-Punkte
Ampel / ampel (push) Successful in 1m21s
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 19:20:40 +02:00
HitonabiandClaude Fable 5 9fa3df500d feat(v5): Etappe W-6 — Setup, Selbst-Update, Erst-Einrichtung, Lizenzen
Ampel / ampel (push) Successful in 1m22s
electron-builder → NSIS: EIN RippySetup-<version>.exe, pro Benutzer,
ohne Adminrechte, eigenes Icon (PNG-basiertes ICO selbst gebaut).
extraResources: die MITGELIEFERTEN Werkzeuge (HandBrakeCLI GPL-2,
flac.exe MIT libFLAC.dll — die Ohne-DLL-Falle aus § 9) samt
Lizenztexten und Quellverweisen (bau/lizenzen, Entscheid 9); vendor/
liegt nicht im Git (74 MB), Befuellung steht in BAUEN.md. Der Kern
findet die mitgelieferten Werkzeuge ueber RIPPY_VENDOR (resourcesvendor) VOR allen anderen Suchwegen.

haupt/update.ts (§ 6.8): electron-updater gegen das oeffentliche Gitea
(festes Tag 'aktuell' als Rueckfallebene, Entscheid 6) — NUR https
(http wird ABGELEHNT; Regel-Tests), NIE waehrend eines Rips (der Haupt
kennt die aktiven Vorgaenge), Fehlschlaege still aber ablesbar
(letzte erfolgreiche Pruefung im Status), installiert beim naechsten
Start. haupt/autostart.ts: HKCU-Run ueber app.setLoginItemSettings,
Toggle in den Einstellungen. Erst-Einrichtung (§ 6.9) im Programm:
5 Schritte, NUR ein Fehler blockiert (kein Laufwerk = Warnung,
MakeMKV-Pflicht mit Klartext-Weg).

GEBAUT UND GEMESSEN (30.08.2026):
- dist-setup/RippySetup-5.0.0-w0.exe — 130,8 MB, SHA-256
  07D39D6BAB74A47C21AA53D847FB5A5DB6990AE9FA1CBC7BE814B51050883115,
  plus .blockmap.
- MESSUNG: Die Update-Auskunft heisst bei Vorab-Versionen nach dem
  KANAL (w0.yml) — erst ein Release ohne Suffix erzeugt latest.yml
  (steht jetzt in BAUEN.md).
- Das GEPACKTE Programm (win-unpacked, asar + resources) besteht den
  Smoke: SMOKE OK, und der Screenshot zeigt die Erst-Einrichtung —
  das Bild eines frischen Rechners.

Bewusst offen (SAVEPOINT): die automatische MakeMKV-Beschaffung
(beschaffen.ts — Download+Installer-Start braucht einen Live-Test);
das Setup NENNT den Weg klar. 185 Tests gruen.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 19:03:40 +02:00
HitonabiandClaude Fable 5 2d9cef22b3 feat(v5): Etappe W-7 — Audio-CD, ISO-Backup, MakeMKV-Schluesselkette
Ampel / ampel (push) Successful in 1m20s
rip/audiocd.ts: die Rechnungen PUR (MSF→LBA mit den 150 Vorlauf-Frames,
TOC-Zerlegung mit Lead-Out-Pflicht und Daten-Track-Bit, 27-Sektoren-
Bloecke unter der 64-KB-Treibergrenze, RAW_READ_INFO mit DiskOffset in
2048ern OBWOHL der Sektor 2352 hat, WAV-Kopf, AC/DC-sichere Namen).
metadaten/musicbrainz.ts: DiscID nach musicbrainz.org-Rechnung — gegen
die ECHTE AC/DC-Kennung getestet (3KVSIWn_…), Vorlauf wird beim Melden
wieder HINZUgerechnet; Tags je Spur mit Bindewort-Kuenstlern.
laufwerk/disc.ts: audioToc + audioSpurLesen ueber die LaufwerkApi.

rip/iso.ts (§ 6.4): 1:1-Abbild fuer unbekannte Discs — async (ein
33-GB-Abbild darf den Kern nicht blockieren), sektor-ausgerichtet,
unvollstaendig heisst FEHLER mit Byte-Zahlen, nie Schoenfaerberei.

werkzeuge/schluessel.ts (§ 9.1): Dauerlizenz schlaegt Forum-Beta-Key
(t=1053, T-Muster aus makemkv_key.py), Ablage in HKCU ueber reg.exe
(kein zweiter koffi-Ort), GEFRAGT statt gerechnet (makemkvcon info
disc:9999, MSG 5020/5021/5051), abgelehnter Key wird ZURUECKGENOMMEN
(schlimmer als keiner: 0 Titel, kein Laufwerk), app_UpdateEnable nur-
wenn-fehlt (der 4K-Schluesselkanal). Kern prueft beim Start und
taeglich; Dashboard-Kachel zeigt Stand + letzten Pruefzeitpunkt;
Dauerlizenz-Feld in den Einstellungen.

Pipeline verzweigt nach Disc-Typ: cd → Sektoren→WAV→FLAC mit
MusicBrainz-Tags (Ordner 'Kuenstler - Album', ohne Treffer ehrlich
'Track NN'), unknown → ISO. Bibliothek-Eintraege fuer beide.

181 Tests gruen, Smoke gruen.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 18:56:07 +02:00
HitonabiandClaude Fable 5 c78ff22ab7 feat(v5): Etappe W-5 — Oberflaeche: Tray, Toasts, Taskleiste, Einstellungen, Bibliothek
Ampel / ampel (push) Successful in 1m23s
haupt/: tray.ts (Symbol mit Zustand, Kontextmenue, Fenster zu = weiter-
laufen, Beenden nur noch gewollt), Windows-Toasts bei Disc erkannt /
fertig / Fehler (Klick holt das Fenster), Taskleisten-Fortschritt
(setProgressBar, Fehlermodus), echter Windows-Ordnerdialog per IPC.
Eigenes Icon (bau/icon.png + tray.png, Disc-Optik).

Kern: Einstellungen lesen/schreiben NUR ueber die eine Quelle (§ 6.7,
Whitelist der Schluessel), Werkzeug-Auskunft (Katalog + gemessene
HandBrake-Presets/Backends), Bibliothek in db.ts (Schema v2 —
fingerprint, Titel, Groesse, Ort, Dauer), Duplikat-Erkennung beim
Einlegen (§ 6.6: 'schon einmal gerippt am …' als disc-info + Toast),
Pipeline traegt fertige Vorgaenge ein.

Fenster: drei Bereiche (Uebersicht / Einstellungen / Bibliothek).
Einstellungen: Ablage mit Durchsuchen-Dialog, Kompression je Disc-Typ
(Preset-Liste VOM eigenen HandBrake gemessen, 'NICHT komprimieren'
waehlbar), Sprachlisten, TMDb/OMDb-Keys, Medienserver, Werkzeug-Stand
mit Klartext (gefunden/fehlt + Folgen). Bibliothek als Tabelle.

Der Smoke-Screenshot zeigt nebenbei den Ernstfall in schoen: Das
Laufwerk ist nach dem rc11-Vorfall inzwischen auch am Storage-Stack in
'unknown' gekippt — und die Kachel zeigt den ZUGRIFFS_GRUENDE-Klartext
samt Abhilfe statt eines stummen Zustands.

165 Tests gruen, Smoke gruen.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 18:47:39 +02:00
HitonabiandClaude Fable 5 a9fa8fa2d8 fix(v5): discmerkmale auf Plattform-Pfade — dritte Lehre desselben Musters
Ampel / ampel (push) Successful in 1m17s
titelAusBdmt lief auf der Laufzeit-Wurzel (G:\ im Betrieb, tmp-Ordner im
Linux-CI-Test) mit win32-join — der BDMV-Pfad wurde auf POSIX zu EINEM
Namen mit Backslashes und der Test brach. Dieselbe Regel wie
struktur/pipeline: Laufzeit-Wurzeln nehmen plattform-path.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 18:41:45 +02:00
HitonabiandClaude Fable 5 5f386e5406 feat(v5): Etappe W-4 — Metadaten-Automatik mit Sicherheitsgrad
Ampel / ampel (push) Failing after 1m20s
metadaten/: discmerkmale.ts (BDMT-Studio-Titel, ISO-9660- und
UDF-Volume-Label direkt vom Medium — OHNE koffi, ueber fs auf \.\G: —,
Label-Normalisierung, Fingerabdruck, progressive Titel-Kandidaten),
tmdb.ts (v3-Key UND v4-Token, de-DE, /find fuer deutsche Texte zu
OMDb-Treffern), omdb.ts, zuordnung.ts (die Confidence-Kaskade
0,95/0,90/0,80/0,60/0,30 aus prescan.py). ablage/poster.ts. Kern meldet
'disc-info' beim Einlegen; die Pipeline benennt den fertigen Ordner
'<Titel> (Jahr)', schreibt movie.nfo/tvshow.nfo mit echten Metadaten
und laedt das Poster. Fenster zeigt 'sehr wahrscheinlich: … · 95 %'.

ZWEI Kaskaden-Schwaechen LIVE GEFUNDEN und gehaertet (gegen die echten
APIs gemessen, Keys aus den Docker-Settings der VM, nicht persistiert):
1. 'Spartacus Gods Of The Arena' wurde zum FILM 'Spartacus' (1960) —
   der stark gekuerzte Kandidat traf woertlich, bevor die volle Anfrage
   als spezifische SERIE galt. Kaskade jetzt JE KANDIDAT
   woertlich→spezifisch (spezifisch nur fuer die volle Anfrage, auch
   fuer Serien). Nachgemessen: jetzt Serie, 90 %.
2. OMDbs t=-Suche machte aus dem Label 'Bd Evg D2' selbstbewusst
   'BD Scream 5' — jetzt Wort-Jaccard-Gate >= 0,5. Nachgemessen: der
   Fall ist jetzt ein ehrlicher 60-%-Vorschlag, den das UI nachfragt.

Messwerte: Akira→95% · Evangelion 2.22→80% (der dokumentierte Fund) ·
Spartacus GotA→Serie 90% · Bd Evg D2→Vorschlag 60%.

Dazu ein neuer Quelltext-Hygiene-Waechter (keine rohen Steuerbytes —
zweimal beim Schreiben passiert, einmal haette ein Test dadurch anders
gemessen als gelesen). 165 Tests gruen, Smoke gruen.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 18:39:09 +02:00
HitonabiandClaude Fable 5 e840b7f327 fix(v5): Laufzeit-Pfade plattformneutral — pipeline/struktur auf node:path
Ampel / ampel (push) Successful in 1m21s
Der NFO-Ablage-Test brach in der Linux-CI: pipeline/struktur bauten mit
path.win32 auf POSIX-Testordnern (mkdir legte 'x\Filme' als EINEN Namen
an, readdir fand nichts). Regel jetzt dokumentiert: Module ueber
LAUFZEIT-Wurzeln (Ablage) nutzen plattform-path — zur echten Laufzeit
immer Windows, in der CI physisch korrekt auf POSIX; Module mit FESTER
Windows-Semantik (katalog, dateiDaneben) bleiben bei path.win32.
Testerwartungen entsprechend ueber join() statt Literale.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 18:29:46 +02:00
HitonabiandClaude Fable 5 3dc296f071 feat(v5): Etappe W-3 — Komprimieren + Ablegen, mit Vollbeweis
Ampel / ampel (push) Failing after 1m18s
komprimieren/: handbrake.ts traegt ALLE bezahlten Fallen aus dem
Docker-Zweig — --aencoder statt --audio-codec (mit Anti-Regressions-
Wächter im Test: der alte Test hatte den Fehler FESTGESCHRIEBEN),
--format aus der Endung (Container kommt sonst aus dem Preset),
Fortschritt NUR aus der Encoding-Zeile (Scan-99%-Falle), letzte 12
Zeilen fuer den Fehlerfall, unknown-option-Erkennung VOR allem anderen
(kommt mit Rueckgabewert 0!), Datei-daneben-Suche, CR-Zeilentrennung
mit 0x81-Kodierungsfalle. encoder.ts misst statt behauptet (--help,
--preset-list, Familien statt Sammelbegriff). presets.ts: je Disc-Typ,
PRESET_KEINE, Sprachlisten.

ablage/: struktur.ts (sichere Namen, '<Titel> (Jahr)', Season NN,
Episoden-Zuordnung NUR bei Eindeutigkeit), nfo.ts (Kodi-Schema),
medienserver.ts (Jellyfin/Emby/Kodi-Refresh, wirft nie).

ablauf/pipeline.ts ERSETZT rippen.ts: Rip → Kompression → Ablage als
EINE Kette; Kompressions-Fehler laesst den verlustfreien Rip STEHEN und
nennt den Ort; Lesefehler ueberleben bis in die Fertig-Meldung. Roh wird
in dieser Etappe grundsaetzlich behalten (Loeschen erst mit W-5-UI).

GEMESSEN am echten System (30.08.2026):
- Encoder: 22 Stueck, Backends cpu-x264/x265/av1 + vce + vce-av1
  (RX 9070 XT als VCE-Familie — nicht unter Intel-Namen), 107 Presets.
- Probe-Encode 5 s Material: success in 45,5 s.
- VOLLBEWEIS: Spartacus-Rohschnitt (17,71 GB — die Datei, die in rc11
  am falschen Schalter starb) mit Preset 'H.265 VCN 1080p' in 2,1 min
  auf 1,17 GB komprimiert und nach Jellyfin-Schema abgelegt:
  E:\Rippy-v5-Beweis\Filme\Spartacus - Gods of the Arena - Disc 2
  (2011)\ mit movie.nfo.
- Nebenbefund: Der Evangelion-Roh-Rip vom 29.08. traegt 'This file was
  not properly finalized' im Kopf — 23,5 GB, die wie fertig aussehen
  und es nicht sind (der abgebrochene rc11-Rip).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 18:26:00 +02:00
HitonabiandClaude Fable 5 ca338ad467 fix(v5): Windows-Pfadregeln ausdruecklich — path.win32 statt join
Ampel / ampel (push) Successful in 1m21s
Die Ampel (Linux) brach an den Katalog-Tests: das plattformabhaengige
path.join mischte dort Schraegstriche in Windows-Pfade. Rippy v5 baut
NUR Windows-Pfade — katalog.ts, handbrake.ts und ablauf/rippen.ts
rechnen jetzt ausdruecklich mit path.win32 und damit auf jeder
Plattform gleich. Im node:24-Container nachgestellt: vorher 2 failed,
mit dem Fix lokal 96 gruen.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 18:16:17 +02:00
HitonabiandClaude Fable 5 844bca37ff feat(v5): Etappe W-2 — Rippen: Parser, makemkvcon-Lauf, Werkzeug-Katalog
Ampel / ampel (push) Failing after 1m22s
rip/parser.ts: die reine Textverarbeitung mit allen bezahlten Fallen aus
dem Docker-Zweig — quelle() (dev:G: statt dev:\.\G:, der 404-Verwandte),
textVon() (UTF-8 streng, sonst cp1252 — nie wieder 'Öffnen'), parseMsg
(Regex statt split — Meldungen mit Komma), PRGV (-1 vs. echtes 0 %),
TINFO/SINFO (Sprache aus Attr 3/4, NICHT 28/29), laengsterTitel mit
Play-All-Schutz, episodenTitel, KRITISCHE_CODES (sprachfeste NUMMERN).

rip/makemkv.ts: Kommandobau + Lauf — ZeilenLeser (binaer, halbe Zeilen,
je Zeile dekodiert), RipAuswertung (pur), rippen() mit AbortSignal,
Lesefehler-Flag AUCH bei Rueckgabewert 0. werkzeuge/katalog.ts: die
Suchreihenfolge samt %VAR%-Gross/Klein-Falle und Registry-Rueckfall.
ablauf/rippen.ts: ein Rip je Laufwerk, Status-Push, 'erst nachsehen,
dann rippen' (unbekannt heisst trotzdem rippen). Fenster: Rippen-Knopf,
Fortschrittsbalken, Abbrechen; Auswurf waehrend des Rips abgelehnt.

Gemessen am echten System (30.08.2026): Katalog findet
makemkvcon64 (Program Files x86), HandBrakeCLI und flac (beide im
rc11-Werkzeugordner LOCALAPPDATA\Rippy\tools). NEUER BEFUND: Nach dem
abgebrochenen rc11-Rip vom Mittag sieht MakeMKV GAR KEIN Laufwerk mehr
(MSG 5042, leere DRV-Liste, mit und ohne --noscan), waehrend die
Storage-IOCTLs sauber antworten — MakeMKV spricht SCSI direkt. 5042 ist
jetzt ein KRITISCHER_CODE mit Klartext-Abhilfe. Der volle Rip-Beweis
(messung.rip.test.ts liegt bereit) braucht deshalb erst eine Hand am
Geraet: Disc neu einlegen oder USB ab-/anstecken.

96 Tests gruen, Smoke gruen.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 18:12:44 +02:00
HitonabiandClaude Fable 5 a45069af5e feat(v5): Etappe W-1 — Laufwerk: Wache, Typ, Auswerfen mit Nachsehen
Ampel / ampel (push) Successful in 1m21s
kern/laufwerk in drei Schichten: codes.ts (Steuercodes HERGELEITET wie
win_ioctl.py, gegen die Doku-Zahlen getestet), win32.ts (der einzige
koffi-Ort im Kern, Muster aus beweise/laufwerk.js), disc.ts (Logik gegen
die LaufwerkApi-Schnittstelle — classify mit den cdrom.py-Schwellen,
Geraete-Info mit ready/empty/unknown + Klartext-Grund, Auswurf als
entriegeln→auswerfen→NACHSEHEN mit injizierbarem Warten). Dazu wache.ts
im 3-Sekunden-Takt (§ 5 Plan A): Uebergangslogik pur, gescheiterte Runde
behaelt den Stand (R2) und meldet laut (R4).

Fenster zeigt Laufwerke live (Modell, Typ, Groesse, Grund) mit
Auswerfen-Knopf; Ereigniszeilen fuer Disc rein/raus und Fehler.

Bündel-Falle gefunden und behoben: Ein woertliches require überlebt
Rollup nicht — win32 wird per dynamischem import() als eigener Chunk
gebaut; der Fehler war dank R4 im Fenster sichtbar statt still.

Gemessen am echten BU40N (30.08.2026, RIPPY_MESSUNG=1):
  Laufwerk G: status=ready typ=bluray groesse=33759690752
  modell=HL-DT-ST BD-RE BU40N 1.03 serial=0025114C0149
Der Auswurf-Beweis (messung.auswurf) folgt am Ende der Sitzung — der
BU40N kann die Schublade nicht selbst einziehen.

52 Tests gruen (Steuercodes, classify, Auswurf-Ablauf, Geraete-Info,
Wache, Smoke weiterhin gruen mit Laufwerks-Kachel im Bild).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 17:28:46 +02:00
HitonabiandClaude Fable 5 6ed8035dcc fix(tests): Linux-only-Waechter pruefte die Welt vor d3e86d2
Ampel / ampel (push) Successful in 1m17s
Die Ampel war rot, und die Ursache war NICHT Rippy v5: d3e86d2 hat den
makemkvcon-Zweig aus dem Prescan bewusst entfernt (einer der 15 Funde),
aber test_makemkvcon_wird_ueber_den_katalog_gesucht verlangte weiter den
alten Katalog-Aufruf. Der Test laeuft nur in der CI (fcntl, lokal
ausgeschlossen) — deshalb fiel es erst beim ersten Push des Branches auf.
Der Waechter passt jetzt auf die NEUE Wirklichkeit auf: kein shutil.which
UND makemkvcon bleibt draussen. Unter Linux nachgemessen: 16/16 gruen,
Gesamtlauf der Nachstellung 995 passed + dieser Fix.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 17:19:51 +02:00
HitonabiandClaude Fable 5 a172a3e2c0 fix(ci): setup-node raus — der Runner hat Node 24 nativ
Ampel / ampel (push) Failing after 1m20s
Lauf 221 brach nach 2:14 min ab; der einzige neue Schritt war
actions/setup-node@v4. Nachgemessen am 30.08.2026: Das Runner-Image
docker.gitea.com/runner-images:ubuntu-latest bringt Node v24.18.0 und
npm 11.16 von Haus aus mit, und die kompletten Node-Schritte der Ampel
(npm ci + build + test in rippy-windows) laufen in einem frischen
node:24-Container auf der VM gruen durch. Statt Beschaffungs-Magie
prueft die Ampel jetzt im Klartext, dass Node >= 22 da ist — zu alt
heisst ROT mit Ansage, nicht kryptisch.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 17:07:53 +02:00
HitonabiandClaude Fable 5 0464933ada docs: SAVEPOINT — Rippy v5, Etappe W-0
Ampel / ampel (push) Failing after 2m14s
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 16:54:32 +02:00
HitonabiandClaude Fable 5 c539e65cd2 feat(v5): Etappe W-0 — das Geruest steht
Electron 44 + TypeScript, drei Prozesse (haupt / kern als utilityProcess /
fenster mit React), Nachrichten-Schema mit Pruef-Funktionen, node:sqlite
als einzige Datenbank-Stelle (kern/speicher/db.ts, § 6.7), Prozess-Leine
im Haupt (Job Object aus beweise/leine.js — Begruendung fuer den Ort im
Dateikopf), MessagePort direkt Fenster<->Kern, Einzelinstanz-Sperre,
Kern-Neustart-Wache, strikte CSP im gebauten Fenster.

Wächter-Tests nach § 4.3: koffi nur an zwei benannten Orten (R1), kein
leerer catch und kein catch-mit-Leerwert (R2/R4), kein HTTP-Server
(§ 4.1), node:sqlite nur in db.ts (§ 6.7). Dazu Datenbank- und
Schema-Tests: 18/18 gruen, Typpruefung in drei Kontexten.

Der W-0-Beweis (npm run smoke, echtes Programm):
SMOKE: OK — fenster=geladen kern=pid:13676,node:24.18.1 datenbank=ok
leine=gesetzt pong=ok version=5.0.0-w0

Nachgemessen ausserdem: taskkill /F auf den Haupt-Prozess (ohne /T,
der Absturz-Fall aus rc10) — der Kern stirbt mit.

Bau-Fallen dokumentiert (BAUEN.md): npm 11 blockt Electrons
Install-Skript (§ 3.5), plugin-react 6 verlangt Vite 8 (deshalb 5.2),
TypeScript bewusst auf 5.9.3 gepinnt statt tsgo 7.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 16:53:30 +02:00
HitonabiandClaude Fable 5 564bd17f84 ci: Ampel auf Node 24 verankert
Rippy v5 (rippy-windows/) braucht Node 24: Vite 7 und node:sqlite laufen
nicht auf dem Zufalls-Node des Runners. docker/ui unter Node 24 lokal
nachgemessen (npm ci + build gruen, 30.08.2026). Die Ampel prueft
unveraendert — nur das Werkzeug ist jetzt festgelegt.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 16:53:16 +02:00
HitonabiandClaude Fable 5 a0cff205ab docs(konzept): Entscheid 4 — Worktree aufgeloest, Branch normal ausgecheckt
Der doppelte Checkout (Worktree + Hauptordner) blockierte den Start neuer
Sitzungen auf dem Branch. Der Branch selbst und main bleiben unveraendert.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 16:25:58 +02:00
HitonabiandClaude Fable 5 c44bfa6daa docs(konzept): Zweite Fassung — geprueft, nachgemessen, drei Entscheide
- Faktenfehler korrigiert: Gitea ist oeffentlich per HTTPS erreichbar
  (gemessen, § 3.6) — Updates kommen direkt daraus, Drei-Wege-Tabelle weg
- node:sqlite in Electron 44 im utilityProcess bewiesen (§ 3.4,
  beweise/sqlite-main.js + sqlite-kern.js) — better-sqlite3 nicht noetig
- Disc-Wache umgedreht: 3-Sekunden-Takt ist Plan A, WM_DEVICECHANGE
  spaetere Verfeinerung (§ 5)
- Entscheid 7 verschaerft: main-Aufraeumen sofort, nicht erst nach W-6
- Entscheid 9 neu: Zielgruppe Bekannte mit Link, Lizenztexte liegen bei
- MakeMKV-Lage tagesaktuell bestaetigt (Key bis Ende September 2026,
  Kaufseite defekt = Dauerzustand seit Sommer 2025)
- Electron-Pflege-Regel (§ 6.8), npm-11-Sperre trifft auch Electron
  selbst (§ 3.5), Release = drei Dateien, 4K-Schluesselkette in § 10,
  Risikotabelle aktualisiert

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-30 16:20:51 +02:00
HitonabiandClaude Opus 5 e514e4070b docs(konzept): Entscheid 8 — der Remote-Worker bleibt bei Docker
Commander: „Das soll NICHT Teil des neuen Standalone-Produktes sein, da
dieser NUR fuer die Docker-Variante verwendet wird."

Damit ist bestaetigt, was in Paragraph 11.1 zuvor nur als Auslegung stand.
Der Remote-Encode-Worker wird WEDER abgeraeumt (er ist Docker, und Docker
bleibt unangetastet — Entscheid 2) NOCH nach v5 uebernommen (v5 ist
Einzelplatz, Entscheid 3 — es gibt dort keinen zweiten Knoten, dem man
etwas schicken koennte).

Dazu die eigentliche Reparatur an diesem Abschnitt: Er war in
Entwickler-Begriffen geschrieben (Modulnamen, PyInstaller, os.name-Zweige)
und deshalb fuer den Adressaten nicht lesbar — zweimal nachgefragt, zweimal
zu Recht. Paragraph 11.1 fuehrt die drei Teile jetzt erst in Klartext ein:

  A ist Rippy. B ist ein Handlanger fuer die VM. C sind Notizzettel,
  die wegen A eingeklebt wurden.

Und macht den Unterschied A/C an dem fest, worauf es beim Aufraeumen
ankommt — nicht am Inhalt, sondern am Ort: A sind ganze Ordner, die Docker
nie aufschlaegt (wegwerfen). C sind einzelne Seiten in Ordnern, die Docker
taeglich benutzt (einzeln durchgehen). Erst danach kommt die Tabelle mit
den Dateinamen.

Das ist kein Beiwerk: Genau diese Verwechslung wuerde beim Aufraeumen die
laufende VM treffen. Und manche Windows-Zeile braucht sogar B weiter — etwa
die Regel, dass eine Laufwerkswurzel ihren abschliessenden Trenner behaelt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-30 15:59:11 +02:00
HitonabiandClaude Opus 5 fde3a78e97 docs(konzept): Entscheide 5-7 — kein Zertifikat, Gitea-Updates, Altlast weg
Die drei offenen Punkte aus KONZEPT-WINDOWS sind entschieden (30.08.2026).

Entscheid 5 — kein Code-Signing-Zertifikat. Die SmartScreen-Warnung wird
hingenommen und in der Anleitung erklaert. Die Folge gehoert dazu und steht
jetzt in 6.8: Ohne Signatur kann electron-updater ein Update nicht auf
Echtheit pruefen, also ist der Transportweg die einzige Absicherung —
Updates nur ueber HTTPS, eine http-Adresse wird abgelehnt.

Entscheid 6 — Updates aus Gitea, auch fuer Externe erreichbar. Rippys
Seite ist einfach: die Adresse steht in der Konfiguration, electron-updater
braucht nur einen statischen HTTPS-Ort. Die Netz-Seite ist es nicht —
Gitea liegt auf 192.168.178.153 im Heimnetz und ist von aussen nicht
erreichbar. Drei Wege sind aufgeschrieben und bewertet (Gitea
veroeffentlichen / oeffentlicher Spiegel / eigene Quelle je Nutzer),
Empfehlung ist der Spiegel. Rippy wird fuer alle drei gebaut, die
Entscheidung kann spaeter fallen ohne Programmaenderung.

Entscheid 7 — der alte Windows-Weg wird entfernt, auch aus main. Dafuer
gibt es einen neuen Abschnitt 11 mit der Arbeitsliste, und die zerfaellt
in DREI Teile statt einem:

  A  die Standalone-App (PyInstaller, Tray, Fenster, Win32-Treiber,
     lokale Queue, Werkzeug-Beschaffung)          -> weg
  B  der Remote-Encode-Worker fuer die Docker-Installation -> BLEIBT
  C  die verstreuten os.name=="nt"-Zweige im Docker-Code -> einzeln pruefen

Dass B bleibt, ist ausdruecklich als Auslegung markiert, nicht als
Anweisung: Der Remote-Worker ist eine Funktion der Docker-Installation,
und Entscheid 2 haelt die unangetastet. Ihn mit abzuraeumen wuerde der VM
eine Faehigkeit nehmen, die niemand gekuendigt hat.

Teil C ist der heikle: pfade.py bleibt (der Remote-Worker braucht
Laufwerkswurzeln und UNC), nativ_nachsehen() ist zu pruefen, und die
Faehigkeiten-Auskunft /betrieb bleibt sinnvoll — nur ihre Windows-Werte
fallen weg.

Zeitpunkt: erst NACH v5 W-6. Solange v5 nicht installierbar ist, ist die
alte Fassung das einzige Windows-Rippy — sie vorher zu loeschen waere eine
Luecke ohne Gegenwert. Der Entscheid nennt die Richtung, kein Datum.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-30 15:52:37 +02:00
HitonabiandClaude Opus 5 cb811bec28 docs: KONZEPT-WINDOWS — Rippy v5 als eigenstaendiges Electron-Programm
Die heutige Windows-Fassung ist der Docker-Code in einer EXE: PyInstaller
buendelt docker/api und docker/worker, uvicorn laeuft auf 127.0.0.1:7788,
pywebview stellt ein Fenster davor. Elf Release-Kandidaten in drei Tagen,
und die Funde sind fast alle derselbe Typ — Linux-Annahmen, die unter
Windows etwas anderes bedeuten (timeout ls -d, shutil.which, /app,
/dev/{name}, F: ohne Trenner).

Das Konzept beschreibt den Neubau als Windows-Programm: Electron 44,
TypeScript durchgehend, Einzelplatz, kein Python, kein HTTP-Server.

Vier Entscheide des Commanders (30.08.2026) sind eingearbeitet:
alles TypeScript/Node · Docker bleibt unangetastet · reiner Einzelplatz ·
eigener Branch.

Vor der ersten Zeile Konzept gemessen (Regel D), Belege in beweise/:

  * Win32 aus Node an G: (HL-DT-ST BD-RE BU40N) — Laufwerkssuche,
    CreateFileW, QUERY_PROPERTY (Modell + Serial), CHECK_VERIFY2,
    GET_LENGTH_INFO (33,76 GB -> Blu-ray). IOCTL_CDROM_DISK_TYPE
    antwortet mit Fehler 50 — derselbe Befund wie im Python-Treiber.
  * Prozess-Leine (Job Object): Kind stirbt mit dem per taskkill /F
    ohne /T abgeschossenen Elternprozess. Die Messung aus rc10, in
    Node nachgestellt.
  * node:sqlite ist in Node 24 eingebaut — in Electron noch ungeprueft,
    ausdruecklich als offener Punkt markiert.

Akutestes Risiko im Dokument: MakeMKVs freier Beta-Key laeuft Ende
September 2026 ab, die Kaufseite fuer die Dauerlizenz ist seit Mai defekt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-30 15:38:39 +02:00
HitonabiandClaude Opus 5 9050fea3f0 docs: SAVEPOINT v4.0-rc11
Der Schalter, den es nicht gibt — und vierzehn weitere Funde aus demselben
Rundgang. Jeder mit der Messung, an der er haengt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-30 15:11:08 +02:00
HitonabiandClaude Opus 5 d3e86d2641 fix(windows): Der Schalter, den es nicht gibt, und vierzehn weitere Funde
Commander: „Kompression fehlgeschlagen bei Spartacus … _t01.mkv: HandBrake
endete mit Code 0" — 16,5 GB fertiger Rohschnitt, und die Kompression war in
derselben Sekunde vorbei, in der sie begann.

Nachgestellt mit genau der Befehlszeile, die Rippy baute:

    unknown option (--audio-codec)
    HandBrake has exited.        $? = 0

Den Schalter `--audio-codec` gibt es bei HandBrakeCLI nicht; er heisst
`-E` / `--aencoder`. Ein unbekannter Schalter ist fuer HandBrake kein Fehler,
der Rueckgabewert ist 0. Der Test dazu forderte den falschen Namen sogar ein.

Daraus wurde ein Rundgang durch den Windows-Pfad. Alles unten ist gemessen,
nichts vermutet (Regel D).

## Die Kompression

1. `--aencoder` statt `--audio-codec`. Am mitgelieferten HandBrakeCLI 1.11.2
   gemessen, mit einem 5-Sekunden-Encode auf der echten Roh-Datei bestaetigt.

2. HandBrakes letzte Zeilen werden aufgehoben (12 gepuffert, 4 in der
   Meldung) und `unknown option (...)` wird als eigener Fall erkannt, VOR
   allen anderen. Vorher wurde jede Zeile weggeworfen, die kein Fortschritt
   war — bei Rueckgabewert 0 blieb damit keine Auskunft uebrig. Die geratene
   Zeile „Meist ist der Zielordner nicht beschreibbar" ist raus; sie war
   falsch und hat die Suche in die falsche Richtung geschickt.

3. Ein `ue`-Umlaut im Pfad toetete die Kompression. HandBrake schreibt zwei
   Kodierungen in denselben Strom (derselbe Pfad einmal UTF-8, einmal CP850).
   In CP850 ist das Byte 0x81, und das ist in cp1252 — was `text=True` auf
   deutschem Windows waehlt — undefiniert:

       UnicodeDecodeError: charmap codec can't decode byte 0x81

   Neu: `rip/handbrake_aufruf.py` mit `HB_LESEN`, benutzt von ripping.py und
   caps.py. Bewusst nicht binaer wie bei makemkvcon: HandBrake trennt
   Fortschrittszeilen mit CR, im Binaermodus waere der Balken weg.

## Die Rohdaten

4. `rohdaten.kandidaten` machte aus dem Arbeitsordner `F:\` ein `F:` und
   verband damit weiter. Das ist unter Windows der aktuelle Ordner auf
   Laufwerk F, nicht dessen Wurzel — 16,5 GB waren unsichtbar, und der
   Wiederholen-Dialog bot nur „Neu rippen" an. Die Falle steht woertlich im
   Kopf von `pfade.verbinden`.

5. Gesucht wurde unter der heutigen Einstellung statt unter der Wahl DIESES
   Rips (`meta["work_dir"]`). Genau dafuer wurde rohdaten.py am 26.07.
   gebaut; repariert wurde damals die Kandidatenliste, nicht der Aufrufer.
   Neu: `_arbeitsverzeichnis_des_jobs`, benutzt an vier Stellen.

6. Zwei Speicher fuer dieselben Ordner: Die Oberflaeche schreibt
   `outputDir`/`workDir` in die Datenbank, `betrieb` liest `storage.*` aus
   der Konfigurationsdatei, und die schreibt niemand. Gemessen: eingestellt
   `E:\Rippy`, angezeigt `C:\Users\...\Videos\Rippy`. Neu:
   `betrieb.mit_einstellungen`.

## Das Laufwerk

7. `device_info` fing den OSError ab und lieferte „unknown" ohne den Grund.
   Nach einem Rip mit Lesefehlern beantwortete das Laufwerk keine
   Medien-Abfragen mehr (Win32-Fehler 1), die Geraete-Auskunft aber schon —
   im UI stand eine volle Laufwerkskarte, kein Rip startbar, und im
   Protokoll das laengst veraltete „Disc erkannt". Neu: `ZUGRIFFS_GRUENDE`,
   ein Feld `grund` im Laufwerks-Eintrag und eine Protokollzeile je Wechsel.
   Eine fehlgeschlagene Disc-Erkennung wird ebenfalls protokolliert.

8. Der Linux-Treiber nannte ein unzugaengliches Laufwerk „empty", waehrend
   Windows richtig „unknown" sagt. Angeglichen, samt Feld-Paritaet.

9. `CreateFileW`, `DeviceIoControl` und `CloseHandle` hatten weder `restype`
   noch `argtypes` — 32-Bit-`c_int` fuer einen 64-Bit-HANDLE, in beide
   Richtungen. Mit `restype` aendert sich der Fehlerwert von -1 auf
   0xFFFFFFFFFFFFFFFF; die Pruefung deckt jetzt beides ab. Am echten
   Laufwerk gegengeprueft, Fehlerpfad eingeschlossen.

10. Der Vor-Scan lief bei JEDER eingelegten Disc ein `makemkvcon info` mit
    120 s Zeitgrenze — 20 bis 120 Sekunden „Disc wird gelesen". Frueher war
    das schnell, weil der Zweig unter Windows nie lief (`shutil.which`,
    repariert am 28.08.). Das Ergebnis landete allein in `toc["tracks"]`,
    das niemand liest: Der Rip-Dialog holt seine Liste ueber
    `/devices/{id}/scan-tracks`, wenn sie gebraucht wird. Entfernt.

## Notbremsen

11. `_frei_bytes` suchte den naechsten vorhandenen Ordner selbst.
    `os.path.dirname("Q:\\")` gibt sich selbst zurueck — ein
    Arbeitsverzeichnis auf einer abgezogenen Platte haette den Job vor dem
    Rip stumm haengen lassen. Benutzt jetzt
    `pfade.naechster_vorhandener`, das den Abbruch seit V2-1 hat.

12. `naechster_vorhandener` haelt Laufwerks- und UNC-Wurzeln jetzt absolut.

13. `aufraeum_skript` baut sein `rmdir /s /q` aus `InstallLocation` in der
    Registry. Waere das eine Laufwerks-Wurzel, loeschte die Deinstallation
    das Laufwerk. Nicht beobachtet, aber nicht wiedergutzumachen — der
    Loeschbefehl bleibt in dem Fall weg.

## Lesefehler

MakeMKV sicherte 1 von 2 Titeln, endete mit 0, und Rippy schrieb „Rip
fertig". Jetzt gibt es eine Warnung, auch wenn der Rip als Erfolg endet, und
die MSG-Nummer steht im Protokoll: MakeMKVs Texte sind uebersetzt, die
Nummern nicht.

## Aus der Gegenprobe am laufenden Rippy

Die erste Fassung dieses Standes war installiert, als der Commander meldete:
„nun oeffnen sich diverse fenster im hintergrund, gehen ganz kurz auf und dann
wieder zu. Das laufwerk hoert auch einfach auf zu lesen." Beides Altlasten,
die erst durch die neue Protokollzeile sichtbar wurden.

14. Prozesserzeugung mitgeschnitten:

        14:54:40  timeout.exe          timeout 4 ls -d C:\Users\...\d7ee6c06-...
        14:54:40  WindowsTerminal.exe

    `rohdaten.pruefen` fragt mit `timeout N ls -d`, ob es ein Verzeichnis
    gibt. Unter Linux ist das richtig (os.path.isdir kann an einem toten
    CIFS-Mount im Kernel haengen, ein Kindprozess laesst sich abbrechen).
    Unter Windows ist es dreifach falsch: timeout.exe gibt es dort, kennt
    aber weder `ls` noch `-d`; sie braucht eine Konsole, und die reisst
    Windows auf; und ihr Rueckgabewert ist nie 0, die Antwort lautete also
    „weg" fuer JEDES Verzeichnis. Rohdaten waren unter Windows
    grundsaetzlich unsichtbar. Neu: `nativ_nachsehen()`. Die zwei
    gleichartigen Aufrufe in mounts.py bekommen dieselbe Absicherung.

15. Der Waechter fragte das Laufwerk alle drei Sekunden ab — auch mitten im
    Rip, also drei CreateFileW plus IOCTLs auf ein Geraet, das makemkvcon
    gerade liest:

        12:49:52  bluray-Rip gestartet
        12:50:09  [watcher] Laufwerk G: beantwortet keine Medien-Abfragen
        12:50:12  MSG 2003 SCSI-Fehler ILLEGAL REQUEST:INVALID FIELD IN CDB
        12:50:12  makemkvcon endete mit Code 11

    `_auto_prescan` haelt sich seit dem 29.08.2026 an die Regel „waehrend
    eines Rips wird nicht gescannt"; die Laufwerksabfrage tat es nicht.
    Jetzt gilt in der Zeit der letzte bekannte Stand.

## Zwei Tests, die gelogen haben

* `assert "--audio-codec" in cmd` schrieb den Fehler fest.
* `lambda: {}` als Doppelgaenger fuer `get_settings(key, bei_fehler_leer)`
  brach, sobald ein Aufrufer einen Parameter benutzte — und zeigte dann auf
  den Code statt auf sich selbst.

977 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-30 15:11:00 +02:00
HitonabiandClaude Opus 5 b6a93aa726 docs: SAVEPOINT v4.0-rc10
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 20:55:44 +02:00
HitonabiandClaude Opus 5 fed24237c9 fix(windows): makemkvcon ueberlebte Rippy und hielt das Laufwerk fest
Commander: „jetzt hast du den makemkvcon kram dir nicht angeguckt".
Stimmt — es stand als Frage im Notizbuch statt als Riegel im Code.

## Gemessen, nicht vermutet

Ein Elternprozess startete makemkvcon, dann wurde er hart beendet
(`taskkill /F` OHNE `/T` — genau das, was beim Dienst-Stopp und beim
Drueber-Installieren passiert):

    ohne Leine   makemkvcon PID 15368   vor dem Kill: True   danach: True
    mit  Leine   makemkvcon PID 43608   vor dem Kill: True   danach: False

Windows raeumt Kindprozesse nicht auf. Eine solche Waise HAELT DAS LAUFWERK —
jeder spaetere Rip scheitert dann mit „Das Öffnen der Disk schlug fehl". Zwei
davon standen waehrend der Messungen auf diesem Rechner.

## Zwei Riegel

* **Die Leine** (`winlauf.kinder_an_die_leine`) — eine Arbeitsgruppe (Job
  Object) mit KILL_ON_JOB_CLOSE. Stirbt Rippy, sterben makemkvcon, HandBrake
  und flac mit. Auch beim Absturz, auch per Taskmanager. Einmal beim
  Dienststart gesetzt, deckt sie JEDEN Werkzeugaufruf ab.
* **Der Aufraeumer** (`winlauf.waisen_beenden`) — beendet beim Start
  Werkzeug-Prozesse, deren Elternprozess es nicht mehr gibt. Fuer das, was
  eine aeltere Fassung oder ein Absturz hinterlassen hat. Nur ELTERNLOSE:
  Ein makemkvcon eines laufenden Rippy bleibt unangetastet, `makemkv.exe`
  (die Oberflaeche) steht gar nicht erst auf der Liste.

Am echten Fall nachgestellt: Waise erzeugt, Rippy gestartet, Waise weg.

## Drei Prozesse duerfen NICHT mitsterben

Dienst, Fensterprogramm und das Aufraeum-Skript der Deinstallation loesen sich
ueber `eigenstaendig_starten` heraus (CREATE_BREAKAWAY_FROM_JOB). Mit
Rueckfall ohne die Fahne: Steckt Rippy in einer fremden Arbeitsgruppe ohne
Herausloese-Erlaubnis, verweigert Windows den Start rundweg — ein Fenster, das
gar nicht mehr aufgeht, waere schlimmer als eines, das mitstirbt.

## Die Falle beim Bauen

Der erste Anlauf meldete nur „ging nicht". Ursache: Ohne `argtypes` reicht
ctypes einen Griff als 32-Bit-int weiter. `GetCurrentProcess()` liefert aber
(HANDLE)-1 = 0xFFFFFFFFFFFFFFFF, ctypes wirft `ArgumentError: int too long to
convert`, und das breite `except` verschluckte es. `kernel32()` meldet jetzt
jede Signatur an; ein Test wacht darueber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 20:54:44 +02:00
HitonabiandClaude Opus 5 21c626eb4e docs: SAVEPOINT v4.0-rc9
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 20:40:25 +02:00
HitonabiandClaude Opus 5 f0f719ca12 fix(windows): Zweiter Rip startete waehrend der Kompression ins leere Laufwerk
Der Commander meldete einen Rip-Fehlschlag „bei der Komprimierung", obwohl
der Rip laengst durch war:

    makemkvcon endete mit Code 11 — letzte Meldung:
    Das Öffnen der Disk schlug fehl  — keine MKV-Datei entstanden

Auffaellig war, was FEHLTE: kein „Ursache:". Waere der Geraetepfad schuld
gewesen, stuende dort MSG 2024. Bleibt: kein Datentraeger im Laufwerk.

Der Ablauf dahinter:
  1. Rip fertig → Rippy wirft die Disc aus (Standardeinstellung)
  2. Status wird auf `transcoding` gesetzt — ab hier sagte `has_active_job`
     NEIN, das Laufwerk sei frei; es kennt nur pending/running
  3. Die Disc-Wache sieht beim Auswurf einen Statuswechsel → „eingelegt"
  4. Die Vollautomatik startet einen ZWEITEN Rip — auf ein Laufwerk, dessen
     Schublade gerade herausfaehrt

Der zweite Rip lief in ein leeres Laufwerk. Auf dem Bildschirm sah das aus,
als sei die Kompression gescheitert — sie lief ungestoert weiter.

Drei Aenderungen:

* `store.job_offen` — der weitere Riegel (pending/running/transcoding/
  canceling) fuer die Vollautomatik. `has_active_job` bleibt unveraendert:
  Das fragt „haelt gerade jemand das Laufwerk?", und waehrend der Kompression
  tut das niemand — ein Auswurf von Hand bleibt erlaubt.
* `ripping.disc_fehlt` — vor dem makemkvcon-Start nachsehen, ob ueberhaupt
  eine Disc drin liegt. Statt zwei Minuten Warten und Code 11 gibt es einen
  Satz, den man versteht. Ein FEHLGESCHLAGENER Blick verweigert nichts:
  „ich weiss es nicht" darf nie zu „es geht nicht" werden.
* MSG 5010 in KRITISCHE_CODES — MakeMKVs Sammelmeldung sagt fuer sich nichts.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 20:36:59 +02:00
HitonabiandClaude Opus 5 f6f0a4ccb6 feat(windows): MusicBrainz-Tags fuer Audio-CDs
Ampel / ampel (push) Successful in 1m25s
Commander: „go"

Die Dateien hiessen `Track 01.flac`. Eine Musiksammlung ohne Titel ist eine
Sammlung von Nummern.

## Wie MusicBrainz eine CD wiedererkennt

Nicht am Namen (den kennt die CD nicht) und nicht an einer Kennung auf der
Disc (die gibt es nicht), sondern an der LAGE ihrer Spuren. Daraus wird ein
Fingerabdruck gerechnet — SHA-1 ueber die Versaetze, base64 mit eigenem
Alphabet (musicbrainz.org/doc/Disc_ID_Calculation).

## Belegt OHNE Audio-CD

MusicBrainz gibt zu jeder bekannten Kennung die Spurlage heraus, aus der sie
gerechnet wurde. Wer die Lage zurueckbekommt und daraus dieselbe Kennung
rechnet, hat die Rechnung belegt:

    Spurlage „Back in Black" (abgefragt)  ->  3KVSIWn_ewv9z0cCizmOJzDWtsQ-
    MusicBrainz sagt dazu                 ->  3KVSIWn_ewv9z0cCizmOJzDWtsQ-

Und die ganze Kette am Stueck, mit echtem Encoder:

    Ordner   ACDC - Back in Black
    Dateien  01 - Hells Bells.flac, 02 - Shoot to Thrill.flac, …
    Tags     TITLE/ARTIST/ALBUM/ALBUMARTIST/DATE/TRACKNUMBER
             — mit metaflac aus der FERTIGEN Datei zurueckgelesen

## Zwei Fallen

**Der Vorlauf.** Die Kennung rechnet MIT den 150 Frames, das Lesen OHNE. Wer
das verwechselt, bekommt eine Kennung, die niemand kennt — und zwar ohne
Fehlermeldung, denn die Antwort ist dann schlicht „unbekannte Disc".

**`AC/DC`.** Als Ordnername haette der Schraegstrich unter Windows einen
Unterordner aufgemacht. Aufgefallen NUR, weil der Beweis den Namen ausgegeben
hat. Jetzt saeubert `sauberer_name` beides — Datei und Ordner.

## ⚠️ Mein Fehler dabei

Die Spurlage im Test hatte ich zuerst ERFUNDEN: Beim Beweis hatte ich nur
Spurzahl und Lead-Out ausgegeben und den Rest „passend" ergaenzt. Der Test
wurde prompt rot — zu Recht. Die Zahlen stehen jetzt so drin, wie MusicBrainz
sie herausgibt (erste Spur bei 182, nicht bei 150: diese Pressung hat einen
laengeren Vorlauf).

Ohne Treffer bleibt es bei `Track 01.flac`. Eine unbekannte Disc ist kein
Fehler, und ein Netzausfall darf keinen Rip umwerfen.

932 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 16:33:46 +02:00
HitonabiandClaude Opus 5 986fcf19b1 feat(windows): Audio-CDs rippen — die letzte Luecke ist zu
Ampel / ampel (push) Successful in 1m24s
Commander: „mach es"

Gemeint war die Lücke, die seit Wochen so im SAVEPOINT stand: **Audio-CDs
laufen unter Windows nicht.** `cdparanoia` und `abcde` sind Linux-Werkzeuge.

## Nicht abcde nachbauen — den Windows-Weg gehen

Eine Audio-CD hat kein Dateisystem. Die `Track01.cda`, die Windows zeigt,
sind 44 Byte grosse Platzhalter; die Musik liegt roh in 2352-Byte-Sektoren.
Windows bietet dafuer zwei Steuercodes an:

    IOCTL_CDROM_READ_TOC   Inhaltsverzeichnis (MSF je Spur, Audio/Daten)
    IOCTL_CDROM_RAW_READ   die Sektoren selbst

Gegengeprueft, dass die berechneten Codes den dokumentierten entsprechen:
0x24000 und 0x2403e.

Kodiert wird mit dem FLAC-Encoder vom offiziellen Xiph-Spiegel (1.5.0), den
Rippy beim Einrichten holt — wie MakeMKV. KEIN Pflichtwerkzeug: Ohne ihn
laeuft alles ausser Audio-CDs, und ein Fehlschlag darf das Einrichten nicht
truebe machen.

## Zwei Fallen, beide gemessen

**Die Leseadresse zaehlt in 2048er-Einheiten**, obwohl ein Audio-Sektor 2352
Bytes hat. Das ist dokumentiert und sieht falsch aus; mit 2352 liest man an
der falschen Stelle.

**`flac.exe` braucht `libFLAC.dll` daneben.** Mit nur der exe endete jeder
Aufruf mit 0xC0000135 — „DLL nicht gefunden" — und zwar ohne eine einzige
Zeile Ausgabe. Jetzt wird der ganze Win64-Ordner ausgepackt.

## Was geprueft ist

Ein Laufwerk und eine Audio-CD lassen sich in der Ampel nicht herstellen.
Deshalb steht alles Rechenbare in reinen Funktionen — MSF↔LBA, das Zerlegen
der TOC-Bytes, WAV-Kopf, Blockaufteilung, Dateinamen — und der Ablauf
bekommt Laufwerk und Encoder eingespritzt. 28 Tests dafuer.

Zusaetzlich mit dem ECHTEN Encoder gemessen: zwei Spuren erzeugten Tons
gerippt, und **FLAC bestaetigt seine eigenen Dateien** (`flac -t`, Code 0).
Am echten Laufwerk gegengeprueft, dass das Inhaltsverzeichnis gelesen wird —
die eingelegte Blu-ray meldet sich korrekt als DATEN-Track und wird nicht als
Musik behandelt.

Was noch fehlt: MusicBrainz-Tags. Die Dateien heissen `Track 01.flac`. Der
Weg dafuer steht (`tags_je_spur`), die Disc-Kennung fuer die Abfrage nicht.

915 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 16:26:23 +02:00
HitonabiandClaude Opus 5 1b84ec2a45 fix(windows): Vollstaendiger Rundgang durch die Docker-Reste
Ampel / ampel (push) Successful in 1m20s
Commander: „Bro, du musst alles was rippy jetzt im code hat für Windows
Bauen! Jeden pfad, alles wo die tools drauf zugreifen. Diese Rippy version
MUSS 100% Windows Kompatibel sein. Prüfe bitte den kompletten Quellcode nach
Docker Resten."

Systematisch gesucht statt Fundstelle fuer Fundstelle: feste POSIX-Pfade,
Linux-Programme, POSIX-eigene Aufrufe, `shutil.which`, `posixpath` auf echten
Pfaden, Container-Texte. Sechs echte Fehler dabei.

## 1. `/dev/{name}` in drei Endpunkten — der schwerste

Das UI ruft `/devices/{id}/eject`, `/scan-tracks` und `/tracks` mit der
Kennung aus der Geraeteliste auf, unter Windows also `G`. Gebaut wurde daraus
`/dev/G` — steht in keiner Laufwerksliste. **Auswerfen und „Disc scannen"
antworteten unter Windows IMMER mit 404**, ohne dass irgendwo stand, warum.

Hin- und Rueckweg gehoeren zusammen: Beide Treiber haben jetzt `kennung()`
und `pfad_zu_kennung()`. Wer die Kennung vergibt, loest sie auch auf.

## 2. `os.path.isdir("/app")` — zum zweiten Mal

Nach `caps.py` (heute frueh) auch in `ablauf.py`: Der eigenstaendige
Windows-Rippy hielt sich fuer einen FREMDEN Worker und haette sich selbst
vorgeworfen, Container-Pfade nicht zu erreichen — auf einer Maschine ohne
Container. Die Entscheidung ist jetzt einspritzbar; vorher hing der Test
daran, ob es einen Ordner `/app` gibt.

## 3. `shutil.which` in `schluessel.py`

Ausgerechnet im Modul, das es NUR unter Windows gibt: Es suchte makemkvcon im
PATH, wo unter Windows nie ein Programm aus „Programme" steht. Die
Schluessel-Automatik fuer 4K-UHD lief damit nie an.

## 4. `posixpath.join` auf echten Pfaden

`rohdaten.py` baute `C:\Roh/datei.mkv` — gemischte Trenner, die im UI falsch
aussehen und jeden Vergleich brechen.

## 5. Container-Pfad in einer Nutzermeldung

„Roh-Datei bleibt in /app/temp erhalten" nennt jetzt den echten Ordner. Wer
die Datei retten will, sucht sonst am falschen Ort.

## 6. Container-Pfade als UI-Vorbelegung

Rip-Dialog und `useBetrieb` starteten mit `/app/media`, bis die Antwort da
war. Leer ist ehrlicher: Es behauptet nichts.

## Und HandBrakes „Code 0"

Code 0 heisst ERFOLG. Rippy meldete trotzdem „fehlgeschlagen", weil die Datei
nicht am erwarteten Ort lag: **HandBrake bestimmt den Container aus dem
PRESET, nicht aus der Endung** — ein MP4-Preset schreibt `.mp4` neben das
verlangte `.mkv`. Jetzt erzwingt `--format` den Container passend zur Endung
(an HandBrake 1.11.2 gegengeprueft), und falls doch etwas daneben liegt, wird
es gefunden statt weggeworfen.

## Der Waechter

`test_keine_container_reste.py` prueft mechanisch, dass im Windows-Weg kein
Container-Pfad ohne Begruendung steht. Die Ausnahmen stehen namentlich mit
Grund da (Linux-Zweige, benannte Rueckfaelle) — und ein zweiter Test wirft
jede Ausnahme raus, die niemand mehr braucht.

Ueber den Tokenizer, nicht ueber „faengt mit Anfuehrungszeichen an": Der
erste Anlauf blieb prompt an seinem eigenen `r\"\"\"`-Docstring haengen.

887 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 16:14:10 +02:00
HitonabiandClaude Opus 5 1a529f4e75 fix(windows): „Disc wird gelesen" blieb waehrend des ganzen Rips stehen
Ampel / ampel (push) Successful in 1m13s
Commander: „der ‚Disk wird gelesen' panel braucht eeeeewig. Der Rip ist
bereits bei 30% und er liest immernoch."

Genau so war es — und die Erkennung kam auch nie zum Ende.

## Warum

`_auto_prescan` hatte GENAU EINE Absicherung: nicht zweimal gleichzeitig
(`_laeuft`). Ob auf dem Laufwerk gerade ein Rip laeuft, hat es nie gefragt.

Waehrend eines Rips haelt `makemkvcon` das Laufwerk. Ein zweites
`makemkvcon info` daneben wartet, bis es seine Zeitgrenze erreicht (gemessen:
eine Laufwerks-Abfrage braucht dann 14 s statt 5, der `info`-Aufruf laeuft in
seine 120 s). Solange steht die Marke `_laeuft` — und damit das Panel, das
ich heute frueh genau dafuer gebaut habe.

Es gibt keinen Grund, waehrend eines Rips zu scannen: Das Laufwerk ist
belegt, und **welche Disc drin ist, wissen wir bereits** — der Job laeuft ja
auf ihr.

## Zwei Stellen, weil es zwei Wege hinein gibt

1. `_auto_prescan` bricht ab, wenn auf dem Geraet ein Job laeuft. Das
   verhindert jeden Scan, der NACH dem Rip-Start angestossen wird.
2. Der Job-Start raeumt eine haengende Marke weg. Ein Scan, der KURZ VORHER
   begann, haelt sie sonst bis zu seinem Ende fest. Verloren geht dabei
   nichts: Unter `_laeuft` steht nur der Platzhalter, und der laufende Scan
   traegt sein Ergebnis spaeter selbst nach.

880 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 15:54:48 +02:00
HitonabiandClaude Opus 5 548742e771 fix(windows): Restzeit blieb ewig „wird gemessen" — zwei Docker-Annahmen
Ampel / ampel (push) Successful in 1m32s
Commander: „Über den kompletten vorgang steht dort ‚Restzeit wird gemessen'
aber messung wird nicht abgeschlossen. Das heißt man hat kein ETA"

Zwei Ursachen, beide unabhaengig, beide toedlich fuer sich allein.

## 1. Die Messreihe lag nur in Redis

`eta.py` schrieb sie ausschliesslich in den Cache — mit der Begruendung im
Modul-Kopf: „Der Cache (Redis) ist schon da". Im Container stimmt das. Auf
einem Windows-PC gibt es kein Redis: `cache_get` gab bei JEDEM Aufruf None
zurueck, `beobachtung_hinzufuegen` legte also jedes Mal eine frische Reihe mit
EINEM Punkt an — und `restzeit_sekunden` braucht `MINDEST_PUNKTE = 2`.

Jetzt wird in beide Ablagen geschrieben: in den Cache, wo es einen gibt (er
ueberlebt einen API-Neustart), und in ein Woerterbuch im Prozess. Das ist ein
paar Zahlen gross, gilt nur fuer die Dauer eines Jobs, und im eigenstaendigen
Betrieb gibt es ohnehin nur diesen einen Prozess. Alte Reihen werden nach
einem Tag weggeraeumt.

## 2. Der Ereignisstrom rechnete die Restzeit gar nicht

Die Rechnung stand nur in `/jobs`. Der SSE-Schnappschuss baute seine Jobs mit
dem nackten `_job_row_to_model` — also ohne Restzeit. **Seit der Umstellung
auf den Ereignisstrom (V2-3) liest die Oberflaeche aber genau diesen
Schnappschuss und nicht mehr `/jobs`.** Die Restzeit wurde also brav berechnet
und niemandem gezeigt.

Beides jetzt in `jobs_fuer_ui()` — dieselbe Lehre wie bei
`laufwerke_mit_disc` heute frueh: Eine Auskunft in zwei Fassungen ist eine
Fassung zu viel.

Nebenbei: Unlesbare Einstellungen duerfen die Jobliste nicht umwerfen. Seit
sie auch den Schnappschuss baut, haengt daran die ganze Oberflaeche — zwei
Snapshot-Tests wurden davon prompt rot.

## Beweis

Job in der Datenbank, Fortschritt 10 % -> 25 % ueber 130 s:

    nach 1. Messpunkt : eta_text=''            (richtig, eine Messung reicht nicht)
    nach 2. Messpunkt : 674 s, „noch ca. 11 min"

877 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 15:49:59 +02:00
HitonabiandClaude Opus 5 aeb3128a85 fix(windows): Dauerscan der Disc, aufblitzende Fenster, Docker-Einstellung uebernommen
Ampel / ampel (push) Successful in 1m30s
Commander: „liest er die disc NOCHMAL ein das macht aber keinen sinn, wenn er
sie bereits erkannt hat. Außerdem öffnen sich nun immer irgendwelche fenster
ganz kurz im hintergrund."

## Beides war dieselbe Schleife

In der Disc-Wache stand:

    except OSError:
        continue

Damit blieb `bekannt[pfad]` ungesetzt, und im naechsten Durchlauf war
`vorher is None` — also wieder „Erststart, liegt schon eine Disc drin". **Ein
einziger fehlgeschlagener Lesevorgang loeste einen neuen Vor-Scan aus.**

Und der scheitert regelmaessig: Waehrend der Vor-Scan laeuft, haelt
makemkvcon das Laufwerk (gemessen: /devices braucht dann 14 s statt 5). Also
Scan haelt das Laufwerk -> Statusabfrage scheitert -> naechster Durchlauf
haelt es fuer den ersten -> neuer Scan. Eine Schleife, die sich selbst am
Leben haelt.

Und weil derselbe makemkvcon-Aufruf in `prescan.py` als EINZIGER kein
`creationflags=OHNE_FENSTER` hatte, blitzte bei jeder Runde eine Konsole auf.
Das war meine Zeile von heute Vormittag.

Die Entscheidung steckt jetzt in `disc_entscheidung()` — pure Funktion, also
ohne Laufwerk pruefbar. Zwei getrennte Fragen statt einer: Haben wir dieses
Laufwerk je gelesen, und was war zuletzt drin? Ein Fehlschlag beantwortet die
zweite nicht und darf die erste nicht zuruecksetzen.

Nachgemessen: Ein Tabwechsel loest KEINEN neuen Scan aus (8 Erkennungen
vorher, 8 nachher). Meine erste Zaehlung von „7 vs 8" war ein Messfehler —
zwei verschieden grosse Abfragefenster.

## Aus dem Docker-Betrieb uebernommen

`docker/worker/entrypoint.sh` setzt vor jedem Worker-Start zwei Dinge:
`app_Key` und `app_UpdateEnable`. Der Key war schon uebernommen, die zweite
nicht — auf dem Rechner des Commanders nachgesehen: NICHT gesetzt.

Das ist MakeMKVs Web-Kontakt; darueber holt es die Disc-Schluessel fuer
4K-UHD nach (Meldung 3338, auf Windows gemessen). „Fuer Windows umschreiben"
heisst hier: Registry statt settings.conf, DWORD statt Text — die
Nachbarwerte (`app_BackupDecrypted`) zeigen die Form.

Gesetzt wird NUR, was fehlt: Wer den Web-Kontakt bewusst abgeschaltet hat,
behaelt ihn abgeschaltet. Ein Waechter-Test vergleicht kuenftig die
`app_*`-Namen aus der entrypoint.sh gegen die Windows-Seite — sonst driften
die beiden Betriebe auseinander.

871 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 15:30:29 +02:00
HitonabiandClaude Opus 5 f0d39b4d04 docs(savepoint): laufende Disc-Erkennung sichtbar, verwaiste makemkvcon notiert
Ampel / ampel (push) Successful in 1m12s
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 15:13:43 +02:00
HitonabiandClaude Opus 5 e67138e9ca feat(ui): Laufende Disc-Erkennung ist jetzt sichtbar
Ampel / ampel (push) Successful in 1m26s
Commander: „das die disc erkennung noch läuft muss sichtbar sein"

Er hat recht, und die Wartezeit ist gemessen: `makemkvcon info` laeuft an
einer Blu-ray in seine 120-Sekunden-Grenze (Disc nach 119 s erkannt). Zwei
Minuten, in denen NICHTS zu sehen war — weder die Disc noch ein Hinweis. Das
sah aus wie ein leeres Laufwerk, also wie ein Fehler.

## Der Zustand war da, er wurde nur weggeworfen

`_auto_prescan` legt beim Start `{"_laeuft": True}` in den Vorrat.
`laufwerke_mit_disc` liess so einen Eintrag KOMPLETT weg — damit keine
halbfertige Disc-Karte mit „Wird erkannt…" als Titel und einem „Rippen
starten"-Knopf erscheint. Richtig gedacht, falsch geloest.

Jetzt gibt es ein eigenes Feld `disc_wird_erkannt`. Die Oberflaeche kann
„wird gelesen" zeigen, ohne einen Titel zu behaupten, den es noch nicht gibt:
eine Karte mit Spinner ueber der Laufwerksliste und eine eigene Zeile im
Server-Status.

## Und der Haken dahinter

Genau waehrend der Erkennung ist die Laufwerks-Auskunft am teuersten:
makemkvcon haelt das Laufwerk, und `device_info` wartet mit. Gemessen:

    /devices waehrend des Scans     14,0 s
    Zeitgrenze des Schnappschusses   5,0 s   ->  devices = None

`None` heisst „konnte nicht nachsehen", und die Oberflaeche behaelt dann
ihren Stand — nach einem frischen Laden also GAR NICHTS. Die Anzeige waere
ausgerechnet in ihrer eigenen Phase leer geblieben.

`laufwerke_notdurft()` antwortet deshalb ohne ioctl: letzter bekannter Stand
plus die aktuelle Erkennungs-Marke aus dem Vorrat. Beim Kaltstart wenigstens
der Laufwerksname — die LISTE der Laufwerke ist billig, teuer ist erst das
Anfassen. Nichts wird erfunden: kein Typ, kein Modell. Und wer noch nie
erfolgreich gelesen hat, schweigt weiter mit `None`.

Im Browser gegengeprueft: „Disc wird gelesen — Laufwerk G:" mit Spinner,
Server-Status „Disc wird gelesen — das dauert bis zu zwei Minuten", danach
der richtige Titel.

859 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 15:12:35 +02:00
HitonabiandClaude Opus 5 dbb934d146 docs(savepoint): v4.0-rc7 — Drueberinstallieren, Linux-Reste, Ordner-Waehler, Jobzeile
Ampel / ampel (push) Successful in 1m9s
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 15:01:34 +02:00
HitonabiandClaude Opus 5 7b0c41ddfe fix(ui): Datum 1.1.1970, Disc nicht erkannt, kein Abbrechen — eine Ursache je Fall
Ampel / ampel (push) Successful in 1m16s
Vier Befunde aus einem Bildschirmfoto vom 29.08.2026.

## 1. „das Datum ist falsch" — und der Typ auch

    TYP „DISC"   STARTZEIT „1.1.1970, 01:00:00"   STATUS „running"

⚠️ Das war MEIN Fehler von heute Vormittag. Ich hatte `type`, `device` und
`startTime` in das Job-Ereignis aufgenommen — mit Feldnamen, **die es in der
Datenbankzeile nicht gibt**. Dort heissen sie `disc_type` und `created_at`;
die Uebersetzung macht `_job_row_to_model`, und sie bildet auch `running` auf
`processing` ab.

Die Folge war schlimmer als das Problem davor: Statt eines FEHLENDEN Feldes
kam ein LEERES. `new Date(null)` ist der 1.1.1970, und „DISC" war der
Rueckfall, den ich zwei Stunden vorher fuer genau diesen Fall eingebaut hatte.
Aus „offensichtlich kaputt" war „sieht plausibel aus" geworden.

Und mein Test hat es nicht gefunden, weil ich seine Beispielzeile selbst
erfunden habe — mit meinen falschen Feldnamen. Ein Test, der dieselbe Annahme
macht wie der Code, prueft nichts. Der neue geht von der ECHTEN Zeile aus.

Der Waechter bekommt jetzt dieselbe Uebersetzung eingespritzt, die auch
`/jobs` benutzt.

## 2. „Es ist eine Disk im laufwerk, aber er erkennt sie dort nicht"

Die Laufwerksliste wurde an DREI Stellen gebaut: `/devices` haengte die
erkannte Disc an, der Ereignis-Waechter und der SSE-Schnappschuss nicht. Das
Dashboard liest den Schnappschuss — und schloss aus der fehlenden Disc auf ein
leeres Laufwerk, waehrend ihr Titel eine Zeile weiter oben stand.

Jetzt gibt es `laufwerke_mit_disc()`, und ein Test zaehlt die Aufrufe von
`device_info` — bei zwei ist er rot.

## 3. „man kann einen rip garnicht abbrechen"

Dieselbe Ursache wie 1: Es gab genau EINEN Abbrechen-Knopf, in der Kachel
„laufender Job". Die erscheint nur bei Status `processing`; der Strom lieferte
`running`. Keine Kachel, kein Knopf, kein Weg zurueck — und aus demselben
Grund stand „Aktiv (0)", waehrend der Rip lief.

Zusaetzlich gibt es den Knopf jetzt in der Job-Zeile selbst, wo man ihn sucht.

## 4. „bei ‚Platz für rippy' sollte eher das arbeitsverzeichnis und der
##     Ablagepfad sein"

Dort stand eine nackte Zahl fuer den ERSTEN Ort. Welcher Ordner das war, sah
man nicht — und die zweite Zeile fiel ganz weg, wenn beide auf derselben
Platte lagen. Das stimmt fuer die ZAHL und war der falsche Schluss fuer den
ORT. Jetzt stehen beide da, mit Pfad, plus der Hinweis, dass der Platz
geteilt wird.

Im Browser gegengeprueft: „Disc erkannt — wartet auf ‚Rippen starten'",
BLU-RAY mit richtigem Datum, beide Pfade, keine Konsolenfehler.

852 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 15:00:11 +02:00
HitonabiandClaude Opus 5 b2acddbdfa fix(windows): Drueberinstallieren, Linux-Reste im Windows-Betrieb, Ordner-Waehler
Ampel / ampel (push) Successful in 1m27s
Vier Fragen des Commanders vom 29.08.2026, drei davon mit Codefolge.

## 1. „Was passiert wenn man die Setup.exe einfach drueber installiert?"

Bis hierher: nicht zuverlaessig. Rippy startet mit Windows, laeuft also fast
immer — dann ist `Rippy.exe` gesperrt, `shutil.copy2` warf PermissionError,
und die neue Fassung landete als `Rippy.exe.neu` daneben. Dazu die Meldung
„wird beim naechsten Start uebernommen".

**Diese Zusage hat niemand eingeloest.** `.neu` kam im ganzen Projekt genau
einmal vor: an der Stelle, die es schrieb. Wer drueberinstallierte, behielt
still die alte Fassung, und das Setup meldete Erfolg.

Jetzt wird der laufende Rippy vorher beendet (`dienst_beenden` gibt es seit
der Deinstallation und wartet auch die zwei Sekunden ab, die Windows fuer die
Dateihandles braucht). Eine von einer aelteren Setup-Fassung liegengelassene
`.neu` wird dabei uebernommen. Bleibt die Datei DANN noch gesperrt, gibt es
einen klaren Fehler statt einer Zusage — Rippy im Infobereich beenden und das
Setup erneut starten.

Der Tausch laeuft bewusst im SETUP und nicht beim Dienststart: Windows sperrt
eine laufende .exe, und `Rippy.exe` waere genau die zu ersetzende Datei.

## 3. Linux-Reste im Windows-Betrieb (Docker/Headless unveraendert)

**`caps.py`: `os.path.isdir("/app")`.** Damit hielt sich der eigenstaendige
Windows-Rippy fuer einen FREMDEN Worker — und das UI warnte vor fehlender
Pfad-Uebersetzung auf einer Maschine ohne Container und ohne Freigabe.
„Extern" heisst jetzt, was es meint: Rippy laeuft woanders als dieser Worker.

**`caps.py`: `shutil.which("makemkvcon")` + `os.path.ismount(daten_dir)`.**
Beide unter Windows immer falsch (Programme liegen nicht im PATH, ein
normaler Ordner ist kein Mount). Die Schluessel-Auskunft blieb dauerhaft
„unbekannt", obwohl MakeMKV samt Datenverzeichnis da war. Der Mount-Test
bleibt fuer den Container, wo er einen Zweck hat.

**`rohdaten.py`: `/app/temp/raw` und `/app/media` fest.** Dieses Modul findet
die Rohdaten eines Jobs wieder — fuer den Wiederholen-Dialog und fuer
„Rohdaten mitloeschen". Unter Windows fand es NIE etwas: Der Dialog meldete
„keine Rohdaten", das Aufraeumen loeschte nichts, und die Bruchstuecke eines
abgebrochenen Rips blieben liegen (bei 4K-UHD bis 100 GB).

Sieben Tests wurden dabei rot, und zwar zu Recht: Sie pruefen Container-Regeln,
liefen aber unter Windows. Die Wurzeln sind jetzt einspritzbar — beide
Betriebsfaelle auf jedem Rechner pruefbar statt vom laufenden abhaengig.

## 4. „Der Durchsuchen button fehlt. Wie es der Installer auch macht"

Neu: `OrdnerWaehler` — Pfadfeld plus „Durchsuchen …", benutzt fuer Ablage und
Arbeitsverzeichnis. Es waere der DRITTE fest eingebaute Ordner-Browser
geworden (RipTargetModal, StorageMounts); dieser hier ist wiederverwendbar.
`/browse` weiss seit dem 28.08. selbst, in welchem Betrieb es laeuft.

⚠️ Beim Einbau fiel der Import unter den Tisch. `vite` pruefte das NICHT — das
Buendel blieb byte-gleich gross, und zur Laufzeit waere es der naechste leere
Bildschirm gewesen. Aufgefallen nur, weil die erwartete Anzahl Ersetzungen
nicht stimmte. Im Browser gegengeprueft: alle sieben Laufwerke, Navigation in
D:\, keine Konsolenfehler.

843 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 14:28:01 +02:00
HitonabiandClaude Opus 5 21b1757aa4 docs(savepoint): v4.0-rc6 — leerer Bildschirm und zwei weitere Container-Wurzeln
Ampel / ampel (push) Successful in 1m43s
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 14:15:58 +02:00
HitonabiandClaude Opus 5 423374e65a fix(windows): Roh- und Zielordner landeten in einem Ordner namens „app"
Beim Nachstellen des leeren Bildschirms lief ein echter Test-Rip durch. Die
Rohdaten landeten in:

    F:\app\temp\raw\<job>\Evangelion 2.22_t00.mkv   (436 MB)

Also in einem Ordner namens `app` auf dem Laufwerk, von dem Rippy gerade lief.

## Zwei Container-Wurzeln im Worker

    RAW_DIR    = /app/temp/raw
    MEDIA_ROOT = /app/media

Unter Windows sind das keine Pfade, sondern Unfaelle. Schlimmer: Die Pruefung
`unter_wurzel(wahl, MEDIA_ROOT)` verwarf auch eine AUSDRUECKLICHE Wahl — ein
Arbeitsordner wie `D:\Roh` liegt nicht unter `/app/media`, also fiel er still
auf den Container-Standard zurueck.

**Damit kam der Arbeitsordner, den der Commander am 28.08.2026 ausdruecklich
bestellt hat, unter Windows nie an.** Der Dialog zeigte ihn, das Setzen ging,
und der Worker ignorierte ihn — ohne ein Wort. Dasselbe galt fuer das Ziel:
Eine UNC-Freigabe liegt unter gar keiner lokalen Wurzel, also waere die
fertige Datei in `X:\app\media\bluray` gelandet.

## Die Wurzeln kommen jetzt aus dem Betrieb

Im Container aendert sich NICHTS: dort ist `/app/media` die Wurzel und `frei`
falsch. Nativ zaehlt die Wahl des Nutzers — dort IST sein Laufwerk die Grenze.

Die drei bestehenden Tests wurden rot, und zwar zu Recht: Sie pruefen die
Container-Regel, liefen aber unter Windows, wo `frei` gilt. Die Wurzeln sind
deshalb einspritzbar — beide Betriebsfaelle sind jetzt auf jedem Rechner
pruefbar, statt vom laufenden abzuhaengen.

837 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 14:15:17 +02:00
HitonabiandClaude Opus 5 27c9d9a4bb fix(ui): Leerer Bildschirm nach „Rippen starten" — ein halber Job riss alles mit
Commander: „wenn man auf rippen starten klickt passiert irgendwas, was das
Programm nicht mag. Der Hintergrund ist einfach leer und er startet nix. Es
gibt auch keine fehlermeldung."

Nachgestellt: Dienst lokal gestartet, Disc-Karte geoeffnet, „Rippen starten"
geklickt. Browser-Konsole:

    TypeError: Cannot read properties of undefined (reading 'toUpperCase')

## Er startet sehr wohl — man sieht es nur nie

Waehrend die Seite leer war, lief der Job (per API gemessen: status
`processing`, progress 12). Das „er startet nix" ist also der zweite Teil
desselben Fehlers: Die Oberflaeche war weg, bevor sie ihn zeigen konnte.

## Die Ursache

`_job_kurz` in `bus/waechter.py` trug nur `status`, `progress`, `title` und
`error` — **keinen `type`**. Das UI fuegt aus `job.created` einen halben Job
in seine Liste ein, `LiveLogSection` liest `job.type.toUpperCase()`, und React
baut bei einem Fehler im Zeichnen den GESAMTEN Baum ab. Es gab in diesem
Projekt keine einzige Fehlergrenze — also blieb ein leerer Bildschirm ohne
jede Meldung.

## Drei Reparaturen, weil es drei Fehler waren

1. **Das Ereignis traegt den Job.** `type`, `device` und `startTime` fahren
   mit. Sie aendern sich ueber die Lebenszeit eines Jobs nie, kosten also kein
   zusaetzliches Ereignis — und ohne `startTime` stand in der Jobliste
   sekundenlang „Invalid Date".
2. **Das UI vertraegt sein Fehlen.** `LiveLogSection` und `TypeBadge` nahmen
   einen vollstaendigen Job an. Zeile 108 derselben Datei hatte das
   Fragezeichen laengst, Zeile 48 nicht.
3. **Eine Fehlergrenze.** Ein Fehler in einer Karte darf nicht den ganzen
   Bildschirm mitnehmen — und schon gar nicht schweigend. Jetzt steht da, was
   los ist, die Navigation bleibt bedienbar, und der Hinweis sagt das
   Wichtigste: laufende Rips gehen weiter.

## Warum es niemand gefunden hat

`unterschiede()` bekommt die Kurzform schon fertig, und alle Tests reichen
ihre eigenen Woerterbuecher herein. **`_job_kurz` selbst war nie geprueft.**
Jetzt bewacht `UI_PFLICHTFELDER` den Vertrag mechanisch — es gibt kein
gemeinsames Typsystem zwischen Python und dem UI.

Gegengeprueft im Browser: derselbe Klick, keine Konsolenfehler, Job erscheint
als „Alle (1)".

833 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 14:10:12 +02:00
HitonabiandClaude Opus 5 d9780a4951 docs(savepoint): v4.0-rc5 — Rippy rippt, drei Fehler im Rip-Pfad behoben
Ampel / ampel (push) Successful in 1m38s
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 13:52:52 +02:00
HitonabiandClaude Opus 5 954f293871 fix(windows): Rippen ging nicht — drei Container-Annahmen im Rip-Pfad
Commander: „Das Rippen der disk funktioniert nicht. makemkvcon endete mit
Code 11 — letzte Meldung: Das Öffnen der Disk schlug fehl — keine MKV-Datei
entstanden"

In diesem einen Satz steckten drei Fehler. Alle drei an seinem Laufwerk
gemessen, nicht hergeleitet.

## 1. Die Quellenangabe — das war der Abbruch

    dev:\.\G:  MSG:2024 „Unknown device" -> MSG:5010 Öffnen schlug fehl
    dev:G:      68 TINFO-Zeilen, „Die Aufgabe wurde erfolgreich abgeschlossen"

`f"dev:{device_path}"` stand an VIER Stellen. Unter Linux richtig (/dev/sr0),
unter Windows nicht: `rippy.drives.windows` meldet den Geraete-Namensraum
`\.\G:`, den `CreateFileW` fuer die IOCTLs braucht — MakeMKV kennt ihn
nicht.

## 2. „Ö" statt „Ö"

`Ö` als UTF-8 (C3 96), gelesen als cp1252. `subprocess` stand auf `text=True`
ohne `encoding=`, nahm also die Gebietsschema-Kodierung; Rippy stellt seine
Konsole beim Start aber auf UTF-8 (sonst stirbt der Start an einer
Umlaut-Logzeile). Direkt gemessen kommen die Bytes je nach Umgebung als UTF-8
ODER cp1252 — deshalb wird jetzt bestimmt statt behauptet.

## 3. Die Ursache fehlte im Fehlertext

Gesucht wurde nach ENGLISCHEN Textbausteinen („evaluation period has
expired"). Auf einem deutschen Windows trifft keiner. Jetzt zaehlen die
Meldungs-NUMMERN, die sprachunabhaengig sind.

⚠️ Beim ersten Anlauf hatte ich 5021 aus dem Kopf mit „Volume-Key unbekannt"
beschriftet — falsch. Meine eigene Ausgabe zeigte nur meine Beschriftung
statt MakeMKVs Text, sodass es fast durchgegangen waere. Der echte Wortlaut
steht jetzt im Code.

## Nebenbefund: der Beta-Key lag zweimal am falschen Ort

`makemkv_daten.DATEN_DIR` war fest `/root/.MakeMKV`. Nach der Reparatur des
Ordners blieb MSG:5051 trotzdem stehen — weil MakeMKV unter Windows seine
Einstellungen in der REGISTRY haelt (HKCU\Software\MakeMKV), nicht in einer
settings.conf. Nachgesehen statt vermutet.

Und der wichtigste Teil davon: **Ein abgelehnter Schluessel ist schlimmer als
gar keiner.** Ohne Key las MakeMKV die Disc noch (68 TINFO), mit dem
abgelehnten verweigerte es alles (0 Titel). Deshalb wird jetzt geprueft und
bei Ablehnung zurueckgenommen.

## Beweis

Echter Rip ueber `ripping.run_makemkv`, kuerzester Titel:

    Status success, Code 0, „Evangelion 2.22_t03.mkv" 217,9 MB
    5036 „Das Kopieren wurde abgeschlossen. 1 Titel wurden gesichert."

828 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 13:52:06 +02:00
HitonabiandClaude Opus 5 73ed104bbc docs(savepoint): Arbeitsordner im Setup, Beta-Key auf Knopfdruck
Ampel / ampel (push) Successful in 1m15s
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 11:54:18 +02:00
HitonabiandClaude Opus 5 678fe276f9 feat(windows): Arbeitsordner im Setup, Beta-Key auf Knopfdruck
Ampel / ampel (push) Successful in 1m18s
Zwei Wuensche des Commanders vom 28.08.2026.

## 1. „kannst du noch einbauen das man den arbeitsordner usw. in den
##     Einstellungen setzen kann und direkt im setup?"

In den Einstellungen ging es seit 35370fd (freies Pfadfeld plus die Laufwerke
als Ein-Klick-Wahl). Im SETUP wurde bisher nur nach Programmordner und Ablage
gefragt — der Arbeitsordner tauchte erst auf, wenn schon installiert war.

Das ist die falsche Reihenfolge: Der Roh-Rip einer 4K-UHD ist bis zu 100 GB
gross. Wer erst NACH der ersten vollen Platte erfaehrt, wo die liegen, hat es
zu spaet erfahren — genau so lief am 25.07.2026 die VM-Platte voll.

Neu ist auch ein Waechter, der alle drei Arten von halb angeschlossenem Feld
faengt (kein Eingabefeld, keine Vorbelegung, wird beim Installieren nicht
mitgeschickt). Der dritte Fall ist der gemeinste: Man waehlt etwas, es
passiert nichts, und niemand sagt warum.

## 2. „der könnte theoretisch auch automatisch ausgelesen werden, ich glaube
##     das web rippy kann das"

Er hatte recht. `makemkv_key.refresh_loop()` laeuft seit jeher taeglich mit
(main.py, Startereignis). GEMESSEN am 28.08.2026: Forum antwortet in 3,3 s,
gueltiger Key mit 62 Zeichen, und in seinen Einstellungen lag bereits einer.

Es war nur nichts davon zu sehen. Kein Knopf, keine Meldung, keine Zeitangabe
— im Feld stand ein Key, und ob der von Hand kam oder von selbst, wusste
niemand. Eine Automatik, die man nicht sehen kann, ist fuer den Benutzer
keine.

Dazu kam eine echte Luecke: Die Schleife startet 60 Sekunden nach dem Server.
Wer gleich nach dem Einrichten eine Blu-ray einlegt, rippt ohne Key — MakeMKV
faellt in den 30-Tage-Testmodus. Das Setup holt ihn jetzt selbst.

Der geholte Key wandert NICHT ueber die Leitung zurueck: Er steht in den
Einstellungen, und ein zweiter Weg zu demselben Wert ist ein zweiter Weg, ihn
zu verlieren.

Rechtlich unveraendert: oeffentliche Beta-LIZENZ der Software, KEIN
Disc-Schluessel. Rippy liefert und verteilt keine Disc-Schluessel.

803 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 11:53:12 +02:00
HitonabiandClaude Opus 5 d0281f7a1b style: Zeilenenden zurueck auf LF (kein Inhalt geaendert)
In 35370fd habe ich fuenf Dateien versehentlich von LF auf CRLF umgestellt.
Der Inhalt stimmte, aber der Diff war unlesbar: 1363 geaenderte Zeilen fuer
30 echte in RipTargetModal.tsx, 1184 fuer 29 in setup_fenster.py. Nachgewiesen
mit `git diff --ignore-cr-at-eol` — damit blieben 56/9 uebrig.

Ursache: Ein Rueckschreiben im Textmodus stellt die ganze Datei um. Die Regel
stand als Warnung schon in meinem Gedaechtnis, dort aber nur in der anderen
Richtung (CRLF -> LF). Sie gilt in beide.

Dieser Commit aendert AUSSCHLIESSLICH Zeilenenden. Nachgewiesen:
`git diff --ignore-cr-at-eol` listet keine dieser fuenf Dateien.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-29 11:52:08 +02:00
HitonabiandClaude Opus 5 6881a63fb7 docs(savepoint): v4.0-rc4 — Cover, Arbeitsverzeichnis, aufgeraeumte Temp-Ordner
Ampel / ampel (push) Successful in 55s
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 16:45:52 +02:00
HitonabiandClaude Opus 5 35370fd552 fix(windows): Cover, Arbeitsverzeichnis und die zurueckgelassenen _MEI-Ordner
Drei Befunde des Commanders vom 28.08.2026, alle drei gemessen.

## 1. „Was ist mit dem Cover auf Windows Rippy?"

Es gab keins, weil es keinen Treffer gab. `_scan_video` verlangte woertliche
Gleichheit:

    if movie.get("title", "").lower() == kandidat.lower():

An seiner Disc gemessen:

    'Evangelion 2.22'    1 Treffer   Evangelion: 2.0 You Can (Not) Advance
    'Evangelion'        20 Treffer   irgendein Evangelion

Der EINZIGE Treffer auf den vollen Disc-Titel war der richtige Film, mit
Poster — und wurde verworfen. Jetzt zaehlt die SPEZIFITAET der Anfrage: Wer
auf den vollen Disc-Titel hoechstens drei Treffer bekommt, hat gefragt wie
jemand, der weiss was er sucht. Ergebnis an derselben Disc:

    Evangelion: 2.0 You Can (Not) Advance / 2009 / 80 % / Poster + dt. Text

## 2. „Warum heisst das hier noch container platte? … Waere es moeglich das
##     Arbeitsverzeichnis zu aendern? momentan geht das nicht."

Beide Haelften gehen auf EINE Zeile zurueck: `MEDIA_ROOT = "/app/media"` war
zugleich Vorgabe UND Pfadgrenze. Auf Windows gibt es den Ordner nicht:

* `/storage-targets` fing den OSError und gab still [] zurueck — die Auswahl
  hatte genau einen Eintrag. Das ist „momentan geht das nicht".
* Dessen Text war fest verdrahtet „(Container-Platte)".
* `/browse` antwortete auf jeden Pfad mit 422.

Die Grenze faellt nicht weg, sie wird betriebsabhaengig: Container und
Kopflos-Betrieb bedienen ein Netz, die native App den Menschen davor.
Gemessen auf seinem PC: 7 Laufwerke zur Auswahl, X/Y/Z mit je 2,2 TB frei.

## 3. „Failed to remove temporary directory: …_MEI0000b0882"

GEMESSEN: 20 zurueckgelassene _MEI-Ordner mit 1,1 GB. Ursache: `Popen` ohne
`env=` reicht PyInstallers Auspack-Zeiger an die Kinder weiter (--dienst und
--oeffnen). Beide laufen dann im Ordner des Elternprozesses, der sich zuerst
beendet und ihn loeschen will. Waere das TEILWEISE geglueckt, haetten Dienst
und Fenster mitten im Betrieb ihre Dateien verloren.

Nebenbefund: test_setup_fenster scheiterte in jeder Umgebung ohne pywebview.

794 Tests gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 16:43:41 +02:00
HitonabiandClaude Opus 5 11001a443e docs: SAVEPOINT v4.0-rc3 — Windows testbereit
Ampel / ampel (push) Successful in 55s
Stand vor dem Test des Commanders. Zwei Dinge stehen bewusst gross drin:
die seit V2-1 tote Metadaten-Suche (betrifft die VM genauso) und die
bekannte Luecke bei Audio-CDs unter Windows.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 16:09:24 +02:00
HitonabiandClaude Opus 5 be3fac53af fix(prescan): makemkvcon ueber den Katalog suchen, nicht ueber shutil.which
Ampel / ampel (push) Successful in 55s
Auf die Frage des Commanders: "du hast jetzt nur mein laufwerk analysiert
oder? wenn ich rippy weitergebe wie laeuft es dort?"

Berechtigt -- und beim Nachsehen fiel derselbe Fehler auf wie heute Vormittag
im Werkzeug-Katalog:

    shutil.which("makemkvcon")   ->  None, auch bei installiertem MakeMKV

`which` sucht nur im PATH. Windows-Programme liegen in "Programme". Der
Zweig, der die Titelliste von makemkvcon holt, lief unter Windows also NIE --
unabhaengig vom Laufwerk, auf jedem Rechner. Jetzt ueber
`katalog.finden("makemkv")`, das genau dafuer da ist.

Dazu vier Tests fuer Disc-Arten, die ICH NICHT HABE, damit die Zusage nicht
an einer einzigen Disc haengt:

    Blu-ray ohne BDMV/META   -> None (sehr haeufig; Rueckfall aufs Label)
    DVD (nur VIDEO_TS)       -> None
    bdmt_deu.xml vorhanden   -> Titel wird gelesen
    deu + eng vorhanden      -> eng gewinnt (APIs suchen damit besser)

Und ein Waechter gegen shutil.which in prescan.py. Der erste Anlauf davon
fiel ueber den eigenen Erklaertext, in dem der alte Aufruf zitiert wird --
er prueft jetzt nur Code, keine Kommentare.

Ampel lokal: 774 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 16:05:25 +02:00
HitonabiandClaude Opus 5 878b24c43b fix: die Metadaten-Suche war seit V2-1 tot — auf Windows UND auf der VM
Ampel / ampel (push) Successful in 54s
Der Commander: "TMDB und OMDB Key sind hinterlegt, das laufwerk wird aber
auch nicht korrekt ausgelesen. Eigentlich sollte er direkt bei TMDB oder OMDB
oder JIKAN anfragen nach metadaten."

Er hat das Symptom gemeldet. Darunter lagen VIER Fehler.

## 1. Ein Phantom-Modul (der schwerste)

    clients/tmdb.py:27     from db import get_settings
    clients/omdb.py:36     from db import get_settings
    clients/thetvdb.py:16  from db import get_settings

`docker/api/db.py` gibt es seit der Zusammenlegung in V2-1 (dd1d0b7) nicht
mehr; main.py schreibt seitdem `from rippy import store as db`. Diese drei
Module haben es nie mitbekommen.

Damit starb JEDE Metadaten-Abfrage schon beim Erzeugen des Clients mit
ModuleNotFoundError -- und `_auto_prescan` verschluckte das in seinem
`except Exception`. Die Disc blieb namenlos, und niemand sah warum.

**Das betrifft die VM genauso.** Sie steht auf 05ab655, also NACH dd1d0b7 --
dort laeuft seit V2-1 dieselbe tote Metadaten-Suche.

## 2. Redis war Pflicht statt Beschleunigung

`cache/cache.py` sprach `redis:6379` an -- den Dienstnamen aus
docker-compose.yml. Auf einem Windows-PC gibt es kein Redis:

    redis.exceptions.ConnectionError: Error 11001 connecting to redis:6379

Das riss den Pre-Scan mit. Ein Zwischenspeicher ist eine Beschleunigung,
keine Voraussetzung: Jetzt faengt jeder Zugriff den Verbindungsfehler ab und
meldet "nicht vorhanden" -- was der Wahrheit entspricht. Gemeldet wird der
Ausfall EINMAL, nicht bei jeder Anfrage.

## 3. Der Klartext-Titel war unter Windows nicht erreichbar

`read_disc_title_via_mount` machte fest `mount -t udf` -- also Linux. Unter
Windows haengt Windows die Disc selbst ein. An der echten Disc gemessen:

    Volume-Label (UDF)          BD_EVG_D2      <- damit findet keine API etwas
    BDMV/META/DL/bdmt_deu.xml   Evangelion 2.22

`disc_wurzel()` liefert jetzt je Plattform einen lesbaren Einstieg, und
`titel_aus_bdmt()` ist davon getrennt (und damit ohne Disc pruefbar).

## 4. Modell und Seriennummer fehlten

Im UI stand "Modell: unbekannt, Seriennummer: -". Der Linux-Treiber liest
beides aus /sys; der Windows-Treiber lieferte leere Felder. Die Entsprechung
ist IOCTL_STORAGE_QUERY_PROPERTY. An echter Hardware gemessen:

    hersteller     'HL-DT-ST'
    modell         'BD-RE BU40N'
    fassung        '1.03'
    seriennummer   '0025114C0149'

Gemerkt statt jedes Mal abgefragt: Die Disc-Wache ruft device_info alle drei
Sekunden, und die Angaben eines Laufwerks aendern sich nicht.

## Ergebnis, an der eingelegten Disc gemessen

    title        'Neon Genesis Evangelion'
    year         1995
    disc_type    'Blu-ray'
    confidence   0.8
    fingerprint  'BD_EVG_D2|48149364736'

(Jikan antwortete waehrend der Messung mit 504 -- deren Ausfall, nicht
unserer. Der Treffer kam von TMDB.)

Zwei Waechter, beide beim Zurueckdrehen rot gesehen: Die Clients muessen sich
OHNE Datenbank und OHNE Redis bauen lassen, und ein `from db import` in
clients/ faellt mechanisch auf.

Ampel lokal: 769 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 15:59:47 +02:00
HitonabiandClaude Opus 5 ea8a043643 feat(setup): Fortschrittsbalken, MakeMKV-Installer mit Rechteabfrage, Updates
Ampel / ampel (push) Successful in 55s
Drei Punkte des Commanders vom 28.08.2026.

## 1. "bei der installation eine progress bar waere gut"

Die Daten dafuer waren schon da -- der Fortschritts-Rueckruf traegt seit
jeher einen Anteil, die Bruecke warf ihn nur weg.

Jetzt rechnet `Fortschritt` Abschnitt + Teil-Anteil in einen Gesamtstand um.
Die Gewichte sind gemessen: Dateien ablegen 0-8 % (rund drei Sekunden),
Ablage 8-10 %, Werkzeuge 10-97 % (sechs Sekunden bis mehrere Minuten). Ein
Balken, der bei 90 % minutenlang steht, ist schlimmer als gar keiner.

Zwei Regeln, beide mit Test:

* Er laeuft NIE zurueck. Der Werkzeug-Abschnitt kann mehrere Downloads
  enthalten, jeder mit eigenem 0-bis-1 -- ohne die Regel spraenge der Balken
  bei jedem neuen Werkzeug an den Abschnittsanfang. Zusaetzlich rechnet
  `sicherstellen` den Anteil eines Werkzeugs auf die ganze Strecke um.
* Eine Textmeldung ohne Zahl bewegt ihn nicht. Sie ist keine Aussage ueber
  den Fortschritt.

Am laufenden Fenster nachgewiesen: "Werkzeuge werden geprueft -- 36 %",
Balken bernsteinfarben, am Ende gruen bei 100 %.

## 2. "make MKV laesst sich nicht installieren weil der vorgang erhoehte
##     rechte benoetigt"

Der Kern, und der Fehler lag bei uns: `subprocess.Popen` benutzt
`CreateProcess`, und das ZEIGT KEINE UAC-Abfrage -- es bricht mit
ERROR_ELEVATION_REQUIRED (740) ab. MakeMKV installiert nach Program Files und
fordert im Manifest Administratorrechte an.

`ShellExecuteW` ist der dokumentierte Weg, der die Abfrage ausloest. Damit
braucht NUR dieser eine Aufruf die Erhoehung.

Und deshalb laeuft das Setup NICHT dauerhaft erhoeht (dazu die Antwort im
Chat): Ein erhoehter Prozess sieht die eingebundenen Netzlaufwerke nicht --
auf diesem Rechner gemessen, X:, Y:, Z: ohne Erhoehung sichtbar,
EnableLinkedConnections nicht gesetzt. Genau das hatte der Commander vorher
selbst als Fehler gemeldet. Wer trotzdem erhoeht starten will, bekommt einen
Knopf -- aber nur, wenn das Schreibrecht am gewaehlten Ziel wirklich fehlt.

## 3. "wenn MakeMKV oder Handbrake schon installiert sind ein update
##     verfuegbar ist. Das kann ja direkt im setup abgehandelt werden."

`veraltete()` vergleicht nach ZAHLEN (ein Zeichenvergleich hielte 1.9.2 fuer
neuer als 1.11.2 -- und HandBrake ist genau dort). `sicherstellen` holt sie
auf Wunsch mit, aber IMMER nach den fehlenden: Ein Update ist Komfort, ein
fehlendes Pflichtwerkzeug ist ein Hindernis.

Der Assistent zeigt es als eigenen Schalter mit Klartext ("MakeMKV 1.18.2 ->
1.18.4"). Der Update-Check laeuft als GETRENNTER Aufruf nach der
Voraussetzungs-Pruefung: Er kostet Netz, und makemkv.com braucht dafuer im
schlimmsten Fall gut zwanzig Sekunden -- in der Pruefung bliebe das Fenster
so lange leer. Sind die Quellen nicht erreichbar, schaltet sich der Haken ab
und sagt warum; ein Haken, der nichts tun kann, ist eine Falle.

Ampel lokal: 758 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 15:38:51 +02:00
HitonabiandClaude Opus 5 95beb91364 feat(tools): Ausweichquellen fuer MakeMKV — recherchiert und gemessen
Ampel / ampel (push) Successful in 1m1s
Commander: "bitte baue fuer MakeMKV fallback seiten ein."

Anlass war ein echter Ausfall. Am 28.08.2026 gemessen:

    https://www.makemkv.com/download/   HTTP 525   (dauerhaft)
    https://makemkv.com/download/       HTTP 525
    http://www.makemkv.com/download/    HTTP 403
    https://forum.makemkv.com/          200 / 522 / Zeitablauf (wechselnd)
    web.archive.org/web/2025id_/...exe  200, 16.432.607 Bytes

525/522 heissen: Cloudflare erreicht den Ursprungsserver nicht. Eine Stoerung
beim Hersteller -- dieselbe, die im Projekt schon einmal jeden Worker-Build
lahmgelegt hat.

## Die Kette

Version:  Hersteller-Seite (massgeblich) -> Forum-Ankuendigungen -> Archiv
Datei:    eigene Quelle -> Hersteller -> Internet Archive

Der Hersteller zuerst, immer. Das Archiv ist Rueckfallebene, und Rippy nennt
hinterher die Quelle, aus der die Datei kam.

Zwei Feinheiten, beide aus Messungen statt aus dem Kopf:

* Die HOECHSTE Nummer gewinnt, nicht die erste. Antwortet das Forum nicht,
  meldet das Archiv einen aelteren Stand (1.18.2 statt 1.18.4) -- "neueste
  Fassung" waere dann eine falsche Aussage.
* Ein zweiter Anlauf, mit knapper Zeitgrenze. Drei Abrufe am Forum:
  TimeoutError, HTTP 522, dann Erfolg. Ohne Wiederholung fiel die Quelle in
  zwei von drei Faellen aus; mit 20-Sekunden-Grenzen dauerte der schlimmste
  Fall 46 Sekunden, in denen das Setup eingefroren aussah. Jetzt acht
  Sekunden je Versuch, schlimmstenfalls gut zwanzig.

## Warum eine fremde Quelle trotzdem sicher ist

Der naheliegende Schutz geht NICHT: MakeMKV signiert seinen Installer nicht
(Get-AuthenticodeSignature -> NotSigned, an der echten Datei gemessen). Eine
Signaturpruefung waere eine, die immer fehlschlaegt -- schlimmer als keine,
weil sie Sicherheit vortaeuscht.

Geprueft wird die Versions-Ressource, ebenfalls gemessen:

    CompanyName      GuinpinSoft inc
    FileDescription  MakeMKV installer
    FileVersion      v1.18.4

Das ersetzt keine Signatur, faengt aber ab, was hier wirklich droht: eine
Fehlerseite mit .exe-Namen, ein abgebrochener Download, eine falsche Fassung.

Ende zu Ende nachgewiesen, ohne etwas zu installieren:

    Version laut Kette: 1.18.4
    Hersteller:         HTTP 525 -> uebersprungen
    Internet Archive:   15,7 MB in 6,1s
    Pruefung:           BESTANDEN (MakeMKV v1.18.4)

Die Grenze aus KONZEPT.md 6 bleibt: Rippy liefert MakeMKV weiterhin NICHT
mit. Es holt die Datei des Herstellers -- im Rueckfall aus einem Archiv, das
genau diese Datei aufbewahrt.

Ampel lokal: 733 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 15:19:46 +02:00
HitonabiandClaude Opus 5 480b658294 fix: die Laufwerks-Pruefung muss selbst einspritzbar sein
Ampel / ampel (push) Successful in 54s
Ampel-Lauf zu 16df61e rot, und diesmal am Gegenteil:

    assert 'Administratorrechte' in 'Statt des Laufwerksbuchstabens den
    UNC-Pfad eintragen (\Server\Freigabe).'

`pfade.laufwerk_von` zerlegte den Windows-Pfad jetzt richtig -- aber
`os.path.isdir("C:\")` ist auf Linux immer False, also galt JEDES Laufwerk
als fehlend und der falsche Zweig griff.

Die Frage "existiert Laufwerk Q:" laesst sich auf dem Linux-Runner
ueberhaupt nicht beantworten, dort gibt es keine Laufwerksbuchstaben. Also
gehoert sie in eine eigene, einspritzbare Funktion (`laufwerk_fehlt`) --
ohne die waere der Zweig nur auf einem Windows-Rechner mit genau diesem
fehlenden Laufwerk pruefbar, also nirgends.

Dieselbe Lehre wie bei pruefe_windows heute Vormittag: **Ein
Plattform-Vergleich mitten in einer Funktion macht jeden Einspritzpunkt
davor wertlos.**

Vor dem Push den Linux-Fall lokal nachgestellt (os.name auf "posix"
gesetzt): Program Files, Programme und ein fehlendes Q: landen jetzt alle
im richtigen Zweig.

Ampel lokal: 715 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 14:56:10 +02:00
HitonabiandClaude Opus 5 16df61ea3a fix: pruefe_schreibrecht nahm os.path statt pfade — zum vierten Mal dieselbe Falle
Ampel / ampel (push) Failing after 54s
Ampel-Lauf zu 3d5f82b rot:

    assert 'nicht vorhanden' in 'Q:\Rippy (Pfad nicht gefunden)'

`os.path.splitdrive` kennt auf Linux kein "Q:" und gab einen leeren String
zurueck, also fiel die Pruefung in den allgemeinen Zweig. Genau dafuer gibt
es seit einer Stunde `rippy/pfade.py` -- und ich habe es hier nicht benutzt.

Das ist das vierte Vorkommen desselben Musters an einem Tag (katalog,
verknuepfungen, betrieb, jetzt einrichtung). Die Regel steht im Kopf von
pfade.py und gilt ohne Ausnahme: **Der Pfad entscheidet, nicht der Rechner.**

Gegengeprueft, dass es keine fuenfte Stelle gibt: kein os.path.splitdrive und
kein direkter ntpath-Aufruf mehr ausserhalb von pfade.py.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 14:53:26 +02:00
HitonabiandClaude Opus 5 3d5f82b786 fix(windows): der Deinstallierer beendet jetzt auch den laufenden Dienst
Ampel / ampel (push) Failing after 54s
Beim Deinstallieren im laufenden Betrieb blieben liegen:

    rippy.db, rippy.db-shm, rippy.db-wal
    (Der Prozess kann nicht auf die Datei zugreifen, da sie von einem
     anderen Prozess verwendet wird)

Der Dienst lief weiter und hielt die Datenbank offen. Damit waere der Fehler
von vorhin durch eine andere Tuer zurueckgekommen: Die naechste Installation
haette wieder den alten Zustand samt setup.done geerbt, und der
Ersteinrichtungs-Assistent waere wieder verschwunden.

Aufgefallen ist es nur, weil der Deinstallierer seit heute NENNT, was er
nicht wegbekommen hat. Vorher stand dort ein `except OSError: pass` und die
Meldung "Rippy wurde entfernt".

Gefiltert wird ueber den Installationsordner, nicht ueber den Namen:
`Rippy.exe` heisst auch die Datei, die den Auftrag gerade ausfuehrt. Die
eigene Prozesskennung und die des PyInstaller-Starters sind ausgenommen.

Nachgewiesen am laufenden Prozess: beendet, Datenbankdateien danach
loeschbar. In der Entwicklungsumgebung schlaegt der Pfadvergleich uebrigens
immer fehl -- die Werkzeuge laufen in einem App-Container, der
%LOCALAPPDATA% umleitet, waehrend die Registry den echten Pfad meldet. Das
steht jetzt als Hinweis im Docstring, damit es niemand ein zweites Mal sucht.

Ampel lokal: 713 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 14:50:50 +02:00
HitonabiandClaude Opus 5 8e65411189 fix(windows): die Datenbank lag AUSSERHALB der Installation — daher fehlte
Ampel / ampel (push) Failing after 54s
der Ersteinrichtungs-Assistent

Der Befund des Commanders: "Ausserdem fehlt der 1st run wizzard wenn man es
installiert." Meine erste Reparatur (App.tsx las einen gescheiterten Abruf
als "erledigt") war richtig, aber nicht die Ursache. Nachgemessen:

    Installation      %LOCALAPPDATA%\Rippy      wird deinstalliert
    Datenbank         %ProgramData%\Rippy       BLEIBT LIEGEN

Eine "frische" Installation erbte damit die alte Datenbank samt
`setup.done = true` -- der Assistent erschien nie wieder. Gegengeprueft:
nach dem Aufraeumen meldet /api/setup wieder {"done": false}, und das
Fenster zeigt "Willkommen bei Rippy".

Der Grund fuer den alten Ort stand im Docstring: "Ein Programmordner ist
unter Windows fuer einen DIENST nicht zuverlaessig beschreibbar." Das stimmte
-- fuer den Windows-Dienst, den es nie gab. Rippy laeuft als der angemeldete
Benutzer (Autostart unter HKCU). Jetzt liegt alles, was Rippy gehoert, in
EINEM Ordner: Programm, UI, Werkzeuge, Protokoll, WebView2-Zwischenspeicher
und die Datenbank.

Dazu:

* `datenbank_umziehen()` holt eine vorhandene Datenbank vom alten Ort ab --
  wer Rippy schon benutzt hat, behaelt Jobs und Einstellungen. Gibt es am
  neuen Ort schon eine, bleibt sie unangetastet: Die BENUTZTE gewinnt.
* `deinstallieren()` raeumt den alten Ort mit weg, und `alte_orte()` fasst
  nur einen Ordner an, der wirklich "Rippy" heisst.
* Der Ersteinrichtungs-Assistent spricht nicht mehr von "Encoding-Worker",
  wenn es keine gibt -- dort steht jetzt "Kompression". Gegengeprueft: kein
  "docker", kein "Container", kein "Worker" mehr im Text.

Ampel lokal: 709 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 14:46:02 +02:00
HitonabiandClaude Opus 5 082e8b8b55 fix(windows): der Knopf "Rippy oeffnen" oeffnete Rippy nicht
Ampel / ampel (push) Failing after 55s
Nach einer erfolgreichen Einrichtung schloss er nur das Fenster, und danach
passierte nichts mehr: Der Dienst lief nicht, kein Fenster ging auf. Der
Commander hat Rippy anschliessend selbst gestartet ("das tool selbst laesst
sich starten") -- was den Fehler verdeckt hat.

Ein Knopf, der etwas anderes tut als seine Beschriftung sagt, ist schlimmer
als keiner. Jetzt startet main() nach einem geglueckten Assistenten das
installierte Programm.

Dazu der zweite Teil des Netzlaufwerk-Befunds: Auch Netz-ANMELDUNGEN haengen
am Token der Sitzung, nicht nur die Laufwerksbuchstaben. Ein erhoehter Prozess
kennt die Zugangsdaten zur Freigabe nicht und bekommt "Zugriff verweigert" --
also dieselbe Meldung wie bei einem echten Rechteproblem. Ein UNC-Pfad mit
Administratorrechten wird jetzt als solcher erkannt und erklaert.

Ampel lokal: 705 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 14:38:17 +02:00
HitonabiandClaude Opus 5 6dfff5c99d fix(windows): vier Befunde aus dem ersten echten Installationslauf
Alle vom Commander gemeldet, alle nachgestellt.

## 1. Der Installer brach ab: No module named 'db'

    Fehlgeschlagen: ModuleNotFoundError: No module named 'db'

Zu Recht: **docker/api/db.py gibt es nicht.** Seit der Zusammenlegung in V2-1
ist der Store `rippy.store`; main.py schreibt seitdem
`from rippy import store as db`. Ich habe mir aus einem ALIAS ein Modul
zusammengereimt und importiert -- genau die erfundene Schnittstelle, vor der
AGENTS.md Regel D warnt, nur diesmal im eigenen Code. Der Store wird jetzt
direkt benutzt; der Umweg ueber den API-Suchpfad war ohnehin ueberfluessig.

## 2. Der Ersteinrichtungs-Assistent fehlte nach der Installation

In App.tsx stand:

    .catch(() => setSetupDone(true))  // API/Setup nicht erreichbar -> nicht blockieren

Das Fenster geht unmittelbar nach dem Setup auf, der Dienst braucht ein bis
zwei Sekunden bis zur ersten Antwort -- der erste Abruf scheitert also fast
immer. Aus "ich konnte nicht nachsehen" wurde "ist schon erledigt", und der
Assistent war fuer immer weg.

Dasselbe Prinzip steht nebenan in useEventStream.tsx: Ein Verbindungsabriss
ist KEINE Aussage ueber die Welt. Jetzt wird nachgefragt, bis der Server
ANTWORTET (zwei Minuten lang alle zwei Sekunden), und solange steht
"Rippy startet ..." im Fenster statt einer leeren Flaeche.

## 3. + 4. Als Administrator keine Netzlaufwerke, Netzlaufwerk = "keine Rechte"

Beides Windows-Verhalten, kein Rippy-Fehler -- aber Rippy hat ihn
hineinlaufen lassen. Auf dem Rechner nachgemessen:

    X:, Y:, Z:                 Netzlaufwerke
    EnableLinkedConnections    nicht gesetzt (Standard)
    C:\Program Files (x86)     ohne Administrator nicht beschreibbar

Ein erhoehter Prozess bekommt ein anderes Zugriffstoken; eingebundene
Netzlaufwerke haengen am Token der Sitzung und existieren dort schlicht
nicht. Daraus wird ein Teufelskreis:

    Program Files    verlangt Administrator
    Administrator    versteckt die Netzlaufwerke
    Netzlaufwerk     wirkt dann wie "keine Schreibrechte"

Rippy braucht ueberhaupt keine Administratorrechte (Vorgabeordner unter
%LOCALAPPDATA%, Autostart unter HKCU). Der Assistent sagt das jetzt:

* eine eigene Pruefung "Rechte", die bei erhoehtem Start warnt und die
  unsichtbaren Laufwerke beim Namen nennt
* ein fehlender Laufwerksbuchstabe wird als solcher gemeldet, nicht als
  fehlendes Schreibrecht ("Laufwerk Q: ist hier nicht vorhanden")
* ein Ziel unter "Programme" erklaert den Kreis und verweist auf den
  Vorgabeordner

## Dazu: zwei Schreibfallen in AGENTS.md

Deutsche Anfuehrungszeichen in doppelt gequoteten Zeichenketten (vier Mal an
einem Tag) und Bash-Heredocs, die Backslashes halbieren (fuenf Mal, zuletzt
beim Schreiben genau dieses Absatzes). Ein Test dafuer waere Rauschen gewesen
-- Python faengt beides bereits beim Import, nur mit verwirrender Meldung.
Die Regel gehoert in die Konventionen, nicht in eine Pruefung.

Ampel lokal: 703 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 14:36:56 +02:00
HitonabiandClaude Opus 5 8eca982e68 docs: SAVEPOINT v4.0-rc2 — Windows ist ein eigenes Produkt
Ampel / ampel (push) Successful in 55s
Die drei Befunde des Commanders und was dahinter steckte, plus der teuerste
Fund des Tages: %ProgramFiles(x86)% wurde auf einer echten Maschine NIE
aufgeloest, weil der Test genau die Schreibweise einspritzte, die im Muster
stand. Er war gruener als die Wirklichkeit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 14:03:04 +02:00
HitonabiandClaude Opus 5 151376aee3 fix: Pfad-Regeln an EINE Stelle — dreimal dieselbe Falle war zweimal zu viel
Ampel / ampel (push) Successful in 54s
Ampel-Lauf zu b47d215 rot, drei Fehlschlaege, alle mein eigener Code:

    platz_orte             os.path.splitdrive kannte auf Linux kein "D:"
                           -> zwei Laufwerke galten als eines
    naechster_vorhandener  os.path.dirname zerlegte C:\Users\Test\... nicht
    pruefe_windows         die Plattform-Pruefung stand VOR der eingespritzten
                           Version -> pruefe_windows(22631) gab auf Linux FEHLER

`os.path` richtet sich nach der Maschine, auf der es laeuft. Das ist fast
immer richtig -- und an jeder Stelle falsch, an der ueber Pfade einer ANDEREN
Maschine gerechnet wird. Genau das war heute schon zweimal da:

    tools/katalog.py         C:\Program Files (x86)\MakeMKV/makemkvcon64.exe
    platform/verknuepfungen  dirname() einer .lnk gab einen leeren String

Zweimal einzeln repariert, beim dritten Mal gehoert es an EINE Stelle:
`rippy/pfade.py` mit `ist_windows_pfad`, `verbinden`, `ordner_von`,
`laufwerk_von`, `gleiches_laufwerk`, `naechster_vorhandener`. Die Regel steht
dort im Kopf: **Der Pfad entscheidet, nicht der Rechner.** katalog,
verknuepfungen, betrieb und einrichtung benutzen jetzt alle dasselbe.

Und `pruefe_windows` beachtet einen eingespritzten Wert wieder. Ein
Einspritzpunkt, der ignoriert wird, ist keiner -- dann sind die Tests
daneben, die ihn benutzen.

Sieben neue Tests in test_pfade.py, die BEIDE Zweige pruefen und deshalb
ueberall laufen. Das war der eigentliche Mangel: Jede dieser drei Fallen war
nur auf der jeweils anderen Plattform sichtbar.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 14:00:34 +02:00
HitonabiandClaude Opus 5 b47d21510d docs: Entscheid 6 — Faehigkeiten statt Modus-Name, und ein Setup das fragt
Ampel / ampel (push) Failing after 54s
Beide Befunde des Commanders vom 28.08.2026 festgehalten, mitsamt der
Begruendung, warum ein 'if (windows)' an dreissig Stellen die falsche
Reparatur gewesen waere: Die Oberflaeche haette weiterhin nichts ueber ihren
Betrieb gewusst, nur eine zweite Sorte Vermutung gehabt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 13:56:41 +02:00
HitonabiandClaude Opus 5 a4a045f303 feat(windows): ein echtes Setup — Voraussetzungs-Pruefung, Zielordner, Ablage
Commander: "Dann haette ich beim 'Setup' auch erwartet das nen echtes setup
passiert - wo will ich das hinspeichern, nen pre requirement check usw. Da
kommt garnichts Rippy geht einfach auf."

Er hatte recht. Ein Doppelklick installierte stillschweigend nach
%LOCALAPPDATA%\Rippy und oeffnete das Fenster. Der Nutzer wurde nichts
gefragt und erfuhr nichts -- auch nicht, ob sein Rechner ueberhaupt kann, was
Rippy braucht.

Jetzt: ein Assistent mit acht Pruefungen, zwei Ordner-Wahlen und drei
Schaltern. Auf diesem Rechner nachgemessen:

    OK  Betriebssystem      Windows 11 (Build 26200)
    OK  Fenster (WebView2)  151.0.4129.107
    OK  Optisches Laufwerk  \.\G:
    OK  HandBrakeCLI        1.11.2
     !  MakeMKV             nicht gefunden
                            -> wird von makemkv.com geholt
    OK  Speicherplatz       59.1 GB frei
    OK  Schreibrecht        C:\Users\...\AppData\Local\Rippy
    OK  Netzwerk-Port       7788 ist frei

Drei Entwurfsentscheidungen, die dazugehoeren:

* Nur ein FEHLER blockiert, eine Warnung nicht. Eine Warnung, die den Knopf
  sperrt, ist eine Bevormundung; ein Fehler, der nur warnt, ist eine Falle.
  Kein Laufwerk = Warnung (reine Komprimier-Maschine ist ein vorgesehener
  Betriebsfall). Kein Schreibrecht = Fehler.
* Jeder Befund sagt, was zu tun ist. Ein Befund ohne Abhilfe laesst den
  Nutzer ratlos zurueck -- ein Test haelt das fuer jede Pruefung fest.
* Die Pruefungen stehen in einrichtung.py, komplett ohne Fenster pruefbar.
  Im Fenstermodul steht nur Aufbau und Bruecke.

WebView2 statt Win32-Dialog: Es ist ohnehin da (Entscheid 4), der Assistent
kostet damit NULL zusaetzliche Bytes. Die Seite laedt nichts aus dem Netz --
sie muss auf einem Rechner ohne Internet aufgehen, dort wird sie am
dringendsten gebraucht. Ein Test haelt das fest.

--still und --ohne-assistent gehen weiterhin den stummen Weg. Geht das
Fenster nicht auf, wird mit den Vorgaben installiert und gesagt warum -- ein
Setup, das gar nichts tut, weil sein Fenster nicht aufging, waere schlimmer
als eines, das nicht fragt.

fix(tools): %ProgramFiles(x86)% wurde auf echten Rechnern NIE aufgeloest

Beim Bauen der Pruefung aufgefallen, und es ist ein Lehrstueck:

    Testumgebung   {"ProgramFiles(x86)": ...}  ->  C:\Program Files (x86)\...
    echtes Windows {"PROGRAMFILES(X86)": ...}  ->  ''

Windows behandelt Umgebungsvariablen ohne Ruecksicht auf die Schreibweise und
legt sie in os.environ GROSS ab. Der Vergleich in _entfalten war exakt, fand
nie eine Uebereinstimmung, und die bekannten Installationsorte fielen aus der
Kandidatenliste. MakeMKV wurde also NUR ueber die Registry-Rueckfallebene
gefunden -- wo die fehlt oder anders aussieht, fand Rippy nichts.

Aufgefallen ist es nur, weil hier zum ersten Mal eine ECHTE Umgebung benutzt
wurde. Der Test spritzte genau die Schreibweise ein, die im Muster stand: Er
war gruener als die Wirklichkeit. Beide Tests nehmen jetzt die echte
Schreibweise, und einer prueft direkt gegen os.environ. Beim Zurueckdrehen
des Fehlers rot gesehen (5 Fehlschlaege).

Ampel lokal: 691 gruen, ruff sauber. Assistent im Bildschirmfoto belegt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 13:54:59 +02:00
HitonabiandClaude Opus 5 66642b8d93 feat(ui): die Oberflaeche weiss jetzt, worauf sie laeuft
Commander-Befund 28.08.2026, zum Windows-Fenster:

    Worker erreichbar:   0 von 1
    Kein Worker antwortet — Pruefen: docker compose ps
    Container-Platte:    unbekannt
    Freigaben:           keine eingehaengt

Kein Satz davon ergibt auf einem Windows-PC einen Sinn. Sein Urteil: "Du hast
ja quasi nur rippy genommen und die docker installation fuer Windows gebaut.
Das gilt fuer die ganze standalone version fuer Windows, auch fuer die
settings und die Anleitung usw."

## Die Ursache war nicht die Anzeige

Die naheliegende Reparatur waere ein `if (windows)` an dreissig Stellen
gewesen -- dieselbe Falle noch einmal, nur mit einer zweiten Sorte Vermutung.

Es fehlte etwas anderes: Das UI hat nie erfahren, worauf es laeuft. config.py
kennt das Profil seit V2-2, weitergegeben wurde es nie. Also hat das UI
angenommen.

Neu: GET /betrieb meldet FAEHIGKEITEN, keinen Modus-Namen.

    externe_worker        Gibt es andere Maschinen, die Jobs uebernehmen?
    freigaben_einhaengen  Kann Rippy Netzwerk-Freigaben selbst einhaengen?
    container_pfade       Sind Pfade wie /app/media ueberhaupt gemeint?
    werkzeuge_verwalten   Kann Rippy MakeMKV/HandBrake selbst beschaffen?

Ein Modus-Name wuerde das UI zwingen, aus einem Namen auf Verhalten zu
schliessen -- und das bricht beim naechsten Betriebsfall: Ein
Docker-All-in-One hat Container-Pfade, aber keinen zweiten Worker.

## Was sich sichtbar aendert (auf Windows nachgemessen)

    Server-Status  "Rippy arbeitet: auf diesem Rechner" statt Worker-Zaehler
                   "Platz fuer Rippy: 59.2 von 232 GB frei" statt "unbekannt"
                   Freigaben-Block faellt weg
    Einstellungen  kein Reiter "Worker"; Speicherziele BLEIBT (dort steht die
                   Ablage -- "wo will ich das hinspeichern" war die Frage),
                   aber mit Pfadfeld statt Container-Auswahl und ohne die
                   Maske zum Einhaengen
    Anleitung      kein docker, kein Encoding-Worker-Abschnitt, stattdessen
                   der echte Ordner (C:\Users\...\Videos\Rippy)

## Zwei Fehler, die dabei aufgefallen sind

* MEDIA_ROOT = "/app/media" war in main.py fest verdrahtet. shutil.disk_usage
  warf unter Windows, die Liste blieb leer -- daher "unbekannt", obwohl auf
  dem Laufwerk 59 GB frei waren. Eine Nichtauskunft, die wie eine Auskunft
  aussieht. platz_orte() liefert die Orte jetzt je Betrieb, und ein noch
  nicht angelegter Ordner faellt auf das naechste vorhandene Elternteil
  zurueck.
* Der SSE-Schnappschuss enthielt den Server-Zustand NICHT, und der Waechter
  schickt ihn nur alle 15 Sekunden. Nach jedem Neuladen stand deshalb bis zu
  eine Viertelminute "unbekannt" da. Jetzt ist er im Schnappschuss, und das
  UI uebernimmt ihn auch von dort.

Dazu: der Windows-Skip in test_api_smoke.py ist weg. Er stammte aus der Zeit
vor V2-4, als main.py fcntl brauchte; seit der Treiberwahl ueber den Port
laedt es auf beiden Plattformen (57 Routen, gemessen). Damit laufen 20 Tests
mehr auch lokal statt nur auf der Ampel.

Ampel lokal: 654 gruen, ruff sauber. Docker-Zweig durch Unit-Tests gedeckt,
am echten Container noch nicht gegengeprueft -- das kommt beim Deploy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 13:45:00 +02:00
HitonabiandClaude Opus 5 a5e64f8e56 fix(windows): der Deinstallierer liess 148 Dateien liegen und meldete Erfolg
Ampel / ampel (push) Successful in 54s
Beim ersten echten Deinstallieren auf dem Rechner des Commanders gemessen:

    Uninstall-Eintrag   weg
    Autostart           weg
    Verknuepfungen      weg
    Dateien             149 NOCH DA  (davon 148 in fenster\EBWebView\)

Gemeldet wurde: "Rippy wurde entfernt."

Zwei Ursachen, beide behoben:

## 1. WebView2 ueberlebt Rippy

WebView2 startet eigene Prozesse (msedgewebview2.exe: Renderer, GPU, Netz,
Crashpad). Stirbt Rippy, laufen sie als Waisen weiter und halten den
Zwischenspeicher offen -- acht davon liefen noch, als ich nachsah. shutil.rmtree
scheiterte an jeder gesperrten Datei.

fenster.helfer_beenden() beendet sie jetzt VOR dem Loeschen. Gefiltert wird
ueber den --user-data-dir in der Befehlszeile: msedgewebview2.exe benutzen
auch andere Programme, und die alle zu beenden waere ein Uebergriff -- der
Nutzer verloere die Fenster fremder Anwendungen. Ein Test haelt fest, dass
erst gefiltert und dann beendet wird.

## 2. Der Fehler wurde verschluckt

`except OSError: pass` in der Loeschschleife. Ein "Rippy wurde entfernt" ueber
einem halb geleerten Ordner ist eine Falschaussage -- genau die Sorte stiller
Fehlschlag, vor der AGENTS.md warnt. Jetzt wird gesammelt, was nicht ging, und
mit dem Grund genannt.

Dazu im Aufraeum-Skript: `rmdir /s /q` statt `rmdir`. Ein blosses rmdir
scheitert an JEDER verbliebenen Datei und laesst den ganzen Ordner stehen --
selbst wenn spaeter nur noch eine Sperrdatei uebrig ist.

Ampel lokal: 612 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 13:15:58 +02:00
HitonabiandClaude Opus 5 ce4e7e6b8a feat(windows): das Setup richtet MakeMKV und HandBrake wirklich ein
Ampel / ampel (push) Successful in 54s
Commander: "handbrake und makemkv MUESSEN mitgeliefert werden oder waehrend
des Setups separat installiert werden! Ohne das ist das tool NICHT
einsatzfaehig."

Er hat recht, und die Luecke war real: katalog.py konnte die Werkzeuge
finden, beschaffen.py konnte sie holen -- das Setup rief beides nie auf. Wer
Rippy auf einem frischen Rechner installierte, bekam eine Oberflaeche, die
ihm sagte was fehlt, und keinen Weg, es zu aendern.

Die beiden gehen unterschiedliche Wege, und der Grund ist die LIZENZ:

* HandBrakeCLI ist GPL-2 -> mitgeliefert. Weitergabe ausdruecklich erlaubt,
  solange Lizenztext und Quellverweis dabei sind (LIZENZ-HandBrake.txt liegt
  daneben). Damit komprimiert Rippy auch ohne Internet.
* MakeMKV ist proprietaer -> beim Einrichten vom Hersteller geholt und mit
  DESSEN Installer installiert. Weitergabe durch Dritte ist nicht erlaubt.
  Das ist dieselbe Black-Box-Trennung wie in KONZEPT.md 6 und deckt sich mit
  KONZEPT-V2.md 4.1 ("MakeMKV wird NICHT mitgeliefert").

Drei Regeln, die dazugehoeren:

1. Ein Setup meldet NIE Erfolg, waehrend ein Pflichtwerkzeug fehlt.
   sicherstellen() liest den Bestand VOR und NACH dem Versuch und gibt
   zurueck, was danach wirklich da ist -- nicht, dass es versucht wurde.
2. Ein nicht erreichbarer Download bricht die Installation nicht ab. Am
   28.08.2026 antwortete makemkv.com mit HTTP 525. Rippy ist dann trotzdem
   installiert und sagt im Klartext, was fehlt und wie man es beschafft.
3. Ohne HandBrake ist Rippy einsatzbereit (Rip laeuft, nur ohne Kompression),
   ohne MakeMKV nicht. Nur Pflichtwerkzeuge entscheiden ueber "bereit".

Nachgemessen am fertigen Setup: HandBrake geloescht, installiert, nach DREI
Sekunden wieder da (74 MB, also aus dem Paket und nicht geladen), Meldung
"Rippy ist einsatzbereit. HandBrakeCLI 1.11.2 / MakeMKV 1.18.4".
RippySetup.exe waechst von 32,0 auf 56,4 MB.

fix(tools): der Fortschritts-Rueckruf bekommt immer einen Text

_datei_laden schickte `None` als Text, wenn sich nur der Fortschritt geaendert
hatte. Der erste echte Aufrufer starb daran:

    can only concatenate str (not "NoneType") to str

Ein Rueckruf, den man nur mit einer nirgends dokumentierten Sonderbehandlung
benutzen kann, ist eine Falle. Jetzt kommt immer ein Satz, gedrosselt auf
jedes zehnte Prozent -- 24 MB in 256-KB-Haeppchen waeren sonst hundert Zeilen
im Protokoll. Zwei Tests halten beides fest.

Nicht im Repo: Die 70,9 MB HandBrakeCLI holt der BAU nach
dist/windows/vendor/ (nicht versioniert) -- dasselbe Muster wie der
vendor/-Ordner fuer MakeMKV auf der VM.

Ampel lokal: 607 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 13:09:01 +02:00
HitonabiandClaude Opus 5 60c0f93237 fix(windows): leere Symbole und der verschwundene Eintrag in "Installierte Apps"
Ampel / ampel (push) Successful in 54s
Beides vom Commander gemeldet, beides gemessen statt vermutet.

## 1. Weisses leeres Blatt statt Symbol

In deploy/worker-windows/rippy.ico steckte GENAU EIN Bild:

    Bilder = 1
      256x256   32 bit   5657 Bytes   PNG

Windows holt sich fuer jede Stelle die passende Groesse -- 16x16 fuer die
Taskleiste, 32/48 fuer Desktop und Startmenue. Fehlt sie, skaliert die Shell
nicht zuverlaessig selbst, sondern zeigt das leere Blatt. Bei einer Datei mit
nur einem PNG-komprimierten 256er passiert das regelmaessig.

packaging/windows/icon.py baut die Datei jetzt mit neun Groessen
(16/20/24/32/40/48/64/128/256, LANCZOS beim Verkleinern). Nachgemessen an
der neuen EXE: 16x16 mit 138 Farben, 32x32 mit 264 -- kein leeres Blatt mehr.
build.py laesst ein unvollstaendiges Symbol gar nicht mehr durch, und
test_icon.py haelt die Pflichtgroessen fest (mit dem alten Stand rot gesehen).

## 2. Rippy stand nicht in "Installierte Apps"

Die Ursache war MEINE Testsuite. Gemessen:

    Rippy.exe --nicht-starten   ->  Eintrag: DA  (Rippy 2.0.0)
    pytest -q                   ->  Eintrag: WEG

test_installation_legt_die_dateien_an_... schrieb in den ECHTEN
Uninstall-Schluessel und loeschte ihn im finally wieder -- also auch den des
Commanders. Der Autostart-Eintrag ging denselben Weg.

Der Schluesselname stand als VORGABEWERT in jeder Signatur, und Vorgabewerte
wertet Python zur Definitionszeit aus: Ein Test konnte ihn gar nicht umbiegen.
Jetzt steht dort None, aufgeloest zur Laufzeit -- damit wirkt ein
monkeypatch.setattr(reg, "SCHLUESSEL", ...) ueberall.

Dazu ein Waechter (test_die_testsuite_ruehrt_den_ECHTEN_eintrag_nicht_an):
Er merkt sich den echten Zustand vorher, laesst eine vollstaendige
Test-Installation samt Autostart laufen und prueft danach, dass sich am
echten Eintrag nichts geaendert hat.

Das ist derselbe Fehler wie vorhin bei den Verknuepfungen, nur an anderer
Stelle. Die Regel gehoert in den Code, nicht in meinen Kopf: **Ein Test
raeumt nur weg, was er selbst angelegt hat.**

Ampel lokal: 590 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 12:57:50 +02:00
HitonabiandClaude Opus 5 e1984dc543 docs: SAVEPOINT — Ampel wieder gruen, und warum sie fuenf Laeufe rot war
Ampel / ampel (push) Successful in 54s
Nachgetragen: die 28 Linux-Fehler, der schwerste davon (der API-Container
waere auf der VM gar nicht hochgekommen), und die Lehre daraus — ein Test,
der nur auf einer Plattform greift, ist eine halbe Zusage.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 12:46:22 +02:00
HitonabiandClaude Opus 5 ca212ff835 fix(test): die detection-Attrappe muss auch das PAKET-Attribut ersetzen
Ampel / ampel (push) Successful in 54s
Ampel-Lauf 186: Die 28 echten Linux-Fehler waren weg, uebrig blieben fuenf
— alle in meinem neuen Test:

    TypeError: drive_status() missing 1 required positional argument

`from rippy.drives import detection` sieht zuerst im PAKET nach
(`_handle_fromlist` prueft `hasattr`) und greift erst dann auf sys.modules
zurueck. Auf Linux ist das echte Modul dort laengst gesetzt, weil es
importierbar ist — die Attrappe blieb wirkungslos, und der Test lief in die
echten Funktionen.

Unter Windows fiel das nicht auf: Dort gibt es das Attribut mangels fcntl
gar nicht, also griff sys.modules. Derselbe Test, zwei Plattformen, zwei
Ergebnisse — genau die Sorte Luecke, die dieser Test eigentlich schliessen
soll.

Jetzt werden beide ersetzt. Gegengeprueft: mit kaputter Durchreiche fuenf
Fehlschlaege, danach wieder gruen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 12:44:05 +02:00
HitonabiandClaude Opus 5 bfc0cada62 fix(windows): kein CMD-Fenster mehr — die EXE ist ein Fenster-Programm
Ampel / ampel (push) Failing after 55s
Commander: "Unterbinde das CMD Fenster was sich beim oeffnen mitoeffnet."

Mein erster Anlauf wollte die Konsole VERSTECKEN und war falsch, aus zwei
Gruenden:

* Eine Onefile-EXE ist ZWEI Prozesse (gemessen: PID 33172 mit 8 MB, PID
  33580 mit 103 MB, beide Rippy.exe). Die Pruefung "haengt genau EIN Prozess
  an der Konsole" war damit nie wahr, das Fenster blieb einfach stehen.
* Selbst wenn sie ginge, waere das Fenster erst nach ein bis zwei Sekunden
  weg. Ein Aufblitzen ist kein "unterbunden".

Jetzt wird die Konsole gar nicht erst erzeugt: --windowed statt --console.
Nachgemessen am fertigen Bau -- PE-Subsystem 2 (GUI) statt 3 (Konsole), und
beim Klick auf die Desktop-Verknuepfung ist genau EIN sichtbares Fenster da:
die WinForms-Oberflaeche. Kein ConsoleWindowClass-Fenster von Rippy, weder
sichtbar noch unsichtbar.

Was dazugehoert, damit daraus kein stiller Fehlschlag wird:

* Ohne Konsole ist sys.stdout None. uvicorn schreibt auf stderr und waere
  mitten im Start gestorben, ohne dass irgendwo etwas stuende. einstieg.py
  haengt sich deshalb an die Konsole des Aufrufers (--status in PowerShell
  schreibt weiter dorthin) oder leitet nach %LOCALAPPDATA%\Rippy\rippy.log um.
* Der Installer meldet sein Ergebnis in einem Fenster, wenn keine Konsole da
  ist -- sonst saehe ein gescheiterter Doppelklick aus wie einer, der nichts
  tut. Bei --still und mit Konsole bleibt es bei der Textzeile.

Gegengeprueft am laufenden Programm: /api/health, / und /api/capabilities
antworten mit 200, und rippy.log faengt auf, was vorher ins Leere ging.

fix(drives): linux.py reicht die detection-Funktionen wieder durch

Die Ampel war seit Lauf 181 rot -- vier Commits lang, und ich hatte es
uebersehen. Ursache:

    docker/api/main.py:54
    AttributeError: module 'rippy.drives.linux' has no attribute 'drive_status'

main.py holt sich beim Import device_discovery.drive_status. Der
Windows-Treiber hat die Funktion; linux.py hatte sie nicht mehr, seit
detection (und damit fcntl) bewusst nicht mehr oben importiert wird -- sonst
waere main.py unter Windows nicht ladbar. Unter Windows lief also alles, auf
Linux waere der API-Container gar nicht hochgekommen.

Behoben mit PEP 562 (__getattr__), demselben Kniff wie in store/__init__.py:
Der Import bleibt ohne fcntl moeglich, wer die Funktionen BENUTZT bekommt sie.

Dazu drei weitere Fehler, die nur auf Linux auftraten:

* katalog.py baute Windows-Pfade mit os.path.join. Auf dem Linux-Runner wurde
  daraus C:\Program Files (x86)\MakeMKV/makemkvcon64.exe. Jetzt entscheidet
  der Pfad selbst ueber den Trenner, nicht die rechnende Maschine.
* verknuepfungen.py nahm os.path.dirname fuer den Arbeitsordner einer .lnk.
  Eine .lnk zeigt IMMER auf einen Windows-Pfad -- also ntpath.
* waechter.py las 0.0 als Zeitpunkt statt als "noch nie geprueft". Auf einer
  frisch gestarteten Maschine ist time.monotonic() klein, also fiel die erste
  Laufwerks-Abfrage aus. None statt 0.0.

Alle vier haben jetzt Tests, die auf JEDER Plattform laufen -- der
Treiber-Test schiebt eine detection-Attrappe unter, der Waechter-Test stellt
eine Uhr bei 0,5 s nach, die Pfad-Tests pruefen beide Zweige. Beim
Wegnehmen der Durchreiche rot gesehen (5 Fehlschlaege), danach wieder gruen.
Damit faengt die Ampel so etwas kuenftig, ohne dass es eine Linux-Umgebung
auf dem Entwicklungsrechner braucht.

Ampel lokal: 582 gruen, ruff sauber.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 12:41:10 +02:00
HitonabiandClaude Opus 5 e1577a4f47 docs: SAVEPOINT v4.0-rc — Windows ist ein echtes Programm
Ampel / ampel (push) Failing after 55s
Der SAVEPOINT stand seit V2-3 still, waehrend elf Commits dazukamen.
Nachgetragen mit den gemessenen Zahlen: 562 gruen, RippySetup.exe 31,7 MB,
WebView2 151.0.4129.107, 5 Encoder auf diesem PC.

Zwei Dinge stehen bewusst gross drin, weil sie sonst verloren gehen:

* Der Dienst, der /api/health mit 200 beantwortete und / mit 404 -- und
  warum ein %TEMP%-Verzeichnis kein Ort fuer eine Oberflaeche ist.
* Der Test, der den PC des Commanders getroffen hat. Ein Test, der Spuren
  ausserhalb von tmp_path hinterlaesst, ist kein Test, sondern ein Eingriff.

Und was NICHT bewiesen ist, steht als solches da: Ein echter Rip unter
Windows ist nie gelaufen, die VM haengt elf Commits zurueck.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 12:15:29 +02:00
HitonabiandClaude Opus 5 c01ef1081c feat(windows): echtes Fenster statt Browser-Tab (WebView2 statt Electron)
Auf die Frage des Commanders: "Warum nutzen wir fuer Windows weiterhin
einen Browser? Warum nutzen wir kein Electron oder sowas und machen daraus
einen echten Client."

Die erste Haelfte trifft zu und ist umgesetzt. Die zweite ist abgelehnt --
gemessen, nicht geschaetzt:

    pywebview + WebView2     8,0 MB in der Bau-Umgebung, 2,7 MB in der EXE
    Electron               150-210 MB, dazu eine zweite Laufzeitumgebung

Windows 11 bringt die WebView2-Laufzeit mit (hier 151.0.4129.107).
Nachgemessen statt angenommen, was sie rendert:

    navigator.userAgent  ...Chrome/151.0.0.0 Safari/537.36 Edg/151.0.0.0
    fetch ja   EventSource ja   CSS Grid ja   Pfeilfunktionen ja

Dasselbe Chromium, das auch in Electron steckt -- nur ohne es ein zweites
Mal mitzuschleppen. RippySetup.exe waechst von 29,0 auf 31,7 MB.

Drei Dinge gehoeren dazu, nicht als Beiwerk:

* Kein stiller Rueckfall auf MSHTML. Der alte IE-Renderer stellt die
  React-Oberflaeche nicht dar. Fehlt WebView2, oeffnet Rippy den Browser
  und SAGT warum -- ein leeres Fenster waere schlimmer als ein Tab.
* Fenster und Tray sind getrennte Prozesse. pystray belegt unter Windows
  den Haupt-Thread, das Fenster braucht ihn genauso.
* Die eigene Konsole wird versteckt, eine geerbte nie. GetConsoleProcessList
  unterscheidet beides: genau ein Prozess an der Konsole heisst, sie
  gehoert uns. Ohne diese Unterscheidung haette "Rippy.exe --status" im
  Terminal das Terminal des Nutzers verschwinden lassen.

fix(windows): Oberflaeche neben das Programm legen statt aus %TEMP% bedienen

Beim Nachsehen im laufenden Betrieb gefunden: Ein Dienst lief eine Stunde,
/api/health gab HTTP 200, / gab 404. Im Fenster stand {"detail":"Not Found"}.

Der Server war in Ordnung. Sein Entpack-Verzeichnis war es nicht:

    _MEI000074b02   31 Eintraege,  5 Ordner   -- kein ui, kein api
    _MEI000082e82   44 Eintraege, 16 Ordner   -- vollstaendig

Eine PyInstaller-Onefile-EXE liest bei JEDER Anfrage aus %TEMP%\_MEIxxxxx.
Ein Temp-Verzeichnis ist kein Ort fuer etwas, das eine Woche liegen bleibt.
Und der Ausfall ist der schlimmstmoegliche: Die API antwortet weiter, der
Dienst gilt als gesund, nur die Oberflaeche ist weg.

Genau davor warnte ROADMAP.md beim Bau-Verfahren ("one-dir statt one-file").
Die Abweichung bleibt, die Luecke wird geschlossen: Der Installer legt die
Oberflaeche neben das Programm, daemon._ui_pfad() nimmt diese Kopie zuerst.
Zeigt sich derselbe Ausfall an den API-Modulen, ist one-dir die Antwort.

Ampel: 562 gruen, ruff sauber. Fenster mit der echten Oberflaeche im
Bildschirmfoto nachgewiesen, nicht nur der Titel geprueft.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 12:14:15 +02:00
HitonabiandClaude Opus 5 069fc46f44 fix(test): der Installations-Test hat die ECHTEN Verknuepfungen ueberschrieben
Ampel / ampel (push) Failing after 47s
WAS: `test_installation_legt_die_dateien_an_...` installiert in ein
tmp_path — legt aber seit dem Verknuepfungs-Einbau auch Symbole auf dem
ECHTEN Desktop und im ECHTEN Startmenue an. Die kennen kein tmp_path.

DIE FOLGE, vom Commander gemeldet: Er klickte auf das Desktop-Symbol und
bekam von Windows "Diese App kann auf dem PC nicht ausgefuehrt werden".
Nachgemessen zeigte die Verknuepfung auf

  ...\Temp\pytest-of-TobisPC\pytest-142\test_installation_..._0\installiert\Rippy.exe

— und dort liegt die 2-KB-ATTRAPPE aus dem Test, kein Programm. Windows
hatte voellig recht.

Der `finally`-Block raeumte nur Registry und Autostart auf; die
Verknuepfungen nicht, weil es sie beim Schreiben des Tests noch nicht gab.
Als sie dazukamen, wuchs der Test stillschweigend ueber sein tmp_path
hinaus. Ein Test, der Spuren ausserhalb seines Temp-Ordners hinterlaesst,
ist kein Test, sondern ein Eingriff.

BEHOBEN mit ZWEI Sicherungen statt einer:
  1. verknuepfen=False — die Funktion legt gar keine an.
  2. vk.alle_anlegen ist trotzdem ersetzt. Wer den Schalter spaeter
     umdreht oder die Vorgabe aendert, kann damit trotzdem nichts am
     echten System anrichten.

Dazu ein Waechter: test_installation_ruehrt_die_echten_verknuepfungen_
nicht_an prueft, dass die Anlege-Funktionen bei verknuepfen=False GAR
NICHT gerufen werden. Waere er frueher dagewesen, haette der Commander
keine kaputte Verknuepfung bekommen.

DER RECHNER IST REPARIERT: neu installiert, beide Verknuepfungen zeigen
wieder auf C:\Users\...\AppData\Local\Rippy\Rippy.exe (29 MB, existiert),
Programme+Features-Eintrag ist zurueck. Start ueber die Verknuepfung:
HTTP 200 nach 2 s, Worker TobisNicerPC mit cpu-x264/x265/av1 + vce/vce-av1,
MakeMKV 1.18.4 und HandBrake 1.11.2 gefunden.

Nebenbei ausgeschlossen, bevor die Ursache klar war: Die EXE selbst ist in
Ordnung (gueltiges x64-PE, MZ/PE-Kopf, 29 MB, Hash identisch mit dem
Installat), kein Mark-of-the-Web, kein Defender-Fund, Smart App Control
aus. Der Fehler lag nicht an der Datei, sondern daran, WORAUF gezeigt wurde.

GEMESSEN: ruff sauber, 522 Tests gruen + 15 uebersprungen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 11:47:11 +02:00
HitonabiandClaude Opus 5 99c05865af feat(windows): Desktop-Symbol und Startmenue-Eintrag — plus --oeffnen
Ampel / ampel (push) Failing after 47s
WAS: Das Setup legt jetzt eine Verknuepfung auf dem Desktop UND im
Startmenue an, die Deinstallation nimmt beide zurueck, und `--status`
zeigt, ob sie da sind. Abwaehlbar mit --keine-verknuepfungen.

WARUM (Commander-Meldung): "es gibt kein icon aufm desktop und keinen
startmenü eintrag". Zu Recht — ein Hintergrundprogramm ohne Symbol ist
praktisch unauffindbar: Es laeuft, aber es gibt keinen Weg hinein ausser
der Adresse im Kopf.

DIE VERKNUEPFUNG ZEIGT AUF --oeffnen, NICHT AUF --dienst. Ein Doppelklick
soll Rippy OEFFNEN; ob der Dienst laeuft, ist dem Nutzer egal und er kann
es auch nicht wissen. Zeigte das Symbol auf --dienst, startete jeder Klick
einen ZWEITEN Server, der am belegten Port scheitert — das Fenster blitzt
auf, im Browser passiert nichts. Ein Symbol, das beim zweiten Klick nichts
tut, ist schlimmer als keins.

`--oeffnen` sieht deshalb erst NACH, ob jemand antwortet, startet nur wenn
noetig, und wartet dann, bis der Dienst wirklich da ist — statt sofort
einen Browser auf eine tote Adresse zu schicken. Gemessen: erster Aufruf
2 s bis HTTP 200, zweiter Aufruf keine zusaetzlichen Prozesse.

DIE ORDNER KOMMEN AUS DER REGISTRY, nicht aus %USERPROFILE%. Wer OneDrive
benutzt oder seine Ordner verschoben hat, dessen Desktop liegt woanders —
die Verknuepfung landete dann in einem Ordner, den niemand sieht, und der
Nutzer suchte ein Symbol, das es nirgends gibt.

UEBER POWERSHELL statt pywin32: Eine .lnk ist ein binaeres Shell-Objekt.
pywin32 koennte es, waere aber 20 MB fuer vier Zeilen. Denselben Weg geht
der alte Worker-Installer schon ("nativ via PowerShell").

ZWEI FEHLER, DIE DIE TESTS GEFUNDEN HABEN:
- os.makedirs stand AUSSERHALB des try. Auf einem Laufwerk, das es nicht
  gibt, wirft es — aus "Verknuepfung konnte nicht angelegt werden" waere
  ein Abbruch der ganzen Installation geworden.
- Der Test dafuer nahm fest Z: als "gibt es nicht". Auf dem Commander-PC
  ist Z: ein NETZLAUFWERK (X, Y, Z sind belegt). Ein fest verdrahteter
  Laufwerksbuchstabe ist eine Annahme ueber eine fremde Maschine; jetzt
  wird zur Laufzeit ein freier gesucht.

Und der Apostroph: In PowerShell wird er innerhalb einfacher
Anfuehrungszeichen durch VERDOPPELN maskiert. Ohne das braeche ein Pfad wie
C:\Users\O'Brien\... das Skript entzwei, und der Fehler saehe aus wie ein
Syntaxfehler in Rippy.

GEMESSEN, nach echter Installation nach %LOCALAPPDATA%\Rippy:
  Desktop-Symbol   -> Rippy.exe --oeffnen, mit Symbol und Beschreibung
  Startmenue       -> ebenso
  Programme+Feat.  -> Rippy 2.0.0, 100 MB, Deinstallieren funktioniert
  Autostart        -> "...\Rippy.exe" --dienst
  Start ueber das Symbol: HTTP 200 nach 2 s
  Worker: TobisNicerPC, Encoder cpu-x264/x265/av1, vce, vce-av1

GEMESSEN: ruff sauber, 521 Tests gruen + 15 uebersprungen (vorher 512).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 11:40:39 +02:00
HitonabiandClaude Opus 5 f4a8d77598 feat(windows): Rippy arbeitet eigenstaendig — Rippen, Werkzeuge, Fähigkeiten
Ampel / ampel (push) Failing after 48s
WAS: Der Ablauf ist aus tasks.py heraus (ablauf.py, ohne Celery), die
LocalQueue wird bedient, ein Laeufer arbeitet Auftraege im selben Prozess
ab, und Rippy meldet sich mit gemessenen Faehigkeiten selbst als Arbeiter.

WARUM: "Rippy fuer Windows soll standalone funktionieren" (Commander). Bis
hierher konnte die Windows-App alles ANZEIGEN und nichts TUN — ein Rip waere
eingereiht worden und fuer immer liegengeblieben, weil niemand ihn holt.

DIE TRENNUNG: rip_disc hing an GENAU DREI Celery-Stellen in 234 Zeilen —
self.update_state, _transcode_queue, transcode_files.apply_async. Alle drei
sind Fragen der ZUSTELLUNG, nicht des Ablaufs. Sie sind jetzt Rueckrufe:
tasks.py reicht die Celery-Fassung herein, standalone.py die lokale. OHNE
Rueckruf komprimiert derselbe Prozess weiter — genau das, was ein
Ein-Prozess-Rippy braucht. Der Ablauf selbst ist Zeile fuer Zeile derselbe;
der Docker-Betrieb merkt vom Umbau nichts (Task-Namen, Argumente, Queues
unveraendert).

EINE ZUSTELL-STELLE statt drei: celery_client.abschicken() bedient alle
Auftragsarten. Vorher rief jede Stelle send_task selbst auf — der
Standalone-Betrieb haette an drei Stellen umgebogen werden muessen, beim
naechsten Auftragstyp an einer vierten.

WEITERER BLOCKER GEFUNDEN: ablauf.py holte detect_disc_type fest aus dem
LINUX-Treiber, in einem try/except. Unter Windows waere es damit IMMER None
gewesen und Rippen "hart verriegelt" — Rippy haette alles angezeigt und
nichts gerippt, ohne dass irgendwo ein Fehler stuende. Jetzt fragt es den
Treiber-Port.

WERKZEUGE: ripping.py und caps.py suchten nur im PATH. Auf dem Commander-PC
gemessen, vorher/nachher:

  vorher   check_makemkv_installed()  -> False (obwohl installiert)
           erkenne_encoder()          -> nur CPU
  nachher  MakeMKV   1.18.4  C:\Program Files (x86)\MakeMKV\makemkvcon64.exe
           HandBrake 1.11.2  ueber die API geholt, in 2,7 s
           Encoder   cpu-x264, cpu-x265, cpu-av1, VCE, VCE-AV1
           107 Presets, Ryzen 7 9700X, 16 Kerne, avx512f

VCE ist die Hardwarebeschleunigung der Radeon — die hat Rippy auf diesem
Rechner vorher nie gesehen, weil es HandBrake gar nicht fand.

NEUE ROUTEN: GET /system/werkzeuge (was liegt wo, in welcher Fassung, gibt
es Neueres) und POST /system/werkzeuge/{name}/holen. HandBrake kommt
vollautomatisch von GitHub. MakeMKV wird NICHT mitgeliefert — Rippy laedt
die offizielle Datei und startet sie (Black-Box-Trennung, KONZEPT.md § 6).
makemkv.com antwortete beim Bauen mit HTTP 525; das wird im Klartext
gemeldet, und eine selbst geholte Datei bleibt moeglich.

HERZSCHLAG: /capabilities las die workers-Tabelle, die bisher nur der
Celery-Herzschlag fuellte. Im Standalone-Betrieb stand dort "0 Worker" und
die Encoder-Auswahl im UI blieb LEER — auf einem Rechner, der alles kann.
Jetzt meldet sich der Prozess selbst, mit dem, was caps.py MISST.

GEMESSEN, aus der fertigen EXE (29,0 MB):
  bereit nach 1 s, keine Fehler im Log
  Werkzeuge: beide gefunden, mit Version und Pfad
  Worker: 1 (TobisNicerPC), 5 Encoder, 107 Presets

Die ganze Kette ist als Test festgehalten (test_kette.py): zustellen ->
einreihen -> Laeufer -> ablauf -> Job endet in einem EHRLICHEN Zustand.
Ohne Laufwerk geprueft, und das ist der wichtigere Fall: Ein Rip auf ein
totes Geraet muss zuegig scheitern, nicht auf "pending" haengenbleiben.

GEMESSEN: ruff sauber, 512 Tests gruen + 15 uebersprungen (vorher 489).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 11:27:54 +02:00
HitonabiandClaude Opus 5 288f9eeb8d feat(tools): Werkzeuge finden, holen und aktuell halten — Grundlage fuer Windows
Ampel / ampel (push) Failing after 47s
WAS: rippy/tools/ mit katalog.py (finden + Version) und beschaffen.py
(herunterladen, installieren, Update-Stand). ripping.py und caps.py fragen
den Katalog statt shutil.which.

DER BEFUND, DER DAS NOETIG MACHT: Der Bestand suchte AUSSCHLIESSLICH mit
shutil.which(). Im Container stimmt das — dort liegen beide Werkzeuge in
/usr/local/bin. Unter Windows findet es NICHTS, auch wenn alles installiert
ist: Windows-Programme liegen in Program Files, nicht im PATH. Am
28.08.2026 auf dem Commander-PC nachgesehen — MakeMKV lag unter
"C:\Program Files (x86)\MakeMKV\makemkvcon64.exe", which sah es nicht.

Fuer einen Rippy, der unter Windows eigenstaendig arbeiten soll, ist das der
Unterschied zwischen "laeuft" und "laeuft nicht". Vorher/nachher gemessen:

  vorher   check_makemkv_installed() -> False   (obwohl installiert)
  nachher  check_makemkv_installed() -> True
           build_makemkv_cmd()[0]    -> C:\Program Files (x86)\MakeMKV\makemkvcon64.exe

SUCHREIHENFOLGE, mit Begruendung im Modul: eingestellt > Rippys eigener
Werkzeug-Ordner > PATH > bekannte Installationsorte > Uninstall-Zweig der
Registry. Rippys eigener Ordner steht VOR dem System, damit eine selbst
gepflegte Fassung eine alte Systeminstallation schlaegt.

VERSION: HandBrakeCLI kann --version. makemkvcon KANN DAS NICHT (usage.txt
kennt keinen solchen Schalter) — die Version kommt aus dem Uninstall-Zweig.
Dort steht bei MakeMKV zwar eine Version, aber InstallLocation ist LEER
(nachgesehen); deshalb wird der Ordner ersatzweise aus DisplayIcon bzw.
UninstallString abgeleitet. Der Test dafuer hat sofort einen Fehler
gefunden: '"C:\...\uninstall.exe" /S' liess sich mit einem blossen
strip('"') nicht aufloesen.

BESCHAFFUNG, an echter Hardware gemessen:
  HandBrake  GitHub-Release-API -> 1.11.2, HandBrakeCLI-1.11.2-win-x86_64.zip
             geladen, entpackt, gestartet: meldet sich als 1.11.2. 2,8 s.
  MakeMKV    makemkv.com antwortete mit HTTP 525 (Cloudflare) — auch mit
             Browser-Kennung. Dieselbe Sperre, die im Projekt schon den
             Docker-Bau lahmlegt. Deshalb: Abruf wird versucht, ein
             Fehlschlag wird im Klartext gemeldet, und eine selbst geholte
             Datei laesst sich weiterhin verwenden. Ein Update-Server, der
             heute antwortet, darf keine Startbedingung fuer morgen sein.

DREI FALLEN, GEGEN DIE ES TESTS GIBT:
- Die .sig-Datei liegt im Release direkt neben dem ZIP und ist 566 Bytes
  gross. Wer nur nach "win" filtert, laedt sie.
- "1.9.2" ist als Zeichenkette GROESSER als "1.11.2". Ein Update-Hinweis, der
  ab Version zehn dauerhaft in die Irre fuehrt — und genau dort ist
  HandBrake gerade.
- Eine Fehlerseite kommt oft mit HTTP 200. Sie darf keine funktionierende
  Installation ersetzen: erst laden, pruefen, dann tauschen.

Und: Ist die neueste Version unbekannt (Quelle tot), steht NICHT "Update
verfuegbar" da. Eine Nichtauskunft ist keine Aussage.

GEMESSEN: ruff sauber, 489 Tests gruen + 15 uebersprungen (vorher 456).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 11:12:21 +02:00
HitonabiandClaude Opus 5 059183c651 feat(windows): V2-4 fertig — RippySetup.exe, Taskmanager-Eintrag, Deinstallation
Ampel / ampel (push) Failing after 46s
WAS: Eine 28,6-MB-Datei, drei Betriebsarten. Doppelklick installiert,
`--dienst` laeuft im Hintergrund, `--deinstallieren` raeumt sich weg.
Dazu packaging/windows/build.py, das sie baut.

DIE ZWEI COMMANDER-WUENSCHE, GEMESSEN:

1. EINTRAG IM TASKMANAGER
     ProcessName   Rippy
     Beschreibung  Rippy — automatisches Ripping
     Produkt       Rippy
     Version       2.0.0
   Der Prozessname kommt vom Dateinamen (bei der Installation kopiert sich
   die Datei als Rippy.exe), die Beschreibung aus einer eingebetteten
   Versions-Ressource. Ohne die steht dort nichts, und Windows SmartScreen
   sieht eine EXE ohne Herausgeberangabe genauso misstrauisch wie ein Mensch.

2. EINTRAG IN PROGRAMME UND FEATURES
   Aus der Registry zurueckgelesen, nicht behauptet:
     DisplayName      Rippy
     DisplayVersion   2.0.0
     Publisher        Rippy
     InstallLocation  <Zielordner>
     UninstallString  "<pfad>\Rippy.exe" --deinstallieren
     EstimatedSize    29241  (KiB)
     NoModify/NoRepair 1
   HKCU statt HKLM: Der Eintrag erscheint genauso in "Apps & Features", die
   Installation laeuft aber ohne UAC-Abfrage durch.

VOLLER KREISLAUF GEMESSEN: installieren -> Rippy.exe + rippy.ico liegen da,
Registry-Eintrag da, Autostart da; Dienst starten -> nach 1 s bereit, alle
sieben Endpunkte HTTP 200, Oberflaeche kommt; deinstallieren -> nach ~4 s
sind Datei, Ordner, Registry-Eintrag, Autostart UND das Aufraeum-Skript weg.

VIER FEHLER, DIE NUR DIE FERTIGE EXE ZEIGT:

1. rippy/store baute die Engine BEIM IMPORT, mit PostgreSQL als Vorgabe.
   Im Windows-Paket gibt es psycopg2 bewusst nicht -> die EXE starb sofort.
   Die Engine entsteht jetzt beim ersten Zugriff. Und der Fehler war
   grundsaetzlicher als der fehlende Treiber: Ein Modul, das beim Import
   schon eine Verbindung aufbaut, laesst sich gar nicht mehr umstellen —
   store.verbinden() kaeme immer zu spaet.

2. celery_client baute den Broker-Client beim Import. Dasselbe Muster, und
   `from celery_client import celery_client` loeste es sogar dann aus, wenn
   nie ein Rip angestossen wird. Jetzt traege, mit KeinBroker als klarer
   Ansage statt eines Importfehlers.

3. Die Selbstloeschung beim Deinstallieren ging als EIN Argument an cmd.
   Python maskiert dabei die inneren Anfuehrungszeichen — cmd suchte einen
   Dateinamen mit Backslashes davor, fand nichts und meldete nichts (>nul).
   Registry und Autostart waren weg, die 28-MB-Datei blieb liegen: ein still
   scheiternder Hintergrundprozess, wie ihn AGENTS.md beschreibt. Jetzt ein
   Aufraeum-Skript, das 15-mal versucht (die Onefile-EXE laeuft als ZWEI
   Prozesse; der Starter haelt die Datei nach dem Ende noch offen).

4. deinstallieren() raeumte den STANDARD-Ordner auf statt des tatsaechlichen.
   Wer nach --ziel D:\Rippy installiert hatte, dessen Dateien waeren
   geblieben, waehrend ein fremder Ordner angefasst worden waere. Der Pfad
   steht in der Registry (InstallLocation) und wird jetzt dort gelesen.

WAS NOCH NICHT GEHT, ausdruecklich: Ein RIP laesst sich unter Windows noch
nicht anstossen — die Zustellung laeuft weiter ueber Celery. Die Umstellung
auf die LocalQueue ist V2-5. Oberflaeche, Laufwerks-Erkennung, Auswurf und
alles Lesende laufen.

GEMESSEN: ruff sauber, 456 Tests gruen + 15 uebersprungen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 11:00:39 +02:00
HitonabiandClaude Opus 5 e5254c23f0 feat(daemon): V2-4 (Teil 3) — rippyd laeuft unter Windows, ohne Docker
Ampel / ampel (push) Failing after 46s
WAS: `rippyd` startet Rippy als EINEN Prozess — SQLite statt Postgres,
LocalQueue statt Celery/Redis, In-Process-Bus statt Redis Pub/Sub, UI von
FastAPI statt von nginx. Dieselbe API, dasselbe UI, derselbe Rip-Code.

GEMESSEN (Windows 11, frische Python-3.12-Umgebung, ohne Docker/Postgres/Redis):

  bereit nach            1 s
  /api/health            200      /api/settings          200
  /api/devices           200      /api/logs              200
  /api/jobs              200      /api/capabilities      200
  /api/health/vorraete   200      /  (Weboberflaeche)    200

  Ereignis-Waechter      gesund: true, alter_sekunden: 0.5
  SSE-Strom              liefert `event: snapshot` mit vollem Zustand
  SQLite                 angelegt, WAL aktiv, alle Tabellen da

ZWEI FEHLER, DIE NUR DER ECHTE LAUF ZEIGT:

1. STARLETTE REICHT LIFESPAN NICHT AN MOUNT-UNTERANWENDUNGEN WEITER.
   Das UI ruft /api/..., im Docker-Betrieb entfernt der nginx das Praefix.
   Ohne nginx haengt die API als Unteranwendung unter /api — und ihr
   startup_event lief nie. Folge: db.init_db() nicht ausgefuehrt,
   "no such table: settings", HTTP 500 auf /jobs, /settings, /logs,
   /capabilities, und der SSE-Strom blieb stumm. /api/health antwortete
   trotzdem mit 200, weil die Route keine Datenbank braucht — der
   Fehlschlag sah also aus wie "laeuft". Behoben ueber einen eigenen
   lifespan, der den der Unteranwendung mit ausloest.

2. EIN print() HAT DEN GANZEN START UMGEBRACHT.
   UnicodeEncodeError: 'charmap' codec can't encode characters
   -> ERROR: Application startup failed. Exiting.
   Windows-Konsolen arbeiten mit cp1252; Rippys Meldungen sind deutsch und
   voller Umlaute und Warnzeichen. Das Bittere: Es war nicht die WARNUNG,
   die den Start verhindert hat, sondern der VERSUCH, sie auszugeben.
   Behoben mit encoding="utf-8" UND errors="replace" — eine Ausgabe darf
   unter keinen Umstaenden etwas abbrechen koennen.

BEFUND ZUR HARDWARE (kein Codefehler): Nach dem Auswurf-Test hat sich das
USB-Laufwerk vom Bus getrennt. Windows kennt es nur noch als Karteileiche
(Get-PnpDevice -Class CDROM -> Status "Unknown", Win32_CDROMDrive leer),
weder ein Laufwerksbuchstabe noch \.\CdRom0..4 sind da. Die leere
Geraeteliste ist damit die RICHTIGE Antwort. Bei bus-versorgten
USB-Laufwerken ist das bekannt — der Auswurf zieht kurz mehr Strom.

GEMESSEN: ruff sauber, 440 Tests gruen + 15 uebersprungen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 10:34:51 +02:00
HitonabiandClaude Opus 5 9d95c95d79 feat(drives): Windows-Treiber an echter Disc BEWIESEN
Ampel / ampel (push) Failing after 46s
WAS: Die Hardware-Schicht des Windows-Treibers ist nicht mehr nur gebaut,
sondern gemessen. Messwerte stehen im Modul-Docstring, der gemessene
BD-50-Wert als Testfall in test_cdrom.py.

GEMESSEN (28.08.2026, LG BU40N extern, Laufwerk G:, echte BD-50):

  drive_status()                 -> 4 (CDS_DISC_OK), sofort
  IOCTL_CDROM_DISK_TYPE          -> DATA_TRACK
  IOCTL_DISK_GET_LENGTH_INFO     -> 48 149 364 736 Bytes = 44,84 GiB
  disc_status()                  -> 101 (CDS_DATA_1)
  detect_disc_type()             -> 'bluray'
  device_info()['status']        -> 'ready'
  device_info()['type']          -> 'bluray'

  auswerfen_versuchen()          -> True, 2,41 s
  drive_status() davor / danach  -> 4 / 1

DIE LETZTE ZEILE IST DER EIGENTLICHE BEWEIS. Der Auswurf haengt nicht am
Rueckgabewert des Steuercodes, sondern am ZUSTAND davor und danach: Die
Disc war drin (4) und ist danach draussen (1). Genau das fehlte in v1
monatelang — dort quittierte das ioctl Erfolg, die Schublade blieb zu, und
im Log stand "Disc ausgeworfen".

Die 44,84 GiB pruefen die Schwelle gleich mit: Eine BD-50 liegt knapp unter
den 55 GiB, ab denen classify() auf 'uhd' geht, und wird korrekt als
'bluray' eingeordnet. Wer die Schwelle senkt, macht aus jeder BD-50 eine
UHD — und Rippy waehlte dann das falsche Kompressions-Preset. Der Testfall
haelt den gemessenen Wert fest.

Offen bleibt allein die Ereignis-Erkennung (WM_DEVICECHANGE) — die wird
erst gebaut.

Nebenbei: Beim Eintragen der Messwerte sind drei echte NUL-Bytes in die
Datei geraten (eine Escape-Ebene im Schreib-Skript verschluckt). Python
lehnt so eine Datei rundheraus ab ("source code string cannot contain null
bytes") — im Binaermodus repariert und gegengeprueft.

GEMESSEN: ruff sauber, 430 Tests gruen + 14 uebersprungen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 10:04:29 +02:00
HitonabiandClaude Opus 5 3d7f3b1680 feat(drives): V2-4 (Teil 2) — main.py laedt unter Windows, Treiber gemessen
Ampel / ampel (push) Failing after 46s
WAS: rippy/drives/__init__.py waehlt den Treiber fuer DIESE Maschine.
main.py und prescan.py fragen ihn, statt fest den Linux-Treiber zu
importieren. Damit ist der Blocker fuer den nativen Windows-Betrieb weg.

GEMESSEN, vorher (frische Python-3.12-Umgebung unter Windows):
  >>> import main
  ModuleNotFoundError: No module named 'fcntl'

GEMESSEN, nachher:
  main.py laedt unter Windows: JA
    Treiber:   rippy.drives.windows
    Routen:    61
    Laufwerke: ['\\.\G:']

Der Import stand in rippy/drives/linux.py -> detection.py -> fcntl. Genau
dafuer gibt es den Port: Der Aufrufer sagt WAS, nicht WIE. test_treiberwahl.py
haelt ausserdem fest, dass BEIDE Treiber denselben Satz Funktionen anbieten —
sonst faellt eine fehlende erst im Betrieb als AttributeError auf, und zwar
auf der anderen Plattform.

DER TREIBER AN ECHTER HARDWARE (LG BU40N extern, Laufwerk G:, LEER):
  GetDriveTypeW("G:\\")              -> 5 (DRIVE_CDROM)
  list_optical_devices()             -> ['\\.\G:']
  CreateFileW(r"\.\G:")             -> Handle 380
  CHECK_VERIFY2 bei leerem Laufwerk  -> ERROR_NOT_READY (21)
  drive_status()                     -> 1 (CDS_NO_DISC)
  detect_disc_type()                 -> 'no_disc'
  device_info()['status']            -> 'empty'
  MEDIA_REMOVAL (entriegeln)         -> Erfolg,   0,1 ms
  EJECT_MEDIA                        -> Erfolg, 664,8 ms

Die 664,8 ms sind der Beleg, dass wirklich etwas passiert ist: Ein
abgelehnter Steuercode kommt in rund 2 ms zurueck.

BEFUND, DER EIN PLACEBO VERHINDERT HAT: IOCTL_STORAGE_LOAD_MEDIA (Schublade
einziehen) antwortet auf diesem Laufwerk mit ERROR_INVALID_FUNCTION. Bei
flachen und externen Laufwerken ist das die Regel. Deshalb gibt es bewusst
KEINE einziehen()-Funktion — ein Knopf "Schublade schliessen", der auf der
Haelfte aller Laufwerke stillschweigend nichts tut, waere genau die Sorte
Placebo, die in Etappe 19 aufgeraeumt wurde.

Dazu eine DeprecationWarning behoben: '\G' im Docstring ist keine gueltige
Escape-Sequenz und waere in einer kuenftigen Python-Version ein harter Fehler.

NOCH NICHT gemessen: das Verhalten MIT eingelegter Disc (Typ-Erkennung ueber
die Groesse, und ein Auswurf, bei dem wirklich etwas drin ist).

GEMESSEN: ruff sauber, 429 Tests gruen + 13 uebersprungen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 09:55:15 +02:00
HitonabiandClaude Opus 5 b723fee3a2 feat(drives): V2-4 (Teil 1) — Windows-Laufwerkstreiber, ohne Hardware geprueft
Ampel / ampel (push) Successful in 45s
WAS: rippy/drives/windows.py mit denselben zwei Vertraegen wie die
Linux-Fassung (auswerfen_versuchen gibt False zurueck, eject wirft).
Dazu win_ioctl.py: die Win32-Steuercodes, HERGELEITET statt abgeschrieben.

WARUM ctypes und nicht pywin32: 20 MB zusaetzliche Abhaengigkeit, die in
jedes PyInstaller-Paket muss und bei jedem Python-Wechsel neu passen will.
Gebraucht werden fuenf Funktionen aus kernel32 — die spricht ctypes direkt an.

DIE STEUERCODES WERDEN AUSGERECHNET, NICHT ABGETIPPT: win_ioctl.py enthaelt
das CTL_CODE-Makro aus winioctl.h als Funktion; jede Konstante wird daraus
gebildet. test_win_ioctl.py rechnet das Ergebnis gegen die in der
Microsoft-Dokumentation stehenden Zahlen. Grund: Ein falscher IOCTL-Code
meldet kein "unbekannter Befehl", sondern ERROR_INVALID_FUNCTION — und das
liest sich wie "dieses Laufwerk kann das nicht". Man sucht dann am Geraet
statt an einer Zahl. AGENTS Regel D, ernst genommen.

DIE ZWEI PORT-REGELN GELTEN AUCH HIER:
- Auswerfen heisst entriegeln, auswerfen, NACHSEHEN. Unter Linux wurde am
  26.07.2026 gemessen, dass ein verriegeltes Laufwerk den Auswurf mit ERFOLG
  quittiert und nichts tut. IOCTL_STORAGE_EJECT_MEDIA meldet ebenfalls nur
  die Annahme des Befehls — also wird auch hier nachgesehen
  (CHECK_VERIFY2 muss ERROR_NOT_READY liefern).
- Ein unzugaengliches Laufwerk ist UNBEKANNT, nicht leer. device_info kennt
  deshalb drei Zustaende, nicht zwei.

EIN FEHLER, DEN DIE TESTS SOFORT GEFANGEN HABEN: Win32Fehler setzte
self.winerror VOR super().__init__(). Nachgemessen: Ein zweiargumentiges
OSError.__init__(code, text) setzt winerror wieder auf None. Damit erkannte
_medium_da ERROR_NOT_READY nicht mehr, hielt jedes leere Laufwerk fuer einen
echten Fehler und meldete "unbekannt" statt "leer". Vier Tests rot, Ursache
in einer Minute gemessen statt geraten.

⚠️ WAS HIER NICHT BEWIESEN IST: dass echte Hardware sich so verhaelt. Das
Laufwerk ist derzeit nirgends angeschlossen. Der Ablauf, die
Fehlerunterscheidung und die Typ-Zuordnung sind gegen ein nachgebautes
Laufwerk geprueft (51 Tests, laufen auf jeder Plattform) — die Hardware-
Schicht gilt bis zu einer Messung als GEBAUT, nicht als BEWIESEN.

GEMESSEN: ruff sauber, 400 Tests gruen + 4 uebersprungen (vorher 378).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 09:45:43 +02:00
HitonabiandClaude Opus 5 4337253797 docs: SAVEPOINT v4.0-beta — V2-0 bis V2-3 stehen, Laufwerk fehlt an der VM
Ampel / ampel (push) Successful in 41s
Vier Etappen gebaut und deployt, Polling ist weg (121 Anfragen/min je Tab
-> ~2 einmalige Abrufe), SSE-Strom live belegt.

Wichtig fuer die naechste Sitzung: Das optische Laufwerk haengt NICHT mehr
an der VM. Rippy laeuft als reine Komprimier-Maschine. Und der Vorfall,
der das aufgedeckt hat, ist dokumentiert — ein devices:-Eintrag in compose
ist eine Startbedingung, und die hat api, worker und ui stillgelegt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 09:37:23 +02:00
HitonabiandClaude Opus 5 05ab655116 fix: ein fehlendes Laufwerk darf Rippy nicht am Starten hindern
Ampel / ampel (push) Successful in 40s
WAS: Die `devices:`-Eintraege fliegen aus docker-compose.yml. Was dieser
Host wirklich hat, ermittelt deploy/geraete-override.sh und schreibt es in
docker-compose.override.yml — die zieht Compose von allein dazu, der
Befehl bleibt `docker compose up -d`.

WARUM (Vorfall heute, 28.08.2026): Das USB-Laufwerk haengt nicht mehr an
der VM. Ein ganz normaler Deploy legte daraufhin api, worker UND ui still:

  Error response from daemon: error gathering device information while
  adding custom device "/dev/sr0": no such file or directory

Ein `devices:`-Eintrag ist eine STARTBEDINGUNG — und keiner der drei
Container braucht zum STARTEN ein Laufwerk. Rippy war unten, und die
Meldung stand mitten im Build-Rauschen (dieselbe Klasse wie das geschluckte
`|| echo` beim .env-Kopieren am 26.07.).

DER WIDERSPRUCH WAR AELTER ALS DER VORFALL: install.sh sagt bei fehlendem
Laufwerk ausdruecklich "die Installation laeuft trotzdem durch; diese
Maschine dient dann als reine KOMPRIMIER-Maschine" — die Compose-Datei sah
das anders. Eine Maschine ohne Laufwerk ist ein VORGESEHENER Betriebsfall:
der Windows-Worker und der GPU-Encoder sind genau das.

Das Skript uebernimmt die Erkennung aus install.sh unveraendert: sr- und
sg-Knoten ueber die SCSI-Adresse in /sys abgeglichen, nicht geraten. Und
es schreibt die Override AUCH dann, wenn kein Laufwerk da ist — sonst
bliebe eine alte Datei mit /dev/sr0 liegen und der Fehler waere derselbe,
nur schwerer zu finden, weil sie gitignored ist und in keinem Diff auftaucht.

deploy.sh ruft es vor dem Start auf.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 09:35:48 +02:00
HitonabiandClaude Opus 5 95705c8d88 feat(ui): V2-3 (Teil 2) — das UI haengt am Ereignis-Strom, Taktgeber raus
Ampel / ampel (push) Successful in 47s
WAS: EventStreamProvider haelt EINE SSE-Verbindung fuer die ganze
Anwendung. Dashboard, Log-Kasten, Log-Seite, Laufwerksliste und
Worker-Liste beziehen ihren Zustand daraus. Sieben von neun setInterval
sind weg.

GEMESSEN AN DEN TAKTGEBERN, je offenem Tab:
  Dashboard      5 Endpunkte / 4 s   75/min  ->  0
  Log-Kasten     2 Endpunkte / 5 s   24/min  ->  0
  Laufwerke      1 Endpunkt  / 5 s   12/min  ->  0
  Log-Seite      1 Endpunkt  /10 s    6/min  ->  0 (+1 Abruf beim Oeffnen)
  Worker-Liste   1 Endpunkt  /15 s    4/min  ->  0 (+1 Abruf beim Oeffnen)
                                     ------
                                     121/min ->  ~2 einmalige Abrufe

Zwei Taktgeber bleiben bewusst: FirstRunWizard (laeuft nur VOR der
Einrichtung) und RipTargetModal (nur solange der Dialog offen ist).

DIE REGEL IST UMGEZOGEN, NICHT VERSCHWUNDEN: Ein Abriss ist keine
Aussage ueber die Welt. Der Provider BEHAELT bei einem Fehler den letzten
Stand und setzt nur `verbunden` auf false; es wird nie eine Liste geleert.
Jede Komponente uebernimmt einen Wert nur, wenn er wirklich da ist —
`devices === null` heisst "konnte nicht nachsehen", nicht "keine
Laufwerke". Das war der Fehler hinter "wird oft neu geladen".

EIN PLACEBO WENIGER: Oben rechts stand ein fest verdrahtetes "ONLINE" mit
pulsierendem Punkt — es leuchtete gruen, auch wenn die API tot war. Jetzt
zeigt es LIVE oder VERBINDUNG WEG, und im Tooltip steht, wann die letzte
Meldung kam.

DER SERVER SCHIEBT JETZT AUCH DEN SERVER-ZUSTAND: Neuer Ereignistyp
system.status (Hardware, Worker, Ablageziele) im 15-Sekunden-Takt des
Waechters — EINMAL im Server statt 15/min je Tab. Nur mitgeschickte
Schluessel werden uebernommen; ein fehlender heisst "behalte deinen Stand".

DAZU EIN FORMATFEHLER GEFUNDEN UND BEHOBEN: /logs bildet ts -> timestamp
ab, mein Snapshot lieferte die rohe DB-Zeile. Das UI haette "Invalid Date"
gezeigt — und zwar NUR im Live-Betrieb, nicht beim manuellen Neuladen.
Jetzt gibt es _log_zeile() einmal, benutzt von beiden.

UND EINEN ZWEITEN: system_lesen lief per asyncio.get_event_loop() in einem
Worker-Thread — dort ist das NICHT die laufende Schleife. Die Coroutine
waere nie gelaufen. Die Schleife wird jetzt im Startup festgehalten.

GEMESSEN: ruff sauber, 378 Tests + 3 uebersprungen, `npm run build`
durch (1650 Module). Der Live-Beweis steht noch aus — er kommt mit dem
Deploy.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 09:32:50 +02:00
HitonabiandClaude Opus 5 f097a0b59d feat(bus): Waechter — Worker-Aenderungen werden zu Ereignissen
Ampel / ampel (push) Successful in 43s
WAS: rippy/bus/waechter.py sieht im Takt von 1 s in der Datenbank nach und
meldet Aenderungen an den Bus: job.created / job.phase / job.progress /
job.finished und log.line. 12 Tests, ohne Datenbank lauffaehig.

WARUM ES IHN BRAUCHT: Der Bus verteilt innerhalb EINES Prozesses. Der
Worker ist aber ein eigener Prozess, im Docker-Betrieb ein eigener
Container, im verteilten Betrieb ein anderer Rechner. Ohne Bruecke wuesste
die API nichts vom Fortschritt eines Rips.

WARUM UEBER DIE DATENBANK und nicht per HTTP-Rueckruf oder Redis:
- HTTP-Rueckruf: jeder Fortschrittswert haengt an einer Verbindung, ein
  kurzer API-Neustart liesse Ereignisse verschwinden, und der Worker
  braeuchte zusaetzliche Konfiguration.
- Redis Pub/Sub: sauber, kommt im verteilten Betrieb (V2-5) — aber der
  Standalone-Betrieb hat bewusst KEIN Redis, das war der Punkt von V2-2.
- Die Datenbank ist ohnehin die Wahrheit ueber den Job-Zustand, ist in
  JEDEM Modus da, und der Worker schreibt dort sowieso hin.

"Ist das nicht wieder Polling?" Doch — aber einmal, lokal und billig:
vorher N Tabs x 9 Endpunkte alle 4-5 s ueber HTTP durch nginx durch das
Rate-Limit; jetzt EINE Abfrage pro Sekunde von vier Spalten. Das Ziel war
nie "nirgendwo nachfragen", sondern: der Browser fragt nicht mehr.

DER TEST HAT EINEN ECHTEN FEHLER GEFUNDEN: Der Docstring versprach "erst
neue Jobs, dann Aenderungen", die Schleife lieferte aber die Reihenfolge
des dicts — ein Client haette ein job.progress fuer einen Job bekommen
koennen, den er noch gar nicht kennt. Jetzt drei getrennte Durchlaeufe.
Das Versprechen war richtig, der Code nicht.

Und er stirbt nicht still: Fehler gehen ins Log UND als system.notice an
den Bus (erster Fehlschlag, danach jeder zehnte), und lebt_seit_sekunden()
macht sein Alter abfragbar — AGENTS.md, "wer einen Vorrat anlegt, macht
sein Alter abfragbar".

GEMESSEN: ruff sauber, 371 Tests gruen + 3 uebersprungen (vorher 359).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 09:23:03 +02:00
HitonabiandClaude Opus 5 1fbe2cfc55 fix(test): Snapshot-Tests brauchten eine Datenbank — die Ampel hat keine
Ampel / ampel (push) Successful in 40s
WAS: test_snapshot_* ersetzen den Store per monkeypatch, statt
db.list_jobs() wirklich aufzurufen.

WARUM ROT (Lauf 170): Die Ampel startet KEINE Postgres. Mein neuer Test
war der erste im ganzen Repo, der eine Datenbank angefasst hat — alle
anderen in test_api_smoke.py pruefen nur Importe und Routen. Auf der VM
und lokal waere es nie aufgefallen: dort ist eine DB da bzw. der ganze
Test wird uebersprungen (kein fcntl unter Windows).

Geprueft wird die Snapshot-LOGIK ("konnte nicht nachsehen" ergibt None,
nicht []), nicht die Datenbank. Also gehoert die Datenbank da nicht rein.

Dazu ein zweiter Test: der Snapshot muss alle vier Bereiche liefern
(jobs/workers/logs/devices) — ein Client, dem einer fehlt, muesste den
Rest raten und fiele auf Polling zurueck.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 09:20:58 +02:00
HitonabiandClaude Opus 5 55db9eb13f feat(api): V2-3 (Teil 1) — Ereignis-Bus und SSE-Endpunkt /api/v2/events
Ampel / ampel (push) Failing after 41s
WAS: rippy/bus mit Ereignis-Schema, In-Process-Treiber und Ringpuffer.
Dazu der SSE-Strom in der API: erst ein Snapshot, danach nur Deltas,
mit lueckenloser Wiederaufnahme ueber Last-Event-ID.

WARUM: Ein offener Tab plus ein Worker verursachen heute rund 133
Anfragen pro Minute (Dashboard 75 + Log-Kasten 24 + Laufwerke 12 +
Worker-Liste 4 + Log-Seite 6 + Tray 12). Das Rate-Limit stand einmal
UNTER dieser Zahl — daher die sich leerende Job-Liste im Sekundentakt.
Mit einer offenen Verbindung sind es null.

DREI EIGENSCHAFTEN, ALLE AUS v1-FEHLERN:

1. Der Bus traegt NUR Nachrichten ueber Aenderungen, nie den Zustand.
   Wer den Zustand will, fragt den Store. Damit kann ein verpasstes
   Ereignis auch keinen Zustand loeschen — anders als beim fuenffachen
   `catch(() => [])` im alten UI, wo jeder fehlgeschlagene Abruf
   "es gibt keine Jobs" bedeutete.
2. Eine zu grosse Luecke wird ANGESAGT, nicht verschluckt. nachliefern()
   gibt None ("hol dir ein ganzes Bild") statt [] ("nichts verpasst") —
   dieselbe Unterscheidung wie timeout-Rueckgabe 124 bei den Netzpfaden.
   Stillschweigend weiterzumachen waere schlimmer: Das UI hielte sich
   fuer aktuell und waere es nicht.
3. Der Snapshot meldet unlesbare Laufwerke als None, nicht als leere
   Liste. "Konnte nicht nachsehen" ist etwas anderes als "gibt es nicht".

Ein unbekannter Ereignistyp fliegt beim Senden HOCH statt durchzugehen.
Ein Tippfehler waere sonst der stillste aller Fehlschlaege: Nachricht
raus, kein Empfaenger, nirgends ein Hinweis.

Ein langsamer Zuhoerer (Tab im Hintergrund, lahmes Handy) bremst den
Sender nicht — er wird markiert und bekommt beim naechsten Mal einen
Snapshot. Ein Rip darf nicht auf einen Browser warten.

GEMESSEN: ruff sauber, 359 Tests gruen + 3 uebersprungen (vorher 346).
13 neue Bus-Tests laufen auf jeder Plattform; die vier SSE-Tests haengen
an main.py und laufen damit in der Ampel.

NOCH OFFEN in V2-3: das UI auf den Strom umstellen (neun setInterval)
und die Ereignisse an den Zustandsaenderungen ausloesen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 09:09:33 +02:00
HitonabiandClaude Opus 5 d2645f87e8 feat(core): V2-2 — SQLite hinter demselben Port, Auftrags-Queue mit Lease
Ampel / ampel (push) Successful in 39s
WAS: Der Store spricht jetzt beide Datenbanken (PostgreSQL wie bisher,
SQLite fuer den Standalone-Betrieb). Dazu die LocalQueue: Auftraege als
Tabelle, Vergabe per bedingtem UPDATE, Lease statt Zombie-Jagd. Und die
Konfigurationsschicht mit EINER Praezedenz fuer alle drei Betriebsarten.

WARUM: Ohne SQLite und ohne broker-lose Queue gibt es keinen Standalone-
Betrieb — und ohne den keine Windows-App und keine Headless-Variante.
Beides haengt an dieser Etappe.

DER GRUNDSATZ (KONZEPT-V2.md §3.1): Die Datenbank ist die Wahrheit ueber
den Job-Zustand, der Broker ist nur der Wecker. Daraus folgt die ganze
Queue: Ein Auftrag ist eine Zeile mit claimed_by und lease_until, ein
Knoten uebernimmt ihn per bedingtem UPDATE (es gewinnt genau EINER, auch
wenn zehn gleichzeitig fragen), und er haelt ihn per Lease am Leben.
Laeuft die Lease ab, ist der Auftrag frei — egal ob Absturz, Netzausfall
oder gezogener Stecker.

Damit gibt es den Zustand "laeuft, aber niemand arbeitet daran" nicht
mehr, den v1 mit zombies.py (206 Zeilen + 263 Zeilen Tests) nachtraeglich
einsammeln musste. Er kann hoechstens 60 Sekunden bestehen und heilt sich
dann selbst. Beides ist geprueft: zwei Knoten bekommen NICHT denselben
Auftrag, und eine abgelaufene Lease gibt ihn wirklich wieder her.

KEINE QUEUE-BIBLIOTHEK (Taskiq/ARQ/Celery-lite), Begruendung im
Modul-Docstring: Der teure Teil ist kein Task, sondern ein 30-90-Minuten-
Subprozess mit Fortschritts-Parsing. Was die Bibliotheken loesen, ist
nicht das Problem; was das Problem ist, muss man ohnehin selbst bauen.

ABWEICHUNG VOM ENTWURF — KEIN ALEMBIC (in KONZEPT-V2.md §3.2 vermerkt):
Die Datenbank auf der VM gibt es schon, Alembic muesste sie erst
stempeln — ein Handgriff auf einer laufenden Installation, den beim
naechsten Deploy jemand vergisst. Und es gibt hier nichts zu
versionieren: drei nachgetragene Spalten. store.migrieren() fragt
stattdessen per inspect() nach und legt nur Fehlendes an; das laeuft auf
beiden Dialekten. Der alte Weg (ADD COLUMN IF NOT EXISTS) war korrekte
Postgres-Syntax und waere auf SQLite gebrochen.

EIN KONSTRUKTIONSFEHLER, SELBST GEFUNDEN: lokal.py hatte anfangs
`from rippy.store import engine` — ein Import bindet den Wert EINMAL, ein
spaeteres store.verbinden() waere nie angekommen, und das Modul haette
weiter mit der alten Datenbank gesprochen. Jetzt wird store.engine zur
Aufrufzeit gelesen; die Warnung steht an beiden Stellen im Code.

GEMESSEN: ruff sauber, 346 Tests gruen + 3 uebersprungen (vorher 301).
Neu: 30 Tests gegen ECHTES SQLite (kein Fake) — inklusive der Gegenprobe,
dass WAL und busy_timeout wirklich gesetzt sind, und dass migrieren()
eine weggenommene Spalte zurueckholt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 09:03:46 +02:00
HitonabiandClaude Opus 5 7558be4854 fix: CRLF in gui.py wiederherstellen (Zeilenenden-Falle in V2-1)
Ampel / ampel (push) Successful in 39s
WAS: docker/worker/gui.py war CRLF und ist beim Umstellen des db-Imports
komplett auf LF gekippt — 1520 Zeilen Diff-Rauschen fuer EINE geaenderte
Zeile. Zeilenenden zurueckgedreht, der Inhalt bleibt.

WARUM ES PASSIERT IST: Mein Umschreib-Helfer las mit
io.open(p, encoding="utf-8") — im Textmodus wandelt Python CRLF beim LESEN
zu LF — und schrieb mit newline="" zurueck, also LF. Betroffen war nur
gui.py; die uebrigen angefassten Dateien sind ohnehin LF.

Richtig waere newline="" AUCH beim Lesen gewesen (dann bleiben die
Zeilenenden im String stehen) oder gleich der Binaermodus.

Das steht so schon in den Projekt-Notizen und ist mir trotzdem passiert,
weil der Helfer generisch war und die Datei nicht danach aussah.
Gegenprobe: `file docker/worker/gui.py` sagt wieder "with CRLF line
terminators", und `git diff HEAD~2 -- gui.py` zeigt genau eine Zeile.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 08:55:21 +02:00
HitonabiandClaude Opus 5 dd1d0b7365 refactor(core): V2-1 — die vier Ports, ein Store, ein Laufwerks-Treiber
Ampel / ampel (push) Successful in 40s
WAS: rippy/ports.py beschreibt Store/Queue/Bus/Drives als Protocol. Zwei
weitere Doppelungen sind zusammengelegt: db.py (API+Worker) wird
rippy/store, und der Auswurf (api/devices.py + ripping.wirf_disc_aus)
wird rippy/drives/linux. Verhalten unveraendert.

WARUM: Drei Betriebsarten tragen nur, wenn ein Modus die Auswahl der
Treiber hinter vier Nahtstellen ist statt ein eigener Codestand
(KONZEPT-V2.md §1). Diese Etappe zieht die Nahtstellen ein, ohne schon
einen zweiten Treiber zu haben — die kommen in V2-2 (SQLite/LocalQueue)
und V2-4 (Windows).

DIE UNANGENEHMERE DOPPELUNG WAR DER AUSWURF: Er stand zweimal da, mit
UNTERSCHIEDLICHEN Vertraegen — devices.eject wirft OSError, ripping.
wirf_disc_aus gibt False zurueck und wirft nie. Beides ist richtig fuer
seine Seite (Browser-Meldung gegen "ein Rip stirbt nicht an einer
klemmenden Schublade"). Jetzt liegt EINE Mechanik darunter
(auswerfen_mit_grund) und beide Vertraege unveraendert darueber.
Die API-Fassung war ausserdem NIE getestet — jetzt schon, inklusive
"reicht ENOENT/EPERM unveraendert weiter".

get_settings hatte den einzigen echten Verhaltensunterschied der beiden
db.py: die Worker-Fassung schluckte jeden Fehler und gab {} zurueck.
Nicht still entschieden, sondern sichtbar gemacht — der Parameter
bei_fehler_leer steht jetzt in der Signatur, mit der offenen Frage im
Docstring. {} heisst fuer den Aufrufer "nichts gesetzt", nicht "konnte
nicht nachsehen"; das ist dieselbe Klasse wie catch(() => []) im alten
UI. Zu entscheiden in V2-2.

ZWEITER BEINAHE-FEHLER DIESER ETAPPE: linux.py importierte detection
auf Modulebene — und das zieht fcntl. Damit waere ripping.py und ueber
es der NATIVE WINDOWS-WORKER nicht mehr ladbar gewesen. Diesmal haben
die Tests es sofort gefangen (4 Sammelfehler). Behoben an der Wurzel:
Konstanten und die reine classify() leben jetzt in drives/cdrom.py,
ganz ohne fcntl. Nebengewinn — die classify-Tests liefen bisher NUR in
der Ampel ("erst nach dem Push bewiesen") und laufen jetzt ueberall.

Ausserdem: .dockerignore-Testmuster brauchen **, sonst greifen sie nur
in der obersten Ebene. Im laufenden Container nachgezaehlt: 30 test_*.py
lagen in den Images.

GEMESSEN: ruff sauber, 301 Tests gruen + 1 uebersprungen (vorher 290;
+4 neue eject-Tests, +7 classify-Tests die jetzt lokal laufen). Kein
Modul liegt mehr doppelt im Repo.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 08:54:28 +02:00
HitonabiandClaude Opus 5 edfe0d4313 docs: SAVEPOINT fuer v4.0-alpha — v2-Konzept entschieden, Etappe V2-0 gruen
Ampel / ampel (push) Successful in 39s
WAS: Neuer Kopfeintrag mit dem gemessenen Zustand (b98dc5e, Ampel gruen,
290 Tests, 0 doppelte Module), den drei Commander-Entscheiden, der
gebauten Etappe V2-0 und dem naechsten Schritt.

WARUM: AGENTS-Workflow Punkt 5 — die naechste Sitzung faengt nicht bei
Null an. Besonders wichtig diesmal, weil der Deploy auf die VM bewusst
aussteht und beim ersten Deploy nach V2-0 zwei Dinge gezielt zu pruefen
sind (liegt /app/rippy in beiden Containern, enthaelt das Worker-Zip
den Ordner).

Dokumentiert ist ausserdem der Fehler, den der Umbau fast ausgeliefert
haette: ein "try/except ImportError" um den detection-Import in
tasks.py haette einen falschen Modulpfad STILL geschluckt und auf Linux
jeden Rip verweigert. Die Lehre steht dabei — bei einem Modul-Umzug
reicht grep auf Zeilenanfaenge nicht.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 08:41:29 +02:00
HitonabiandClaude Opus 5 b98dc5eef5 refactor(core): V2-0 — gemeinsames Paket rippy statt drei Zwillingsdateien
Ampel / ampel (push) Successful in 41s
WAS: Neues Paket src/rippy (core/drives/rip). detection.py,
makemkv_daten.py und notify.py lagen je ZWEIMAL im Repo — unter
docker/api UND docker/worker, byte-identisch. Jetzt gibt es sie einmal;
beide Container importieren dieselbe Datei. Verhalten unveraendert.

WARUM: Es gab kein geteiltes Paket zwischen den Containern, deshalb die
Kopien. docker/api/db.py sagt es im Kopfkommentar selbst: "Wer die
Struktur aendert, aendert BEIDE Dateien." Ein Waechter-Test
(test_zwillinge_sind_byteweise_identisch) hat das mechanisch
abgesichert — er war noetig, weil die Konstruktion falsch war. Erste
Etappe des v2-Plans (KONZEPT-V2.md §8.3).

IM EINZELNEN:
- src/rippy/{core/notify, drives/detection, rip/makemkv_daten}.py
- conftest.py in der Wurzel legt src/ auf den sys.path (die Ampel ruft
  pytest dort auf).
- Beide Dockerfiles kopieren src/rippy nach /app/rippy — /app ist
  Arbeitsverzeichnis und uvicorn-App-Dir, also ohne PYTHONPATH findbar.
- worker_setup_paket packt das Paket ausdruecklich mit ins Zip: die
  Schleife sah nur die oberste Ebene, ein Unterordner waere nie
  mitgekommen und der Windows-Worker beim Start gestorben.
- Die zwei Test-Dateien fuer makemkv_daten sind zu einer verschmolzen
  (die Faelle aus beiden). Damit entfaellt auch der importlib-Umweg im
  Worker-Test: der war noetig, weil bei "pytest -q" aus der Wurzel
  docker/api zuerst eingesammelt wird und jeder weitere Import nur noch
  den sys.modules-Cache trifft — die Worker-Kopie wurde also nie
  angefasst. Netto -13 doppelte Tests, +2 neue (siehe unten).

EIN FEHLER, DEN DER UMBAU FAST AUSGELIEFERT HAETTE: In tasks.py steht
der detection-Import in einem "try/except ImportError" — absichtlich,
denn der native Windows-Worker hat kein fcntl und soll trotzdem
starten. Das except verschluckt aber JEDEN ImportError, auch einen
falschen Modulpfad. Auf Linux haette der Worker ab sofort still
detect_disc_type=None gesetzt und jeden Rip verweigert, ohne dass
irgendwo ein Fehler stuende — genau die Klasse "still scheiternder
Hintergrund-Prozess" aus AGENTS.md. Gefunden ueber eine zweite Suche
mit eingerueckten Treffern.

Waechter dagegen: src/rippy/test_paket.py prueft mit
importlib.util.find_spec (fuehrt nichts aus, laeuft also auch auf
Windows ohne fcntl), dass es die drei Modulpfade wirklich gibt. Beim
Wegnehmen von detection.py gegengeprueft: Test wird rot, nach
Wiederherstellen gruen.

GEMESSEN: ruff sauber, 290 Tests gruen + 1 uebersprungen (lokal, ohne
die zwei Linux-only-Module). Kein Modul liegt noch doppelt im Repo.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 08:38:29 +02:00
HitonabiandClaude Opus 5 20675a98fa docs: Konzept fuer Rippy v2 + drei Commander-Entscheide (28.08.2026)
WAS: KONZEPT-V2.md neu — Systemarchitektur, Daten-/Queue-Strategie, die
drei Betriebsmodi, API-/Event-Design, Migrationsplan V2-0 bis V2-7.
KONZEPT.md §10 und ROADMAP.md ziehen nach.

WARUM: Rippy soll drei Betriebsarten bekommen statt einer — Docker,
native Windows-App ohne Docker, Headless-Linux-Dienst; alle mit
demselben Webinterface. Das traegt technisch nur, wenn es EINEN Kern
gibt, dessen Betriebsmodus nur die Auswahl der Treiber hinter vier
Ports ist (Store, Queue, Bus, Drives).

Drei Entscheide des Commanders sind eingearbeitet:

- Reihenfolge: Echtzeit (SSE statt Polling) VOR der Windows-App. Die
  Windows-App braucht SQLite und die lokale Queue ohnehin.
- Disc-Schluessel: automatischer Abruf MIT Rueckfallebene, als Kette in
  drei Stufen (eigener Bestand -> Abruf -> Import von Hand). Das
  verschiebt die Grenze aus KONZEPT.md §10 vom 25.07.2026 bewusst —
  deshalb steht sie dort jetzt ausdruecklich fortgeschrieben statt
  still ersetzt (AGENTS Regel B). Bezugsadresse leer vorbelegt,
  Fehlschlag laut, Bestand wird nie still ueberschrieben.
- Speicherziele: der Host mountet, Rippy prueft und erzeugt die
  kopierbare Zeile. Raeumt die URSACHE der CIFS-Ausfaelle ab (Befund
  26.07.2026: die Verbindung lebt in der Netz-Namespace des
  api-Containers und stirbt mit ihm) statt weiter das Symptom zu
  heilen. SYS_ADMIN, DAC_READ_SEARCH, apparmor:unconfined und die
  Mount-Wache fallen damit weg.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-28 08:38:03 +02:00
Hitonabi a14449ef85 fix(worker-ui): fix syntax error in gui.py and ruff error in test_verwaltung.py
Ampel / ampel (push) Successful in 39s
2026-07-27 17:17:30 +02:00
Hitonabi 4343b0901d feat(worker-ui): adjust thumbnails, log view, and button logic to match web dashboard
Ampel / ampel (push) Failing after 40s
2026-07-27 17:16:00 +02:00
Hitonabi c3e77399ad fix(worker): mock ntpath.dirname in test_erreichbarkeit so it passes on Linux CI runner
Ampel / ampel (push) Failing after 39s
2026-07-27 17:13:45 +02:00
Hitonabi 75426224d1 fix(worker): ensure sys.path in test_verwaltung for pytest importlib mode
Ampel / ampel (push) Failing after 39s
2026-07-27 17:11:11 +02:00
Hitonabi e5ff5373bb fix(worker): restore pure logic module verwaltung.py and its tests (SoC)
Ampel / ampel (push) Failing after 39s
2026-07-27 17:06:38 +02:00
Hitonabi 9b30c0a490 chore: remove obsolete test_verwaltung.py
Ampel / ampel (push) Failing after 40s
2026-07-27 17:02:37 +02:00
Hitonabi 061f79ecda fix: ruff linter errors (multiple statements, bare except, unused vars)
Ampel / ampel (push) Failing after 38s
2026-07-27 17:00:52 +02:00
Hitonabi a32a1bb075 fix: bare except in main.py
Ampel / ampel (push) Failing after 38s
2026-07-27 16:56:36 +02:00
Hitonabi 32979d7bde docs: SAVEPOINT update fuer Etappe 25 (Windows Worker in Flet)
Ampel / ampel (push) Failing after 40s
2026-07-27 16:53:59 +02:00
Hitonabi d15f4b2ab6 feat: Thumbnails, bunte Logs und Button-Status im Worker UI 2026-07-27 16:17:30 +02:00
Hitonabi a221a161f4 feat: Tray-Icon fuer Worker GUI (pystray) — Fenster schliessen minimiert ins Tray 2026-07-26 22:33:54 +02:00
Hitonabi 264b2c77f0 chore: finale exe mit venv --clear fix neu gebaut 2026-07-26 22:32:12 +02:00
Hitonabi 16ea54e35d fix: venv --clear bei Reinstall, verhindert veraltete Paketversionen 2026-07-26 22:30:12 +02:00
Hitonabi 81ba6bd1c6 fix: don't override pinned flet==0.23.2 with unpinned pip install 2026-07-26 22:24:20 +02:00
Hitonabi 06c1718a52 fix: installer buttons (Durchsuchen/Freigabe holen), Worker-Start via os.startfile, Shortcut via PowerShell 2026-07-26 22:15:50 +02:00
Hitonabi de500f9890 feat: complete rewrite of worker installer in Flet (standalone exe) 2026-07-26 22:07:24 +02:00
Hitonabi 9a151f3d8b feat: Worker V2 Flet GUI mit Feature-Parität und neuem Installer 2026-07-26 22:01:27 +02:00
Hitonabi e165e2a0d3 feat: Komplettierung der aktuellen Rippy-Etappe
Ampel / ampel (push) Failing after 29s
- Versionsanzeige für den Windows-Worker im UI inkl. Prüfung
- Absicherung der install.sh gegen fehlendes systemd
- Serien-Episoden-Erkennung und Laufzeitabgleich anhand TMDB-Daten (Heuristik)
- Umstellung der Windows-Worker-Installation auf SchTasks (Dienst-Ersatz)
- Kodi-Bibliotheks-Refresh über JSON-RPC integriert
2026-07-26 21:13:27 +02:00
Hitonabi d15900d1eb fix(audio): nur die beste Tonspur pro Sprache verlustfrei kopieren
Ampel / ampel (push) Failing after 29s
2026-07-26 20:55:57 +02:00
HitonabiandClaude Opus 5 4cb1fab416 docs(savepoint): die Kette ist zum ersten Mal ganz durchgelaufen
Ampel / ampel (push) Failing after 30s
40,9 GB Rip -> Auswurf -> Kompression auf dem Windows-PC -> 12,29 GB abgelegt,
Roh-Verzeichnis danach automatisch aufgeraeumt. Die Sprachwahl am ERGEBNIS
nachgeprueft (HandBrakeCLI --scan auf die abgelegte Datei): nur noch deutsche
Ton- und Untertitelspuren, kein Japanisch, keine unbenannten - vorher meldete
der Disc-Scan deu 4x, jpn 2x, und 4x.

Ein Fund aus dem Ergebnis, bewusst NICHT still repariert: Der Ton ist fuenfmal
MP3 2.0 mit 160 kbps. Das Preset "HQ 1080p30 Surround" schreibt laut
--preset-export zwei Regeln vor (av_aac stereo 160 / Surround 640); angewandt
wurde nur die erste, auf jede behaltene Spur. Der Surround-Ton eines Presets
namens "Surround" faellt damit still weg. Warum der Encoder MP3 statt av_aac
wurde, ist ungeklaert - Rippy uebergibt keinen Audio-Schalter. Als offener
Punkt notiert statt geraten; die Preset-Wahl ist eine Entscheidung des
Commanders.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 18:52:12 +02:00
HitonabiandClaude Opus 5 4915bba0b3 docs(savepoint): der volle Durchlauf - vier Belege und ein gefundener Fehler
Ampel / ampel (push) Failing after 30s
Belegt: Auswurf im automatischen Weg (bisher nur der UI-Knopf), Phasen-Marke
springt bei der Uebergabe auf true, Sprachwahl kommt beim externen Encoder an
("Ton: deu, Untertitel: deu"), Mount-Wache heilt in 4,2 s.

Gefunden: Jeder erste Film in einer neuen Ablage war unerreichbar - die Pruefung
liess nur eine fehlende Ordner-Ebene durch, obwohl makedirs die ganze Kette
anlegt. Der Fehler wartete seit v3.17 darauf, dass jemand eine frische Ablage
benutzt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 17:47:27 +02:00
HitonabiandClaude Opus 5 96c400f2f2 fix(worker): erster Film in einer neuen Ablage war immer unerreichbar
Ampel / ampel (push) Failing after 30s
Im ersten vollstaendigen Durchlauf aufgefallen: Der Rip lief sauber durch (40 GB
Akira, Marke rip_fertig sprang korrekt auf true), die Kompression brach 0,2 s
spaeter ab mit "Dieser Worker erreicht die Ziel (fertige Datei) nicht:
\\192.168.178.62\rippy\movies\Akira (1988)".

Die Freigabe war erreichbar. Es fehlten zwei noch nie angelegte Ordner - movies
und der Filmordner darin. Die Pruefung liess aber nur EINE fehlende Ebene durch
(sie sah nach dirname), obwohl gleich darauf os.makedirs die ganze Kette anlegt.
Damit war jeder ERSTE Film in einer neuen Ablage systematisch unerreichbar.
Jetzt zaehlt, ob irgendein Vorfahre existiert (erster_vorhandener_ordner,
begrenzt auf 12 Stufen, damit auf einer toten Freigabe nicht endlos geklopft
wird).

Zweiter Fehler in derselben Meldung: Sie behauptete "RIPPY_PATH_MAP ist gesetzt,
deckt diesen Pfad aber nicht ab" - und nannte im selben Satz den korrekt
uebersetzten UNC-Pfad. Wer dem folgte, suchte in der Karte statt in der
Freigabe. Die Karte wird nur noch beschuldigt, wenn sie den Pfad wirklich nicht
angefasst hat; sonst steht da, was zutrifft: uebersetzt, aber gerade nicht
erreichbar. Dazu der Artikel-Fehler "erreicht die Ziel" behoben.

Diese Pruefung hatte KEINEN einzigen Test - deshalb kam beides durch. Jetzt 12
(301 gruen). Beim Schreiben ist noch ein dritter Fehler aufgefallen:
`isdir=os.path.isdir` als Vorgabewert bindet die Funktion beim IMPORT, ein
Ersetzen geht danach ins Leere. Aufloesung jetzt beim Aufruf.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 17:43:51 +02:00
HitonabiandClaude Opus 5 936b0837bf docs(savepoint): Uhrzeit-Meldung erledigt - mit dem Beweis, der zaehlt
Ampel / ampel (push) Successful in 32s
Die "Substantial drift 7200 seconds"-Meldung kam nicht alle paar Sekunden,
sondern einmal pro Absender-Hostname (celery memoized nach hostname) - und der
Container-Hostname wechselt bei jedem Neubau. Die vier Meldungen im Log sind
genau vier Deploys.

Der Beweis, dass sie weg ist: Um 14:57:33 synchronisierte sich der Worker mit
celery@d160eb2f3afd, dem frischen Container nach dem Deploy. Ein NEUER Hostname
umgeht die Merk-Sperre, die Warnung haette also feuern muessen. Sie kam nicht.
Dazu gemessen: TZ=UTC wirkt auf Windows wirklich (time.timezone -3600 -> 0), und
die celery-Zeitstempel im lokalen Worker-Log stehen in UTC.

Ausserdem festgehalten: Der Windows-Worker laeuft auf gemischten Dateistaenden
(tasks.py 13:19, ripping.py 14:06, zombies.py 14:17) - die Sprachwahl ist
vollstaendig drin, meta_merken fehlt noch. Es fehlt eine Versionsanzeige, die
so etwas sichtbar macht, statt es nur beim Nachsehen auf dem PC zu finden.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 17:23:14 +02:00
HitonabiandClaude Opus 5 a9cfcb272a docs(konzept): Rate-Limit 100/min -> 600/min als Abweichung vermerkt
Ampel / ampel (push) Successful in 32s
Regel B: keine stille Aenderung an einer KONZEPT-Vorgabe. Das Muss-Feature
"Rate-Limiting pro Client-IP" bleibt, nur die Zahl aendert sich - mit der
Rechnung, die zeigt warum: 100/min lag unter Rippys eigener Last (ein offener
Tab braucht 111/min, ein Windows-Worker 12 dazu). Festgehalten durch
test_grenze_deckt_die_eigene_last_ab, damit die Zahl nicht unbemerkt zurueck
unter die Grundlast wandert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 17:09:23 +02:00
HitonabiandClaude Opus 5 163216a68e docs(savepoint): v3.20 - die Bremse war das Problem, nicht die Last
Ampel / ampel (push) Successful in 31s
SAVEPOINT v3.20 mit den Messwerten: /jobs und /capabilities byteweise identisch
ueber zwanzig Sekunden (es lud also nichts neu), 97 Antworten mit HTTP 429 im
nginx-Log, 812 von 876 Anfragen scheinbar von einer IP, und die Rechnung, die
zeigt warum: ein offener Tab braucht 123 Anfragen/min, erlaubt waren 100.

Dazu drei neue Lehren in AGENTS.md:
- Ein verpasster Abruf ist keine Nachricht ueber die Welt (`catch(() => [])`).
- Eine eigene Schutzbremse gegen die eigene Last rechnen - und jedes Greifen
  protokollieren, sonst ist sie unsichtbar.
- Eine geschluckte Warnung ist eine Falle (`|| echo` in einem 200-Zeilen-Log).
- Und: wenn der Commander eine Korrelation nennt, ist das eine Spur, auch wenn
  seine vermutete Erklaerung daneben liegt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 17:06:56 +02:00
HitonabiandClaude Opus 5 9156e8a4a9 fix(deploy): leere Argumente und eine fehlende .env brachen das Deploy - still
Ampel / ampel (push) Successful in 30s
Zwei Funde beim Deployen, beide fuer die Weitergabe relevant:

1. `./deploy.sh` ohne Argumente - der dokumentierte Normalfall - endete mit
   "line 5: $4: unbound variable". Leere Argumente ueberleben den Weg durch ssh
   nicht: Die Gegenseite bekommt die Befehlszeile als EINEN String und parst sie
   neu, wobei "" ersatzlos verschwindet. ${4:-} statt "$4".

2. Fehlte die .env-Quelle, war das eine geschluckte Warnung. Auf der Ziel-VM lag
   die echte .env unter ~/projects/rippy/.env, der Default zeigte auf
   ~/rippy/.env. Das `cp` schlug also jedes Mal fehl, die Warnung scrollte im
   Build-Rauschen vorbei, und gebaut wurde mit der Kopie im Klon: zwei Tage alt,
   darin ein MAKEMKV_URL_BASE-Notbehelf auf einen web.archive.org-Schnappschuss
   (liefert inzwischen 525, waehrend makemkv.com wieder 200 gibt) und ein
   JWT_SECRET_KEY aus der Zeit vor dem Auth-Rueckbau. Jeder worker-Build brach
   daran ab, und die Ursache stand nirgends.

Jetzt: .env uebernommen -> es steht da. Quelle fehlt, Klon hat eine -> laute
Warnung samt Dateidatum und Kandidatenliste. Keine von beiden -> Abbruch, statt
mit leerem DB-Passwort zu bauen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 16:57:12 +02:00
HitonabiandClaude Opus 5 bfb13f44a5 fix(ui+api): das "Neuladen" war HTTP 429 - und "Neu" komprimierte immer
Ampel / ampel (push) Successful in 30s
Zwei Commander-Befunde, beide mit derselben Wurzel: Rippy hat sich selbst
ausgebremst und dann geschwiegen.

## "Wenn der Worker installiert ist, wird dieser Bereich oft neu geladen"

Gemessen statt geraten. Die Antworten von /jobs und /capabilities waren ueber
zwanzig Sekunden byteweise identisch, alle Endpunkte antworteten unter 30 ms -
es wurde also gar nichts neu geladen. Im nginx-Log standen dagegen 97 Antworten
mit HTTP 429.

Drei Fehler griffen ineinander:

1. Das Limit war zu klein fuer Rippy selbst: 100 Anfragen/min, waehrend ein
   offener Tab 111/min verursacht (Dashboard 75 + Log-Kasten 24 + Laufwerke 12)
   und der Windows-Tray weitere 12/min dazulegt.
2. Der nginx gab die Client-Adresse nicht weiter. Fuer die API kam damit ALLES
   von 172.19.0.6 - Browser, zweiter Tab und Tray teilten sich einen Eimer
   (812 von 876 Anfragen). Das erklaert die Kopplung an den Worker: tray.py
   fragt /api/jobs ueber Port 80, also durch denselben Proxy.
3. Ein abgewiesener Abruf leerte das UI. `catch(() => [])` heisst "es gibt
   keine Jobs" - richtig waere "ich weiss gerade nichts Neues". Fuer einen Takt
   stand "Keine Jobs", die Zaehler sprangen auf (0), vier Sekunden spaeter war
   alles zurueck.

Behoben: X-Real-IP im nginx, Grenze auf 600/min mit vorgerechneter Herleitung,
jeder Fehlschlag laesst den alten Stand stehen (null statt []), axios bekommt
eine Zeitgrenze, und das Dashboard trennt schnelle Daten (Jobs/Laufwerke, 4 s)
von langsamen (Hardware/Worker/Ablagen, 12 s) - 75/min werden zu 30/min.
Ein greifendes Limit steht ab jetzt im Log, gedrosselt auf eine Meldung pro
Client und Minute.

## "Hier gibt es den Button 'neu' aber WAS wird dann gemacht?"

Immer die Komprimierung - auch bei einem Job, dessen RIP abgebrochen war. Am
26.07.2026 waeren aus 5,1 GB Bruchstueck (von rund 40 GB) brav ein Film
geworden, der bei 12 % aufhoert.

Die Phase war nach `status = "failed"` nicht mehr feststellbar, also wird sie
jetzt vermerkt (rip_fertig in den Job-Metadaten: false beim Rip-Start, true bei
der Uebergabe an die Kompression). Daraus folgt die Beschriftung: "Neu
komprimieren", "Neu rippen" - oder bei Bestandsjobs ohne Vermerk ein Dialog,
der beide Wege erklaert und die Groesse der Rohdaten als Entscheidungshilfe
nennt. Geraten wird nicht. Fuer den Rip-Fall gibt es POST
/jobs/{id}/retry-rip: neuer Job mit neuer ID (sonst laege das Bruchstueck im
Roh-Verzeichnis des neuen Rips), Titel/Ablage/Sprachwahl uebernommen, mit
ehrlicher Absage wenn keine Disc im Laufwerk liegt.

10 neue Tests (289 gruen), darunter eine Kopplungspruefung: der Name der
Phasen-Marke muss in worker/tasks.py und api/phasen.py zusammenpassen - genau
diese Sorte Auseinanderdriften hat die Zombie-Erkennung ein Release lang blind
gemacht.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 16:49:10 +02:00
HitonabiandClaude Opus 5 f7555a17d1 fix(zombies): die Fehlermeldung unterscheidet jetzt Rip von Kompression
Ampel / ampel (push) Successful in 29s
Nachtrag, direkt am echten Fall aufgefallen. Die Zombie-Erkennung hat den toten
Rip gefunden (Beleg: nach 140 s noch "processing 12 %", nach 160 s "failed") -
aber der Fehlertext sagte:

  "Die Rohdateien wurden NICHT geloescht: mit 'Neu komprimieren' laeuft die
   Kompression erneut, ohne die Disc noch einmal zu rippen."

Der Satz war fuer einen toten TRANSCODE geschrieben, wo die Roh-MKV vollstaendig
ist. Seit "running" mit zu den Arbeitsstati gehoert, traf er auch abgebrochene
RIPS - und da ist er schlicht falsch: Die Datei ist ein Bruchstueck (im Vorfall
5,1 GB von rund 40), und wer dem Rat folgt, komprimiert einen Film, der bei 12 %
aufhoert.

Jetzt unterscheidet der Text die Phase:
  Rip tot        -> "Der Rip war bei 12 % - die Roh-Datei ist UNVOLLSTAENDIG ...
                     Richtig ist: Disc wieder einlegen und neu rippen."
  Transcode tot  -> "Der Rip war fertig, nur die Kompression nicht ..."

Die deutschen Anfuehrungszeichen haben dabei zum vierten Mal an einem Tag
zugeschlagen (in DOPPELT gequoteten Python-Strings beendet das schliessende
Zeichen den String). Die betroffenen Zeilen sind jetzt einfach gequotet, wie es
der Bestand ohnehin macht.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 16:23:15 +02:00
HitonabiandClaude Opus 5 19f3dc5330 fix(zombies): "running" fehlte - ein abgestuerzter RIP wurde NIE gefunden
Ampel / ampel (push) Successful in 30s
Der Commander: "Ausserdem ist gerade mitten im Rip das Laufwerk ausgegangen...
glaube ich zumindest." Gemessen war es etwas anderes, und der Fund ist groesser
als der Vorfall.

WAS MESSBAR WAR:
  Job 2182d525   status=running progress=12   (Rip gestartet 14:00:24)
  makemkvcon     laeuft NICHT (per /proc geprueft, PID gegengeprueft)
  Rohdatei       5.167.382.528 Bytes, waechst in 10 s nicht
  Laufwerk       Status 4 (Disc drin), /dev/sr0 + /dev/sg1 da
  Worker-Start   14:07:02  <- mein `docker compose up -d --build`

Das Laufwerk ist also NICHT ausgegangen. Der Rip wurde von MEINEM Deploy
getoetet: `up -d --build` baut den worker-Container neu, und der laufende Rip
stirbt mit ihm. Genau davor warnt der SAVEPOINT seit v3.18 - die Warnung half
nichts, weil sie niemand liest und nichts sie prueft.

DER EIGENTLICHE FUND: Die Zombie-Erkennung lief um 14:09:04 und meldete
`{'geprueft': 0, 'aufgeraeumt': []}` - obwohl der tote Job direkt vor ihr lag.
Ursache:

  ARBEITS_STATI = ("ripping", "transcoding", "canceling")   # zombies.py
  db.update_job(job_id, status="running", ...)              # tasks.py - der Rip

Der Rip setzt "running", gesucht wurde "ripping". Dieser Wert steht
ausschliesslich in Celerys Task-META und NIE in einer Job-Zeile (nachgeprueft:
kein einziger Schreiber im ganzen Baum). Die Zombie-Erkennung aus v3.14 wurde
gebaut, um genau einen abgestuerzten Rip zu finden - und hat ihn nie gesehen.

Besonders tueckisch: `geprueft: 0` sah bei jedem Worker-Start wie "nachgesehen,
alles gesund" aus, waehrend sie nach einem Status suchte, den es nicht gibt.
Deshalb blieb der Job auf "processing 12 %" stehen - mit einer Restzeit-Schaetzung
von 1 h 30 min obendrauf, die es fuer einen toten Prozess nicht geben duerfte.

GEBAUT:
  * "running" in ARBEITS_STATI.
  * Ein Test, der das Auseinanderlaufen MECHANISCH verhindert: Er liest tasks.py,
    sammelt jeden Status, den der Worker per db.update_job in eine Job-Zeile
    schreibt, und verlangt, dass jeder davon entweder ein Arbeitsstatus oder ein
    Endzustand ist. Ein Kommentar haette das nicht verhindert.
  * GET /health/arbeit + eine Sperre in deploy.sh: Laeuft ein Job, bricht der
    Deploy ab (uebersteuerbar mit RIPPY_TROTZDEM=1 - dann ist es eine
    Entscheidung und kein Versehen). Ein Satz Code gegen eine verlorene Stunde.
  * Server-Status zeigt jetzt die eingehaengten FREIGABEN mit freiem Platz, nicht
    nur die Container-Platte (Commander-Wunsch). Genau dort liegen die Rohdaten,
    und bei externem Encoden muessen sie dort liegen - wer wissen wollte, ob noch
    Platz fuer eine Disc ist, sah die falsche Zahl.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 16:16:05 +02:00
HitonabiandClaude Opus 5 6438beec05 fix(worker): kein CMD-Blitzen mehr - und die 7200-Sekunden-Meldung ist erklaert
Ampel / ampel (push) Successful in 31s
Zwei Meldungen, beide auf dieselbe Wurzel zurueckgefuehrt: Der Worker startet
Konsolenprogramme, und das hat unter Windows Nebenwirkungen.

1. "Es geht immer alle paar Sekunden ne CMD auf." Kein Geist, sondern der
   HERZSCHLAG. Der Worker laeuft als pythonw.exe, also ohne eigene Konsole. Wer
   ohne Konsole ein Konsolenprogramm startet, bekommt von Windows eine NEUE - und
   die ist sichtbar. `capture_output=True` hilft nicht: es leitet die Datenstroeme
   um, unterdrueckt aber kein Fenster. Und caps.py fragt jede Minute
   `HandBrakeCLI --help`, `--preset-list` und `--version` ab, dazu makemkvcon aus
   der Schluessel-Automatik: vier bis fuenf Fenster pro Minute, in Schueben.

   Neues winlauf.py haelt CREATE_NO_WINDOW an EINER Stelle; alle elf Aufrufe in
   caps.py, ripping.py und schluessel.py benutzen es. Auf Linux ist der Wert 0 und
   creationflags=0 eine Nulloperation - im Worker-Container gegengeprueft, damit
   derselbe Code auf beiden Seiten laeuft.

2. Die 7200 Sekunden sind CELERYS EIGENE UMRECHNUNG, nicht die Uhren. Erst fiel
   auf, dass die Sekundenbruchteile nur 40 ms auseinanderliegen (.177269 vs
   .134799) - derselbe Augenblick, zweimal verschieden gerechnet. Die Quelle sagt
   warum (celery/utils/time.py):

     def utcoffset():                    # Sekunden WEST von UTC, in Stunden
         return time.altzone // 3600     # CEST -> -2 ;  UTC -> 0
     def adjust_timestamp(ts, offset, here=utcoffset):
         return ts - (offset - here()) * 3600

   Absender VM (offset 0), Empfaenger Windows-PC (here() = -2):
   ts - (0 - (-2)) * 3600 = ts - 7200. Celery verschiebt den empfangenen Stempel
   also selbst und vergleicht ihn dann mit der eigenen Uhr. Die Annahme dahinter -
   Ereignisse truegen Ortszeit - stimmt nicht, `Event()` stempelt Epoch.

   Abhilfe gemessen, nicht geraten: Mit TZ=UTC meldet Windows utcoffset 0
   (timezone=0, isdst=0 - auf dem Commander-PC geprueft), damit wird die
   Umrechnung zur Nulloperation. Beide .bat-Dateien setzen es jetzt. Nebeneffekt
   ist erwuenscht: Der Worker rechnet dann in derselben Zone wie die VM und wie
   Rippys UI.

   Fuer Rippy war die Meldung ohnehin folgenlos - /capabilities fragt per
   Celery-Ping (Frage/Antwort, ohne Zeitstempel), nicht ueber die
   Gossip-Ereignisse. Aber eine Warnung, die bei jedem Blick ins Log steht und
   nichts bedeutet, kostet Vertrauen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 16:05:54 +02:00
HitonabiandClaude Opus 5 5f01aa89fc fix(deinstaller): er brauchte Adminrechte und hatte keine
Ampel / ampel (push) Successful in 30s
Commander: "Ich kann den worker uebrigens immernoch nicht deinstallieren."

Der Screenshot zeigt ZWEI Dinge. Das erste ist erklaerbar: Es lief noch der ALTE
uninstall.ps1 von der letzten Installation - Zeile 2 mit dem kaputten
`if (-not $Force) { if ([System.Windows.Forms.MessageBox]...` . Meine Reparatur
schreibt die Datei erst beim naechsten Installer-Lauf neu.

Das zweite ist MEIN Fehler, und er haette auch die neue Fassung erwischt:

  Remove-Item : Das Element C:\Program Files\Rippy Worker\doc\LICENSE
  kann nicht entfernt werden: Der Zugriff auf den Pfad wurde verweigert.

Der Standard-Zielordner liegt unter "C:\Program Files", und der gehoert nicht dem
Benutzer. Die Installer-.exe ist mit -requireAdmin gebaut und fragt beim Start per
UAC - der Deinstaller hatte nichts Vergleichbares. Er war damit im STANDARDFALL
nutzlos, und mein `rd /s /q` waere genauso aufgelaufen.

Jetzt erhoeht er sich selbst: Schreibprobe im Ordner, Admin-Abfrage, und nur wenn
beides fehlt, ein Neustart per RunAs mit -Force (damit die Bestaetigung nicht
zweimal kommt). GEMESSEN statt angenommen - wer den Worker ins eigene Profil
installiert hat, bekommt gar keine UAC-Frage. An seinem echten Ordner
gegengeprueft: schreibbar=False, istAdmin=False -> Entscheidung "erhoehen".

Der erzeugte Deinstaller ist diesmal komplett nachgestellt worden: parst, und die
Reihenfolge stimmt (Add-Type Zeile 7, MessageBox Zeile 10, Schreibprobe,
Erhoehung, erst dann Loeschen).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 15:55:05 +02:00
HitonabiandClaude Opus 5 f146f33f5d feat(installer): Verknuepfung auf dem Desktop - mit Rippy-Icon
Ampel / ampel (push) Successful in 30s
Commander: "Und wenn man den worker installiert braucht man auch eine exe auf dem
Desktop abgelegt wird zum starten you know?"

Berechtigt: Die Startdateien lagen nur im Programmordner. Wer den Worker von Hand
starten wollte, musste erst "C:\Program Files\Rippy Worker" suchen - und genau
das war heute noetig, als der Worker stand.

Jetzt legen beide Installer eine Verknuepfung "Rippy Worker" auf den Desktop
(GUI mit Haekchen, Kommandozeile per -KeineDesktopVerknuepfung abschaltbar). Drei
Details, die den Unterschied machen:

  * Das ICON wird mit ausgeliefert. rippy.ico lag im Repo, ging aber nie an die
    Zielmaschine - die Verknuepfung haette das Batch-Standardsymbol getragen und
    waere zwischen den anderen Icons unfindbar gewesen. Jetzt im Worker-Paket.
  * WindowStyle 7 (minimiert): start-tray.bat startet pythonw, also ohne
    Konsolenfenster - aber die .bat selbst blitzt sonst kurz auf. Gilt jetzt auch
    fuer die Autostart-Verknuepfung, wo derselbe Blitz war.
  * Der DEINSTALLER nimmt sie mit, an beiden moeglichen Orten (eigener Desktop
    und Desktop aller Benutzer). "Rueckstandsfrei entfernbar" ist ein
    MUSS-Kriterium; ein totes Symbol auf dem Desktop waere genau so ein Rueckstand.

Dieselbe Rechte-Ueberlegung wie beim Autostart: bei einer Installation unter
"Programme" auf den Desktop ALLER Benutzer, sonst auf den eigenen - bei einer
UAC-Erhoehung ueber ein fremdes Admin-Konto waere der eigene der falsche.

Layout headless gerendert und angesehen (Fenster 648 -> 672 px, nichts
ueberlappt), beide .ps1 mit echtem PowerShell 5.1 geprueft, .exe neu gebaut.
Und die CRLF-Falle aus dem Savepoint hat prompt wieder zugeschlagen: Mein
Python-Rewrite machte aus install-gui.ps1 LF - zurueckgedreht, `file` bestaetigt
BOM und CRLF fuer beide.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 15:46:15 +02:00
HitonabiandClaude Opus 5 a448ebc4de fix(ui): die Pfad-Warnung sagt jetzt, was zu tun ist - und bietet einen Knopf
Ampel / ampel (push) Successful in 29s
Commander: "Das ist ja quatsch. Mein PC hat das Ziel als Worker direkt auf dem
PC eingebunden."

Nachgemessen: Die Warnung hatte SACHLICH recht, war aber unbrauchbar. Sein PC hat
die Freigabe wirklich als Netzlaufwerk (X:) gemountet - nur lag das
ARBEITSVERZEICHNIS darauf und die ABLAGE nicht. Das Ziel war weiter
/app/media/movies, also die VM-Platte, und dorthin kommt sein PC nicht. Beleg aus
der Worker-Meldung:

  pfad_map = /app/media/rippy=\192.168.178.62\rippy
  Ziel     = /app/media/movies        <- nicht abgedeckt, richtig gewarnt

Die alte Meldung nannte den Container-Pfad und die Mapping-Zeichenkette - also
genau die zwei Dinge, die ein Nicht-Entwickler nicht deuten kann. Jetzt steht der
Handgriff drin, mit dem NAMEN der Freigabe, die dieser Worker wirklich erreicht
("Einstellungen -> Ripping -> Ablage auf 'rippy' stellen").

Dazu ein Knopf, der das Ziel NUR FUER DIESEN RIP auf die Freigabe legt
(/app/media/movies -> /app/media/rippy/movies), ohne die globale Ablage
anzufassen. Wer den Rip jetzt starten will, will jetzt eine Loesung und keine
Wegbeschreibung.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 15:38:31 +02:00
HitonabiandClaude Opus 5 b4a0dd551a docs(savepoint): v3.19 - sieben Meldungen, drei echte Fehler, eine Kette
Ampel / ampel (push) Successful in 30s
Der Savepoint haelt fest, was gemessen wurde und was nicht. Die wichtigste Lehre
steht auch in AGENTS.md: Bei "zu langsam" die DAUER je Schritt messbar machen
statt die plausibelste Ursache zu beheben. Meine erste Erklaerung fuer die 150 s
war falsch und machte es sogar langsamer (202 s); erst Zeitstempel im Log zeigten
die Stelle - ein os.makedirs, das drei Minuten im Kernel hing. Danach 8 s.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 15:25:46 +02:00
HitonabiandClaude Opus 5 848deb1c24 fix(ui): Sprachnamen auf Deutsch - "Undetermined" versteht niemand
Ampel / ampel (push) Successful in 29s
An der echten Akira-Blu-ray gemessen, nachdem die Sprachauswahl live lief:

  Ton:        deu 4x, jpn 2x, und 4x
  Untertitel: deu 4x, und 8x

MakeMKV liefert die Namen englisch ("German", "Japanese") und fuer Spuren ohne
Sprach-Kennzeichnung "Undetermined" - das sind typischerweise Audiokommentare.
Der Commander liest alles auf Deutsch (AGENTS Grundregel 4), und
"Undetermined" ist fuer einen Nicht-Entwickler schlicht keine Auskunft. Jetzt
steht dort "Ohne Sprachangabe", und die zwei Dutzend haeufigsten Codes haben
deutsche Namen. Unbekannte Codes behalten MakeMKVs Namen - geraten wird nichts.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 15:22:13 +02:00
HitonabiandClaude Opus 5 9230d0dd7a fix(weitergabe): drei Luecken geschlossen, die einen Fremden gestolpert haetten
Ampel / ampel (push) Successful in 29s
Weitergabe nicht durch Lesen geprueft, sondern indem ich mich wie ein fremder
Rechner verhalten habe: frischer `git clone` von Gitea in ein leeres Verzeichnis,
dann `./install.sh --nur-pruefen`. Ergebnis: 2,6 MB, alles gruen, Laufwerk samt
richtigem sg-Knoten ueber die SCSI-Adresse erkannt. Der Weg selbst traegt.

Drei Luecken sind dabei aufgefallen:

1. IN BEISPIELBEFEHLEN STAND MEINE IP. `install.ps1` und
   `remote-transcode-worker.yml` nannten im Aufruf-Beispiel 192.168.178.162 -
   also genau die Zeile, die ein Fremder kopiert. Jetzt Platzhalter, beim
   Windows-Installer mit dem Hinweis, wo die richtige IP steht (und dass es NICHT
   die des eigenen PCs ist - der haeufigste Irrtum).

2. DER ASSISTENT FRAGTE DEN MAKEMKV-BETA-KEY NICHT. Er stand in der README, in
   der .env und in den Einstellungen - nur nicht dort, wo man beim Einrichten
   hinsieht. Ein Fremder installiert also, legt eine Blu-ray ein und bekommt
   spaeter einen Fehlschlag, ohne dass ihn jemand darauf hingewiesen haette. Das
   ist die wahrscheinlichste Stolperstelle einer frischen Installation. Jetzt
   fragt der Assistent ihn ab, mit dem Unterschied im Klartext: DVDs gehen ohne,
   Blu-ray braucht ihn - und er ist NICHT der Disc-Schluessel einer 4K-Disc.

3. Eine Docstring nannte meine NAS-IP als Beispiel - jetzt neutral (//NAS/rippy).

Tests und Log-Beispiele behalten die echten Namen: Sie dokumentieren Messungen,
und genau das ist ihr Wert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 15:18:30 +02:00
HitonabiandClaude Opus 5 c171f8879c feat(schluessel): der Windows-PC holt die 4K-Schluessel jetzt selbst
Ampel / ampel (push) Successful in 31s
Auf Commander-Entscheid gebaut. Belegt am 25.07.2026 auf beiden Maschinen:
`makemkvcon` unter LINUX ruft Disc-Schluessel NIE ab, die WINDOWS-Version schon
(Meldung 3338). Deshalb scheiterte jede unbekannte UHD-Disc auf der VM mit "The
volume key is unknown", und der Weg, der funktioniert, war Handarbeit: Laufwerk
an den PC, Disc oeffnen, _private_data.tar suchen, im UI hochladen.

Das laeuft jetzt von selbst - und zwar ZWEISCHICHTIG, mit Absicht:

  1. Der WAECHTER (verlaesslich): sieht _private_data.tar nach und laedt sie zu
     Rippy hoch, sobald sie sich geaendert hat. Braucht keine
     Laufwerkserkennung, kein Disc-Oeffnen, nichts geraten. Deckt auch den Fall
     ab, dass man die Disc einfach in der MakeMKV-Oberflaeche oeffnet.
  2. Das ANSTOSSEN (nach bestem Wissen): liegt eine Disc im Laufwerk, wird
     `makemkvcon info` darauf losgelassen - dabei holt MakeMKV den Schluessel.

Warum getrennt: Das Format der BELEGTEN `DRV:`-Zeile liess sich auf dem
Commander-PC nicht messen, weil dort kein optisches Laufwerk steckt (alle 16
Plaetze melden `DRV:i,256,999,0,"","",""` - das ist gemessen). Geraten wird also
nur in Schicht 2, und wenn die Vermutung falsch ist, passiert dort einfach
nichts - Schicht 1 arbeitet weiter. Die teure Annahme steckt nie im
verlaesslichen Teil.

Gemessene Fundstellen: Datenverzeichnis ist `%USERPROFILE%\.MakeMKV` (NICHT
%APPDATA%\MakeMKV, wie man vermuten wuerde) - dort lag die echte Datei mit
6.420.480 Bytes. Programm: C:\Program Files (x86)\MakeMKV\makemkvcon64.exe,
v1.18.4. Hochgeladen wird mit ROHEM Koerper an POST /system/keystore, weil der
API python-multipart fehlt.

Die Automatik schaltet sich selbst ab, wenn MakeMKV nicht installiert ist: Auf
einem reinen Encoding-PC gibt es nichts zu holen, und eine Schleife, die jede
Minute ins Leere greift, waere nur Rauschen. Ihre Meldungen gehen ueber die
Log-Bruecke auch nach Rippy - das ist genau die Auskunft, auf die man nach dem
Einlegen einer neuen UHD-Disc wartet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 15:14:52 +02:00
HitonabiandClaude Opus 5 148ac494c2 feat(sprachen): Rippy fragt vor dem Rip, welche Sprachen du willst
Ampel / ampel (push) Successful in 29s
Commander-Anforderung: "Die Disc hat Material in X Sprachen und X Untertiteln -
Rippy muss VOR dem Rip fragen: Was genau willst du haben? In der Automatik muss
das ebenfalls einstellbar sein."

Die Auskunft lag laengst vor und wurde weggeworfen: Derselbe Titel-Scan, der die
Titel-Tabelle fuellt, liefert in derselben makemkvcon-Ausgabe die Streams mit.
Ein zweiter Info-Lauf haette eine Minute Wartezeit gekostet - jetzt kommt beides
aus einem Aufruf.

Format an der Akira-Blu-ray im Laufwerk gemessen (AGENTS Regel D):

  SINFO:<titel>,<stream>,<attribut>,<code>,"<wert>"
  1 = Typ ("Audio"/"Subtitles"), 3 = Sprachcode, 4 = Sprachname,
  6 = Codec, 14 = Kanaele, 30 = Beschreibung

DIE FALLE dabei: Die Sprache steht in 3/4, NICHT in 28/29. Die tragen auf JEDEM
Stream "eng"/"English" - auch auf einer deutschen Tonspur und auf dem
Videostream; das ist MakeMKVs eigene Anzeigesprache. Wer 28 nimmt, haelt jede
Disc fuer englisch. Ein Test haelt das fest.

Angewendet wird die Wahl bei der KOMPRESSION, nicht beim Rippen - drei Gruende:
der Rip bleibt vollstaendig und verlustfrei (Muss-Feature laut KONZEPT); HandBrake
hat dafuer dokumentierte Schalter (--audio-lang-list / --subtitle-lang-list, die
genau die ISO-639-2-Codes nehmen, die MakeMKV liefert - beides gegengeprueft);
und wer spaeter andere Sprachen will, komprimiert neu statt die Disc wieder
einzulegen. Genau das sagt der Dialog auch, sonst glaubt man, es werde
unvollstaendig gerippt.

Nichts angeklickt heisst "alles behalten" - das Verhalten von vorher. Auch die
Einstellung ist bewusst LEER vorbelegt: Ein stilles "deu" wuerde bei einem
japanischen Original die Originaltonspur wegwerfen, ohne dass jemand gefragt hat.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 15:10:21 +02:00
HitonabiandClaude Opus 5 58f4991d92 fix(mounts): 3 min 15 s hingen in EINER Zeile - os.makedirs auf dem toten Mount
Ampel / ampel (push) Successful in 29s
Nachtrag, weil die letzte Runde die Wiederanbindung nicht schneller machte
(202 s statt 150 s). Die Zeitstempel im Log zeigten, wo die Zeit sitzt:

  12:53:56  API gestartet
  12:54:03  "antwortet nicht - wird neu verbunden"    <- Erkennung: 7 s, gut
  12:57:18  "eingehaengt"                             <- Reparatur: 3 min 15 s

Die Erkennung war also schon schnell; die REPARATUR fraess die Zeit. Und zwar
nicht in den Mount-Versuchen, sondern in der ersten Zeile von mounten():

  os.makedirs(ziel, exist_ok=True)

`exist_ok` prueft mit os.path.isdir, und ein `stat` auf einen toten CIFS-Mount
blockiert im Kernel bis zum SMB-Timeout. Ausgerechnet der Aufruf, der nur "lege
den Ordner an, falls er fehlt" bedeutet, hing drei Minuten - BEVOR irgendeine der
sorgfaeltig begrenzten Pruefungen dran war. Dritter Fund derselben Sorte an einem
Tag: os-Aufruf auf einen Netzpfad ohne Zeitgrenze.

Jetzt klaert `pfad_lage()` die Lage mit einem abbrechbaren Kind-Prozess
(`timeout 4 ls -d`, drei Antworten: da / weg / unklar), und makedirs laeuft nur
bei "weg". Dieselbe Falle in `reparieren()` (os.path.ismount als Vorbedingung -
gebraucht wird es nicht, `umount -l` auf einen leeren Pfad kostet nichts) und in
`aushaengen()` (ismount + rmdir).

Dazu steht die DAUER jetzt im Log ("neu verbunden (4.2s)"). Sie war die
entscheidende Spur; wer sie ablesen kann, muss sie nicht rekonstruieren.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 15:01:09 +02:00
HitonabiandClaude Opus 5 2a90538473 fix: Deinstaller, Verwaltungsfenster, Dashboard-Widerspruch, Mount-Tempo
Ampel / ampel (push) Successful in 30s
Vier Meldungen des Commanders, alle nachgemessen.

1. DEINSTALLER LIEF NICHT MEHR - reproduziert mit echtem PowerShell:

     Der Typ [System.Windows.Forms.MessageBox] wurde nicht gefunden.

   `Add-Type -AssemblyName System.Windows.Forms` stand EINE ZEILE ZU SPAET, die
   MessageBox wurde davor benutzt. Der Deinstaller starb also in seiner ersten
   Arbeitszeile, jedes Mal. Zwei weitere Maengel gleich mit:
   Kodierung war ASCII trotz Umlauten, und `Remove-Item -Recurse -Force
   $PSScriptRoot` loescht den Ordner, in dem das laufende Skript liegt - das
   klappt auf Windows nicht zuverlaessig (venv-DLLs sind geladen). Jetzt raeumt
   ein losgeloestes cmd nach, sobald PowerShell weg ist. Der erzeugte Deinstaller
   ist gegengeprueft: parst, BOM da, Umlaute intakt.

2. VERWALTUNGSFENSTER (Doppelklick aufs Tray). Zeigt Status, Aufgaben und Log,
   plus Knoepfe fuer Rippy, Log-in-Rippy und Deinstallieren - Deinstallieren geht
   damit auch aus dem Tray-Menue. Eigener PROZESS statt Fenster im Tray, weil
   pystray und tkinter beide den Haupt-Thread wollen; tkinter statt WinForms,
   weil es bei jeder Windows-Python-Installation dabei ist. Headless gerendert
   und angesehen. Alles Fachliche kommt von Rippy (/capabilities, /jobs), damit
   dort nicht eine zweite, abweichende Wahrheit steht.

3. DASHBOARD-WIDERSPRUCH. Oben stand "Akira im Laufwerk erkannt", die
   Server-Status-Karte gleichzeitig "Bereit - keine Disc in Arbeit / Disc
   einlegen". Zwei Aussagen, ein Blick. Die Karte fragt jetzt /devices und sagt
   "Disc erkannt - wartet auf Rippen starten" samt Titel.

4. MOUNT-TEMPO. Der Commander: "150 Sekunden? Das ist verrueckt langsam." Recht
   hat er. Gemessen ging die Zeit fast komplett in einen FEHLVERSUCH: `umount -l`
   ist lazy, der Abbau passiert spaeter, und wer direkt danach mountet, riskiert
   dass der Abbau hinter dem neuen Mount landet. Der erste Reparaturversuch
   scheiterte dadurch regelmaessig - und der zweite kostete 30 s mount-Timeout
   plus Pruefungen. Jetzt werden 1,5 s auf den Abbau gewartet, bevor neu
   gemountet wird; die Wache prueft erstmals nach 3 s statt 10 s und benutzt zum
   ERKENNEN die einfache schnelle Probe (die Doppelprobe steckt dort, wo der
   Wettlauf lauert: direkt nach dem Mount).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 14:52:53 +02:00
HitonabiandClaude Opus 5 4c2331563c docs(savepoint): v3.18 - Auswurf, externer Worker, und die Mount-Ursache
Ampel / ampel (push) Successful in 31s
Stellt eine Aussage aus v3.17 richtig: Dort stand die Mount-Sache als "Ursache
liegt beim NAS, nicht gefunden". Gemessen liegt sie bei uns - die CIFS-Verbindung
lebt in der Netz-Namespace des api-Containers und stirbt mit ihm. Das NAS ist
unschuldig.

AGENTS.md bekommt die Lehre, die diesen Abend zweimal gekostet hat: Ein
Rueckgabewert ist kein Beweis, wo die Wirkung pruefbar ist. CDROMEJECT quittiert
Erfolg auf einem verriegelten Laufwerk, `mount` quittiert Erfolg auf einer
Verbindung, die Sekunden spaeter stirbt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 14:40:31 +02:00
HitonabiandClaude Opus 5 4cf7acbb96 fix(mounts): DIE URSACHE gefunden - die CIFS-Verbindung stirbt mit dem Container
Ampel / ampel (push) Successful in 31s
Der Savepoint v3.17 fuehrte das als "Ursache liegt beim NAS, nicht gefunden".
Gemessen ist es etwas ganz anderes, und es liegt bei uns:

  /proc/fs/cifs/DebugData  ->  Net namespace: 4026532653
  api-Container            ->  net:[4026532653]   DIESELBE
  worker-Container         ->  net:[4026532540]   andere

Die CIFS-Verbindung lebt in der NETZ-NAMESPACE DES API-CONTAINERS - dort wird
sie eingehaengt, weil nur dieser Container CAP_SYS_ADMIN hat. Wird der Container
neu gebaut, stirbt sein Netz-Namespace und mit ihm der Socket. Der Mount steht
danach weiter in /proc/mounts (per rshared auf den Host propagiert) und sieht
vollkommen gesund aus - aber jeder Zugriff laeuft in den CIFS-Timeout.

Damit erklaert sich alles, was vorher widerspruechlich aussah: warum es nach
JEDEM Deploy passiert, warum `mount` Erfolg meldet, warum /proc/mounts genau eine
korrekte Schicht zeigt, und warum nur ein echtes Neu-Verbinden hilft. Das NAS ist
unschuldig (eine Sitzung, Status 1, 630 Credits, Ping 0,47 ms).

Zweiter Fund, der den Rest erklaert: Direkt nach einem frischen Mount antwortete
die Freigabe - und Sekunden spaeter nicht mehr. Das ist ein Wettlauf mit
`umount -l`: lazy heisst, der Abbau passiert spaeter, und faellt er samt
Propagation hinter den neuen Mount, zeigt der Pfad wieder auf die Leiche. Eine
einzige Probe kann das nicht sehen - deshalb prueft `wirklich_erreichbar()`
zweimal mit drei Sekunden Abstand, und zwar sowohl beim Mounten als auch in der
Wache.

Dazu: erste Pruefung der Wache schon nach 10 s statt 60 s. Genau dann ist die
Lage nach einem Deploy kaputt.

Ehrlich offen bleibt die strukturelle Folge: Der api-Container HAELT die
NAS-Verbindung. Startet er mitten in einem Rip neu, verliert auch der Worker sein
Ziel. Das saubere Gegenmittel waere ein Mount auf dem HOST statt im Container -
ein eigener Umbau, und er widerspraeche "Speicherziele ueber das UI einhaengen".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 14:32:51 +02:00
HitonabiandClaude Opus 5 549727f648 fix(mounts): Wache, die die Freigabe nach einem Rebuild von selbst zurueckholt
Ampel / ampel (push) Successful in 28s
Dreimal in Folge reproduziert, jetzt bei JEDEM Deploy: Nach `docker compose up -d
--build` ist die CIFS-Freigabe tot. `mount` meldet Rueckgabewert 0, /proc/mounts
zeigt genau eine korrekt aussehende Schicht, die Erreichbarkeits-Probe antwortet
direkt nach dem Mount sogar - und Sekunden spaeter laeuft jeder Zugriff in die
Zeitgrenze. Derselbe Ablauf ein bis zwei Minuten spaeter stellt sie zuverlaessig
her (POST /storage-mounts/rippy/repair, mehrfach belegt).

Die Ursache liegt am NAS und ist nicht gefunden. Aber die Wirkung ist teuer: Nach
jedem Update war jeder Rip auf die NAS kaputt, ohne dass irgendwo etwas davon zu
sehen war - und der Commander haette es jedes Mal von Hand richten muessen.
Wenn die Heilung bekannt und billig ist, gehoert sie automatisiert, auch ohne die
Ursache zu kennen.

Die Wache sieht jede Minute nach und verbindet stumme Freigaben neu. Zwei Dinge
sind dabei wichtiger als die Heilung selbst:

1. NIE waehrend ein Job laeuft. Neu verbinden heisst `umount -l`; mitten in einem
   Rip oder Encode waere das ein Datenverlust. Die Wache steht still, solange
   irgendein Job nicht durch ist - auch bei einem wartenden, der jeden Moment
   anlaufen kann (db.hat_arbeit).
2. Gemeldet wird nur der UEBERGANG. Ist das NAS ausgeschaltet, waere ein Log je
   Minute ein Wasserfall.

Der Zustand steht in /health/vorraete, damit man sehen kann, dass die Wache lebt
- dieselbe Lehre wie heute Nachmittag beim stillen except.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 14:24:09 +02:00
HitonabiandClaude Opus 5 87484d6863 feat(worker): der externe Worker wird erwachsen - Log in Rippy, Anzeige, Slots
Ampel / ampel (push) Successful in 28s
Commander 26.07.2026: "der externe Encoder Worker ist ein bisschen duenn - der
koennte noch viel mehr." Drei Punkte, alle am Tray.

1. LOG IN RIPPY STATT TXT-DATEI (ausdruecklich gewuenscht). Das Tray schrieb sein
   Log nach %LOCALAPPDATA% und oeffnete es im Editor - wer wissen wollte, warum
   der Worker nichts tut, musste sich an den PC setzen. Neue Bruecke
   (logbruecke.py) meldet die wichtigen Zeilen nach Rippy, Quelle "w:<name>",
   und die Logs-Seite hat jetzt Knoepfe je Quelle: "was macht mein PC" ist ein
   Klick. Der Filter konnte Quellen schon immer, es gab nur keinen Knopf.

   Durchgelassen wird WENIG und mit Grund: Die Job-Meldungen stehen laengst in
   Rippy (tasks.py schreibt sie selbst). Es fehlte, was DANEBEN passiert und den
   Worker unbrauchbar macht, ohne dass ein Job existiert - hochgefahren oder
   nicht, Verbindung zu Redis/Postgres, Abstuerze. Alles andere fliegt weg:
   Celery ist bei --loglevel=info gespraechig, die logs-Tabelle hat keine
   Aufraeumung, und ein zugemuelltes Log ist so unbrauchbar wie keins. Dazu eine
   Drossel (30 Zeilen/Minute), die MELDET, wieviel sie verschluckt hat.
   Zeilenformat woertlich aus dem laufenden Container abgenommen (Celery 5.4.0).

   Die lokale Datei bleibt - sie ist genau dann die einzige Auskunft, wenn Rippy
   nicht erreichbar ist.

2. DAS TRAY ZEIGT, WAS LAEUFT. Vorher stand dort "laeuft" oder "gestoppt" - auf
   einer Maschine, die stundenlang an einem Film rechnet, ist das keine Auskunft.
   Jetzt Titel, Prozent und Restzeit, geholt von Rippys /jobs. Bewusst dieselbe
   Quelle wie das Dashboard, damit im Tray nicht eine zweite, abweichende
   Schaetzung steht.

   Dazu: Windows schlaeft nicht mehr mitten im Encode ein
   (SetThreadExecutionState, ohne ES_DISPLAY_REQUIRED - der Bildschirm darf
   ausgehen). Die Sperre wird zurueckgenommen, sobald nichts laeuft, und auch bei
   einem harten Ende des Trays - sonst schlaeft der PC nie wieder ein und niemand
   weiss warum.

3. MEHRERE ENCODES GLEICHZEITIG. Der Worker lief fest mit --pool=solo und nahm
   genau EINEN Auftrag an. Der Installer fragt die Zahl jetzt (GUI: Feld neben
   dem Namen, mit der erkannten Kernzahl daneben), Vorbelegung ab 12 Kernen
   zwei, sonst einer: HandBrake nutzt schon alle Kerne, aber x265 skaliert nicht
   linear. Auf Windows gibt es keinen prefork-Pool (kein fork) - deshalb
   --pool=threads, was hier passt, weil die Arbeit ein Kind-Prozess ist und der
   Thread nur wartet.

GUI-Layout headless gerendert und angesehen (nichts ueberlappt, 16 Kerne
korrekt erkannt), beide .ps1 mit echtem PowerShell 5.1 geprueft, BOM und CRLF
erhalten, .exe neu gebaut.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 14:17:14 +02:00
HitonabiandClaude Opus 5 be04a9772e fix(auswurf): CDROMEJECT meldete Erfolg und tat nichts - erst entriegeln
Ampel / ampel (push) Successful in 29s
Commander-Meldung: "Den Button gibt es in den Settings, aber es passiert nicht,
das Laufwerk geht nicht auf." Am laufenden System nachgestellt, mit der Disc, die
gerade drin lag:

  wirf_disc_aus("/dev/sr0")      -> True
  CDROM_DRIVE_STATUS danach      -> 4 (Disc drin)

Das ioctl wird also ANGENOMMEN und tut nichts. Ursache: MakeMKV verriegelt
waehrend des Rips die Laufwerkstuer (CDROM_LOCKDOOR 1) und entriegelt sie nicht
wieder. Ein verriegeltes Laufwerk quittiert den Auswurf trotzdem mit Erfolg.
Gegenprobe an derselben Disc:

  CDROM_LOCKDOOR 0 + CDROMEJECT  -> Status 2 (SCHUBLADE OFFEN)

Genau das macht das Werkzeug `eject` immer: erst entriegeln, dann auswerfen.

Zweite Haelfte des Fixes, und die wichtigere: Das Ergebnis wird GEPRUEFT statt
geglaubt. Bisher gab wirf_disc_aus True zurueck, sobald das ioctl nicht geworfen
hatte - und ins Log kam "Disc ausgeworfen", waehrend die Schublade zu blieb.
Deshalb ist der Fehler in v3.14 durchgerutscht: Dort wurde richtig festgestellt,
dass die Einstellung von niemandem gelesen wurde, und danach WURDE sie gelesen -
ausgeworfen wurde weiterhin nicht. Jetzt wird das Laufwerk gefragt (bis zu 5 s,
die Schublade braucht ein bis zwei), und "kein Datentraeger" zaehlt mit, weil ein
Slot-Laufwerk keine Schublade hat.

Dieselbe Luecke steckte im Auswurf-Knopf der API (devices.eject) - dort mit
Klartext-Fehler, wenn die Disc drin bleibt.

Der Auswurf sitzt uebrigens schon an der richtigen Stelle: nach dem Rip, VOR dem
Einreihen der Kompression. Und das Laufwerk ist waehrend `transcoding` frei -
has_active_job blockiert nur bei pending/running, der Worker laeuft mit 4 Slots.
Die zweite Disc parallel war also nur am nicht aufgehenden Laufwerk gescheitert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 14:03:10 +02:00
HitonabiandClaude Opus 5 2587fe63af docs(savepoint): v3.17 - neun Punkte zu, vier Bestandsfehler dazu
Ampel / ampel (push) Successful in 27s
Der Savepoint trennt wie immer gemessen von vermutet - und stellt zwei
Behauptungen aus v3.16 richtig, die sich als falsch erwiesen haben:

1. "Die Namen der Hardware-Presets sind auf der Rippy-VM nicht ermittelbar."
   Falsch - `--preset-list` nennt sie vollstaendig, auch ohne Hardware-Encoder.
   Der vermeintliche Blocker fuer Punkt 1 existierte nicht.
2. "Rohschnitt intakt -> 'Neu komprimieren' genuegt." Falsch - can_retry war
   false, den Knopf gab es nicht.

AGENTS.md bekommt zwei neue Lehren aus dieser Sitzung: Hintergrund-Schleifen
muessen ihre Fehler melden (ein stiller except hat eine Stunde gekostet), und
Netz-Pfade nie ungebremst anfassen - os.path.isdir haengt auf einem toten CIFS
im Kernel und laesst sich aus Python nicht abbrechen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 13:55:41 +02:00
HitonabiandClaude Opus 5 87537bf3e5 fix(mounts): Ergebnis pruefen statt glauben - "mount" meldet Erfolg und liefert nicht
Ampel / ampel (push) Successful in 28s
Nachtrag zum vorigen Commit, weil der die Freigabe noch nicht zurueckbrachte.
Dreimal reproduziert: Beim API-Start meldete `mount` Rueckgabewert 0, das Log
schrieb "rippy: eingehaengt", /proc/mounts zeigte GENAU EINE korrekt aussehende
Schicht mit den richtigen Optionen - und `timeout 6 ls /app/media/rippy` lief
trotzdem in die Zeitgrenze. Derselbe Ablauf ein zweites Mal, per POST
/storage-mounts/rippy/repair, stellte sie sofort her (30 s, danach erreichbar).

Der erste SMB-Sitzungsaufbau kurz nach dem Container-Start geht also gelegentlich
schief, ohne es zu melden. Ein Rueckgabewert von `mount` beweist deshalb nichts.

Jetzt: Nach dem Mount wird geprueft, ob die Freigabe ANTWORTET (ist_erreichbar,
harte Grenze). Wenn nicht, einmal loesen und neu mounten. Hilft auch das nicht,
fliegt ein Fehler mit Klartext - dann steht im Log "FEHLER" statt "eingehaengt",
was schlicht die Wahrheit ist, und der Nutzer bekommt den Hinweis auf die
Reparatur-Funktion statt eines Rips, der spaeter still scheitert.

Damit ist die Kette geschlossen: os.path.isdir kann nicht mehr im Kernel haengen
(voriger Commit), die Rohdaten-Schleife stirbt nicht mehr daran, und ein Mount
gilt erst als hergestellt, wenn er antwortet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 13:46:37 +02:00
HitonabiandClaude Opus 5 a15623cc70 fix(mounts): Freigabe kam nach einem Rebuild nicht zurueck - Erreichbarkeit zuerst
Ampel / ampel (push) Successful in 28s
Bestandsfehler, beim Gegenpruefen dieser Sitzung aufgefallen und dreimal
reproduziert: Nach `docker compose up -d --build` war die CIFS-Freigabe TOT
(4 von 4 Zugriffen liefen in 10 s Timeout, /storage-mounts meldete
`reachable: false`) - und blieb es. Erst POST /storage-mounts/rippy/repair
stellte sie in einer Sekunde her.

Beim API-Start haette dasselbe passieren muessen. Warum nicht:

  if os.path.ismount(ziel):
      return schreibtest(ziel)

Der Mountpunkt existiert im NEUEN Container weiter (Bind-Mount vom Host), also
sagte ismount "ist schon da" und alle_remounten() brach genau hier ab. Dazu
oeffnet schreibtest() eine Datei OHNE Zeitgrenze - auf einem toten CIFS
blockiert das im Kernel, und der Start-Thread haengt dauerhaft (das waren die
zwei Threads im Zustand D, die diese Sitzung schon einmal gekostet haben).

Jetzt entscheidet ist_erreichbar() zuerst - das hat eine harte Grenze
(`timeout 3 ls`, seit 24.07. im Einsatz). Antwortet die Freigabe, sind ismount
und schreibtest danach gefahrlos. Antwortet sie nicht, faellt es durch auf
loesen + frisch mounten: derselbe Weg, den reparieren() geht, nur automatisch.

Fuer den Commander heisst das: Der NAS-Mount steht nach einem Deploy wieder von
selbst, statt still zu fehlen. Ohne das war jeder Rip auf die NAS nach einem
Update kaputt, ohne dass irgendwo etwas davon zu sehen war.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 13:40:58 +02:00
HitonabiandClaude Opus 5 8ccca90e3c fix(api): "konnte nicht nachsehen" ist nicht "ist weg"
Ampel / ampel (push) Successful in 28s
Gemessen nach dem letzten Deploy: Der ERSTE Zugriff auf die CIFS-Freigabe stallt
nach einem Container-Neustart mehrere Sekunden (die SMB-Sitzung wird neu
aufgebaut), danach antwortet sie in 0,01 s - zehn von zehn Versuchen, NAS per
Ping bei 0,47 ms. Die Freigabe ist also gesund, nur der erste Griff ist teuer.

In diesem Fenster lief die Pruefung in ihre Zeitgrenze, der Vorrat notierte
"keine Rohdaten", und der Knopf "Neu komprimieren" verschwand - obwohl 74 GB
dalagen. Der Nutzer haette daraus geschlossen, seine Daten seien weg. Genau
diese Sorte Fehlschluss ("aus einem Zustandswert auf einen Mechanismus") hat das
Projekt schon zweimal bezahlt.

Deshalb drei Antworten statt zwei: "da", "weg", "unklar". 124 ist der
Rueckgabewert von `timeout`, wenn es das Kind abgeschossen hat - das heisst
NICHT angesehen. Bleibt eine Pruefung unklar und der Vorrat hatte vorher einen
Treffer, wird die letzte bekannte Antwort gehalten statt Abwesenheit behauptet.

Wer eine Ja/Nein-Antwort braucht (verzeichnis_da), bekommt im Zweifel weiter
Nein - das ist die richtige Richtung fuer eine einzelne Abfrage.

Live davor geprueft: Die Schleife LEBT jetzt (alter_sekunden 30 -> 21 -> 12 -> 3
ueber 100 s) und heilt sich selbst - sobald die Freigabe antwortete, stand
mit_treffer=1 und can_retry=true.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 13:34:39 +02:00
HitonabiandClaude Opus 5 2554c2633b fix(api): os.path.isdir hing im Kernel und toetete die Schleife - harte Zeitgrenze
Ampel / ampel (push) Successful in 28s
Ursache gefunden, nicht geraten. Der neue Diagnose-Endpunkt sagte
`rohdaten.alter_sekunden: null` - die Funktion war NIE EINMAL fertig geworden,
und kein Fehler war gemeldet. Der Blick auf die Threads des API-Prozesses zeigte
zwei im Zustand **D** (uninterruptible sleep, im Kernel blockiert):

  tid=1600034 name=uvicorn state=D
  tid=1600037 name=uvicorn state=D

Der Mechanismus: Die Schleife startete ihren ersten Durchlauf, waehrend Rippy
beim Container-Start die CIFS-Freigabe neu einhaengte. Ihr `os.path.isdir` blieb
im Kernel stecken, `asyncio.to_thread` kam nie zurueck, die Schleife erreichte
ihr `sleep` nie - und war damit fuer immer tot. Sichtbar war nur, dass
can_retry dauerhaft false blieb.

Ein Timeout um den Aufruf haette nichts geholfen: Ein im Kernel haengender
Thread laesst sich aus Python nicht abbrechen, jeder Versuch haette einen
weiteren Thread verbrannt, bis der Pool leer ist.

Ein Kind-PROZESS laesst sich abbrechen. Geprueft wird jetzt mit
`timeout 4 ls -d <pfad>` - dasselbe Werkzeug, das mounts.ist_erreichbar seit dem
24.07.2026 fuer genau dieses Problem benutzt (dort fuer den toten NAS-Mount).
Laeuft es in die Zeitgrenze, gilt das Verzeichnis als "nicht da": Ein Ort, den
man nicht in Sekunden ansehen kann, ist fuer einen Rip ohnehin unbrauchbar.

os.listdir bleibt fuer /app/media selbst - das ist ein lokales Verzeichnis, die
Freigaben sind Unterordner davon. Und os.path.isdir bleibt fuer den Rueckfall
auf /app/temp/raw: ein Docker-Volume, dort kann nichts haengen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 13:28:02 +02:00
HitonabiandClaude Opus 5 0d8426d353 diag(api): Vorrats-Schleifen pruefbar machen - der stille except hat gekostet
Ampel / ampel (push) Successful in 28s
Live-Befund: /jobs/<id>/rohdaten findet die 74,1 GB, aber can_retry blieb ueber
80 Sekunden false - der Vorrat der Hintergrund-Schleife war leer. Direkt im
Container aufgerufen fuellt die Funktion ihn korrekt. Warum die Schleife im
Server-Prozess nichts tat, war NICHT zu sehen: Der `except Exception: pass`
verschluckte jeden Grund.

Zwei Konsequenzen, unabhaengig von der Ursache:

1. Die Schleife MELDET ihren Fehler jetzt (print in den Container-Log) statt ihn
   zu verschlucken. Ein Hintergrund-Prozess, der still scheitert, ist schlimmer
   als einer, der laut scheitert.

2. Neuer Diagnose-Endpunkt GET /health/vorraete: nennt fuer Ping- und
   Rohdaten-Vorrat, wie ALT der letzte Durchlauf ist. Bleibt so ein Vorrat leer,
   ist am Endpunkt selbst naemlich nichts zu sehen - er antwortet nur dauerhaft
   "nichts gefunden".

Die naheliegende Erklaerung (asyncio-Tasks ohne Referenz werden vom GC geholt)
ist widerlegt: Die aeltere Ping-Schleife laeuft nach demselben Muster und lebt -
ueber 72 Sekunden blieb jeder /capabilities-Aufruf unter 10 ms, waehrend ein
toter Ping-Vorrat je 30 s einen synchronen Nachping von ~1 s gekostet haette.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 13:23:32 +02:00
HitonabiandClaude Opus 5 9fbaed4af8 fix(api): Rohdaten-Suche in den Hintergrund - /jobs darf nie am NAS haengen
Ampel / ampel (push) Successful in 28s
Bei der Live-Gegenprobe gemessen: Waehrend der CIFS-Mount nach einem
Container-Neustart hochkam, brauchten /jobs und /jobs/<id>/rohdaten jeweils
10,0 Sekunden - genau der CIFS-Timeout. Das Dashboard fragt /jobs alle vier
Sekunden ab; ein schlafendes NAS haette es damit dauerhaft eingefroren.

Dieselbe Loesung wie beim Celery-Ping in /capabilities (v3.15): eine
Hintergrund-Schleife im 30-Sekunden-Takt sieht nach, wo Rohdaten liegen, und
/jobs liest nur noch ab. Kennt der Vorrat einen Job noch nicht (frischer
Fehlschlag), zaehlt der billige lokale Ort auf der Container-Platte - der
antwortet immer sofort.

Live geprueft, nachdem der Mount stand: /jobs 0,022 s, /rohdaten 0,014 s,
can_retry = true, 79.604.951.639 Bytes (74,1 GB) gefunden. Der 80-GB-Rohschnitt
des Commanders ist damit erstmals ueber das UI wieder erreichbar.

Der leere Treffer davor war KEIN Codefehler: der Mount stand in dem Moment
schlicht noch nicht. Beleg nachgeliefert - im Container gemessen findet die
Suche den Pfad in 0,000 s.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 13:15:42 +02:00
HitonabiandClaude Opus 5 108368d583 fix(jobs): Rohdaten werden gesucht statt geraten - "Neu komprimieren" ging nicht
Ampel / ampel (push) Successful in 28s
Bei der Live-Gegenprobe des neuen /rohdaten-Endpunkts aufgefallen, und der Fund
ist groesser als der Endpunkt: Job 95afdc89 hatte `can_retry = false`, obwohl
79,6 GB intakter Rohschnitt unter /app/media/rippy/<id> lagen. Der Knopf
"Neu komprimieren" existierte gar nicht.

Der SAVEPOINT v3.16 schrieb dazu: "Rohschnitt 79,6 GB intakt -> 'Neu
komprimieren' genuegt, kein Neu-Rip." Das war falsch, und zwar doppelt:

  _kann_neu_komprimieren  suchte in /app/temp/raw/<id> und unter dem AKTUELLEN
                          workDir -> Knopf erschien nicht
  retry_transcode         berechnete raw_dir aus demselben aktuellen workDir
                          -> haette am falschen Ort gesucht

Ursache in beiden Faellen: Der Rip war mit einer Wahl NUR FUER DIESEN RIP auf
die NAS gelegt worden (gibt es seit v3.15), die Einstellung selbst stand auf
leer. Damit zeigte nichts mehr auf die Datei. Wieder derselbe Fehler, den dieses
Projekt schon mehrfach bezahlt hat: aus einem Zustandswert (der heutigen
Einstellung) auf einen Mechanismus (wohin damals gerippt wurde) geschlossen,
statt nachzusehen.

Neues Modul rohdaten.py sucht jetzt an allen Orten, die ueberhaupt in Frage
kommen: Container-Standard, eingestelltes Arbeitsverzeichnis und jedes
Ablageziel unter /app/media. Der Suchraum ist geschlossen, weil
_arbeitsverzeichnis() im Worker nur diese zulaesst; verwechseln kann man nichts,
weil Roh-Verzeichnisse exakt wie die Job-ID heissen (vollstaendige UUID) und
fertige Ablagen "Titel (Jahr) [kurz-id]".

Nicht in die Job-Zeile geschrieben, obwohl das sauberer waere: create_all legt
nur fehlende TABELLEN an, keine Spalten - und Bestandsjobs (genau dieser Fall)
haetten den Wert ohnehin nicht.

11 Tests, darunter der echte Fall, ein toter CIFS-Mount und der Klassiker
"/app/media-boese".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 13:09:44 +02:00
HitonabiandClaude Opus 5 843c54cd1a fix(test): Erwartung korrigiert - ohne Quelle ist die Confidence 0,3, nicht 0,0
Ampel / ampel (push) Successful in 27s
Meine eigene Testannahme war falsch, nicht der Code: Antwortet keine
Metadaten-Quelle, setzt _scan_video bewusst 0,3 mit `type: unknown` und behaelt
den Disc-Titel. Der Rip laeuft dann trotzdem, die Datei heisst nur wie das
Disc-Label. Genau dieser Zweig ist Bestand und richtig.

Gefunden von der Ampel (Lauf 140) - lokal laeuft dieses Modul nicht, es braucht
fcntl.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 13:01:34 +02:00
HitonabiandClaude Opus 5 ee123f2a90 fix(install): Paketbefehl je Distribution statt stur apt
Ampel / ampel (push) Failing after 29s
Commander-Frage: "Was wenn der Unterbau nicht Debian ist?" Berechtigt - bei
fehlendem Compose nannte install.sh stur `sudo apt install
docker-compose-plugin`. Auf Arch, Fedora oder openSUSE ist das ein Befehl, den
es nicht gibt.

Erkannt wird ueber das VORHANDENE Paketwerkzeug (apt-get/dnf/yum/pacman/zypper/
apk), nicht ueber /etc/os-release: Ein Derivat kann sich anders nennen als sein
Unterbau, sein Paketwerkzeug liegt aber im PATH. Findet sich keines, wird nichts
behauptet. Auf der Rippy-VM gegengeprueft (Ubuntu 26.04 -> apt), unter Git Bash
gegengeprueft (kein Treffer -> keine Behauptung).

Dazu steht IMMER der Weg da, der auf jeder Distribution funktioniert:
get.docker.com bringt das Compose-Plugin mit. Paketnamen wandern, dieses Skript
nicht.

README stellt jetzt oben klar, dass die Distribution gleichgueltig ist - Rippy
bringt MakeMKV, HandBrake und abcde in seinen eigenen Containern mit, vom Host
braucht es nur Docker und einen Kernel, der das Laufwerk sieht.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 12:59:42 +02:00
HitonabiandClaude Opus 5 0c269a97ee fix(metadaten): exakt schlaegt unscharf - Jikan beendet die Kette nur bei Treffer
Der SAVEPOINT v3.16 vermutete, das Aehnlichkeits-Gate 0,55 sei "grosszuegig" und
Jikan stehe in der Kette zu frueh (vor OMDb). Nachgerechnet - titel_aehnlichkeit
ist eine reine Funktion - ergibt sich ein anderes Bild als vermutet:

  "Alien"           vs. "Alien 9"           -> 0,83  TRIFFT
  "Inception"        vs. "Deception"         -> 0,78  TRIFFT
  "Hero"             vs. "Heroman"           -> 0,73  TRIFFT
  "The Dark Knight"  vs. "Dark Knight Rises" -> 0,69  TRIFFT

Ein Kinofilm, den TMDB verpasst, bekam damit Anime-Metadaten mit Confidence
0,85 - und OMDb, das ihn kennt, wurde nie gefragt.

Bemerkenswert dabei, und das widerlegt die Vermutung "einfach zu niedrig": Fuer
den Fall, fuer den Jikan ueberhaupt eingebaut wurde, ist das Gate sogar zu HOCH.
"Evangelion 2.22" gegen den MAL-Titel "Evangelion: 2.0 You Can (Not) Advance"
ergibt 0,51 und faellt durch. Eine einzelne Zahl kann beides nicht leisten.

Deshalb zwei Schwellen statt Umsortieren (Reihenfolge bleibt, AGENTS Regel B):
Nur ein praktisch exakter Titel (>= 0,9) beendet die Kette. Ein unscharfer
Treffer wird GEMERKT, dann wird OMDb gefragt - und erst wenn OMDb nichts hat,
kommt er als VORSCHLAG mit Confidence 0,6 zum Zug. Damit gewinnt "exakt" immer
gegen "unscharf", egal aus welcher Quelle.

Antwort auf die Commander-Frage "JIKAN ist drin - wird das genutzt?": ja, und ab
jetzt an der richtigen Stelle.

Ehrlicher Vorbehalt: Live gegengeprueft ist das nicht - MyAnimeList war waehrend
dieser Sitzung durchweg weg (Jikan antwortete HTTP 504 auf jede Anfrage). Die
Arithmetik des Gates ist davon unberuehrt und in test_jikan_helpers.py
festgehalten, die Kettenlogik in test_prescan_helpers.py.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 12:59:26 +02:00
HitonabiandClaude Opus 5 6db64230eb fix(dashboard): zwei Placebos raus, Restzeit rein - und Loeschen sagt die Zahl
Commander: "Der Server Status muss dringend ueberarbeitet werden, das Dashboard
soll ja quasi alles auf einen Blick zeigen." Berechtigt - die Karte hiess "Echte
Live-Daten" und enthielt drei Angaben, von denen zwei erfunden waren:

1. "Auslastung: 0 % (Aktiv)" war NICHT die CPU-Last, sondern der Fortschritt des
   Jobs - bzw. eine feste 15 bzw. 5, wenn keiner lief. Rippy misst nirgends
   CPU-Last, also wird sie auch nicht behauptet.
2. Die Verlaufskurve daneben war Math.random(). Reine Dekoration, die wie eine
   Messung aussah.
3. "N Worker Online" zaehlte die registrierten Eintraege aus /system/info - auch
   Leichen alter Container-Rebuilds. Die echte Erreichbarkeit steht in
   /capabilities (Celery-Ping) und wird jetzt von dort geholt.

Statt dessen: laufende Phase im Klartext mit RESTZEIT, jeder erreichbare Worker
mit Kernen/Vektorbefehlen/extern, freier Platz mit Warnung, wenn er nicht mehr
fuer eine Disc reicht. Und wenn kein Worker antwortet, steht das rot da statt
"1 Worker Online".

Restzeit auch im aktiven Rip-Banner und in der Job-Tabelle. Solange die
Datenlage duenn ist, steht dort "Restzeit wird gemessen" - keine erfundene Zahl.

Job entfernen fragt jetzt vorher nach den Rohdaten und nennt die GB, die daneben
liegen bleiben und danach nicht mehr erreichbar sind - auf Wunsch loescht es sie
mit. Der Fall aus v3.14, bei dem 75 GB unsichtbar verwaisten.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 12:59:08 +02:00
HitonabiandClaude Opus 5 638edc6a9f feat(ui): Presets vom Worker, Warnung vor unerreichbaren Pfaden, Browser weg
Vier Commander-Punkte auf einmal, alle am selben Ort.

Presets (Punkt 1 + 3b): Die drei Auswahllisten in Einstellungen kommen jetzt
vom Worker statt aus dieser Datei, gefiltert auf die passende Aufloesung - die
4K-Liste bietet keine 1080p-Presets mehr als Normalfall an (genau dieser Griff
rechnete in v3.12 eine 4K-UHD auf 1080p herunter; bewusstes Verkleinern steht
jetzt in einer eigenen, benannten Gruppe). Knopf "Bestes waehlen" uebernimmt die
Empfehlung fuer alle drei Disc-Typen, und unter jeder Liste steht, WARUM. Ein
gespeicherter Wert, den der Worker nicht kennt, wird benannt statt verschluckt -
so faellt eine falsche Bestandseinstellung ueberhaupt auf.
Der Wizard entscheidet nicht mehr selbst, sondern nimmt dieselbe Empfehlung.
Damit gibt es nur noch EINE Stelle mit dieser Logik, und die hat Tests.

Warnung vor dem Start (Punkt 6 des Savepoints): Waehlt man einen externen
Encoder, der Quelle oder Ziel nicht erreicht, steht das JETZT im Rip-Dialog -
nicht erst nach einer Stunde Rip. Geprueft wird mit derselben Regel, die
pfad_lokal() im Worker anwendet. Bei "Automatisch" wird genannt, welcher Worker
die Aufgabe kaputtmachen koennte: die geteilte Queue nimmt den ersten freien.

Datei-Browser (Punkt 7): "Warum wird hier der Datei Browser noch angezeigt - das
ist doch quatsch." Er ist nicht wirklich redundant (nur ueber ihn geht ein
freier Zielordner fuer EINEN Rip), aber er ueberschrieb die Schnellwahl
stillschweigend. Jetzt eingeklappt - wer ihn aufklappt, entscheidet bewusst, und
/browse wird erst dann geholt. Nebenbefund: browseFiles wurde geladen und NIE
angezeigt, samt ungenutztem File-Icon - beides raus.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 12:58:53 +02:00
HitonabiandClaude Opus 5 aea26493db feat(installer): der Windows-Installer holt die Freigabe jetzt selbst von Rippy
DER BLOCKER aus dem SAVEPOINT v3.16 ist zu. Beide Installer (Kommandozeile und
GUI) fragen GET /worker-setup/pfad-map, pruefen mit Test-Path, ob DIESER PC die
Freigabe wirklich erreicht, und schreiben `set RIPPY_PATH_MAP=...` in
start-tray.bat und start-worker.bat.

Der Commander muss dafuer nichts ueber Container-Pfade wissen - das Feld bleibt
leer, der Installer holt den Wert. Von Hand geht es trotzdem (Knopf "Von Rippy
holen" bzw. -PfadMap), falls dieser PC die Freigabe anders erreicht.

Ist nichts erreichbar, steht das als Klartext im Log samt dem haeufigsten Grund
(fehlende Zugangsdaten - Freigabe einmal im Explorer oeffnen). Die Installation
laeuft weiter: ein Worker, der sich meldet und ehrlich scheitert, ist besser als
einer, der nicht existiert. Ein LEERES RIPPY_PATH_MAP wird bewusst nicht
gesetzt - pfad_lokal() liest das als "kein Mapping", und die Fehlermeldung im
Worker unterscheidet genau diese beiden Faelle.

GUI: neues Feld samt Knopf, Fenster 560->648 px. Layout headless gerendert und
angesehen (nichts ueberlappt, Umlaute korrekt), beide Dateien mit echtem
PowerShell 5.1 auf Parser-Fehler geprueft, UTF-8-BOM erhalten. .exe neu gebaut.
install.ps1 hatte durch ein Werkzeug LF statt CRLF bekommen - zurueckgedreht.

remote-transcode-worker.yml richtiggestellt: Dort stand "mount -t nfs
<rippy-host>:/srv/rippy" - das geht NICHT, auf der Rippy-Maschine laeuft kein
NFS- und kein Samba-Server, sie ist selbst nur Client der NAS. Der Weg, der
funktioniert: dieselbe Freigabe einhaengen, die auch Rippy nutzt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 12:58:23 +02:00
HitonabiandClaude Opus 5 8b7bdfe798 feat(api): drei Endpunkte, die das Raten beenden - plus Restzeit in /jobs
GET /worker-setup/pfad-map - was ein externer Worker fuer RIPPY_PATH_MAP
eintragen muss, abgeleitet aus Rippys eigenen Mounts. DAS war der stille
Blocker: /app/media/... sind Container-Pfade, ein externer Worker sieht sie nur
uebersetzt, und dieses Mapping setzte NIEMAND. Externes Encoden konnte deshalb
nie funktionieren, obwohl das Celery-Routing einwandfrei arbeitete (Job
95afdc89: angenommen, 182 ms spaeter abgelehnt). Hat Rippy keine Freigabe, sagt
der Endpunkt das im Klartext samt Abhilfe - statt ein leeres Mapping zu liefern.

GET /presets - Preset-Namen der Worker plus Empfehlung MIT Begruendung. Die
Namen standen bisher fest verdrahtet an vier Stellen im UI.

GET /jobs/{id}/rohdaten + DELETE /jobs/{id}?rohdaten=true - was liegen bleibt,
wenn ein Job aus der Liste fliegt. Grund (v3.14): Entfernen loescht bewusst
keine Dateien, aber Job und Rohdaten haengen nur an der Job-ID - der Rohschnitt
ist danach UNERREICHBAR. Damals verwaisten so 75 GB unsichtbar, gefunden erst
per SSH.

/jobs liefert jetzt eta_sekunden + eta_text. Die Schaetzung entsteht in der API
und nicht im Browser, aus drei Gruenden: ein Seitenwechsel setzte die Messreihe
zurueck, zwei offene Tabs zeigten verschiedene Zahlen, und fuer einen externen
Encoder-Worker gaebe es gar keine - genau dort wollte der Commander sie sehen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 12:58:06 +02:00
HitonabiandClaude Opus 5 4195854bf8 feat(bausteine): Preset-Liste, Pfad-Vorschlag und Restzeit - alles gemessen
Vier neue reine Bausteine, jeder mit Tests. Sie beantworten Fragen, die Rippy
bisher geraten oder gar nicht gestellt hat.

1. caps.parse_preset_liste - die Preset-NAMEN, die das HandBrake DIESES Workers
   wirklich kennt (`--preset-list`, Format im Worker-Image gemessen). Damit
   endet das Raten: die Namen unterscheiden sich je HandBrake-Version, und ein
   erfundener Name laesst die Kompression scheitern.
   Richtigstellung zum SAVEPOINT v3.16: Dort galt es als unmoeglich, die
   Hardware-Preset-Namen auf der Rippy-VM zu ermitteln, weil dort kein
   Hardware-Encoder laeuft. Gemessen ist das falsch - die Kategorie `Hardware/`
   steht vollstaendig in der Liste (VCN, NVENC, QSV, MF). HandBrake trennt
   zwei Fragen: --preset-list nennt alle Presets, --help nur die nutzbaren
   Encoder. Zwei Fragen, zwei Quellen.

2. mounts.pfad_map_vorschlag/pfad_map_zeile - der fehlende Anschluss fuer
   RIPPY_PATH_MAP. Geraten werden muss dafuer nichts: Rippy hat die Freigabe
   selbst eingehaengt und kennt ihre Quelle (//host/share). Mountpunkt plus
   Quelle IST das Mapping. NFS gibt bewusst "" - Windows-Schreibweise ist nicht
   ableitbar (AGENTS Regel D).
   Der Test fand dabei sofort die dokumentierte Windows-Falle: os.path.join
   baute `/app/media\rippy` in einen Container-Pfad, das Mapping waere still
   wirkungslos geblieben. _mountpoint nutzt jetzt posixpath.

3. presets.empfehlung - "immer das Beste" (Commander-Anforderung) ohne
   Punktesystem: fuer jede Lage eine feste Reihenfolge echter Namen, genommen
   wird der erste, den der Worker kennt. Hardware nur, wenn die Familie
   wirklich gemeldet ist (vce -> Preset heisst VCN, sonst liefe eine AMD-Karte
   unter dem Intel-Namen). vaapi und MF werden nie empfohlen: fuer vaapi gibt
   es kein Preset, bei MF ist die Nutzbarkeit nicht ablesbar.

4. eta - Restzeit aus dem gemessenen Fortschritt. Messreihe je Phase (Rip und
   Kompression haben nichts miteinander zu tun), Stillstand verlaengert die
   Schaetzung, und unter zwei Messwerten oder 60 Sekunden Spanne gibt es
   ehrlich keine Aussage. Test mit den echten 25.07.-Werten: 1,44 % in 29 min
   landet bei "noch ca. 1 Tag 23 h" - genau die Angabe, deren Fehlen den
   50-Stunden-Lauf unsichtbar machte.

Dazu: HandBrakes "Invalid preset <Name>" wird uebersetzt. Vorher stand im UI
nur "HandBrake endete mit Code 3" - dass der Preset-NAME das Problem ist, war
daraus nicht zu erraten.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 12:57:51 +02:00
HitonabiandClaude Opus 5 a468e4b6a4 docs(savepoint): Commander-Feedback als Landkarte - neun Punkte, neun Staende
Ampel / ampel (push) Successful in 27s
Rueckfrage des Commanders: "Was ist mit diesen ganzen Sachen?" - er wollte
wissen, ob seine Liste aus der ersten Selbst-Einrichtung vollstaendig erfasst
ist. Nachgeprueft: alle neun Punkte kommen im v3.16-Block vor.

Einer war aber nur IMPLIZIT zu finden: dass seine RX 9070 XT wirklich
encodieren soll, musste man aus zwei anderen Punkten erschliessen (Pfad-Mapping
und Preset-Namen). Genau so faellt etwas durch.

Jetzt steht seine Liste woertlich als Tabelle im Savepoint, jede Zeile mit
Stand und Verweis auf die Prioritaetenliste. Drei erledigt, eine Frage
beantwortet, fuenf offen.

Aufgeteilt wo noetig: Punkt 3 war eigentlich drei Forderungen - Vektorbefehle
auslesen (erledigt), das Beste empfehlen (offen), und Warnung von orange auf
gruen (erledigt, wirkt fuer seinen PC ab dem Deploy).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 12:10:59 +02:00
HitonabiandClaude Opus 5 4c78914529 docs(savepoint): v3.16 Uebergabe - externes Encoden konnte nie funktionieren
Ampel / ampel (push) Successful in 27s
Diese Sitzung endete wegen vollem Kontext. Der Savepoint ist so geschrieben,
dass die naechste ohne Nachfragen weitermachen kann.

ZUSTAND, den man kennen MUSS: Repo fd1feaa mit gruener Ampel, aber die VM laeuft
noch 61c38a0 - die letzten zwei Commits sind NICHT deployt, und der
Windows-Worker des Commanders laeuft mit altem Code. Der 80-GB-Rohschnitt liegt
intakt auf der NAS, "Neu komprimieren" genuegt also, sobald der Blocker faellt.

DER KERNBEFUND aus dem fehlgeschlagenen Test-Rip, mit Messung statt Vermutung:
Das gezielte Routing funktionierte einwandfrei - sein PC nahm die Aufgabe an und
lehnte sie 182 ms spaeter ab. Drei Ursachen griffen ineinander, zwei sind
behoben, eine bleibt der Blocker (RIPPY_PATH_MAP wird von niemandem gesetzt).

Die offenen Punkte stehen nach Prioritaet, jeweils MIT dem Kontext, der zum
Weiterarbeiten fehlt: Format von pfad_lokal fuer Punkt 1, warum Punkt 2 nicht
ohne die Preset-Liste vom Worker geht (AGENTS Regel D - Namen erfinden hat das
Projekt zweimal teuer bezahlt), welcher Messpunkt sich fuer die ETA bewaehrt hat
(/proc/<pid>/fdinfo statt Fortschrittsanzeige), und welche Datei jeweils dran ist.

Dazu ein eigener Abschnitt "Fallen, die diese Sitzung gekostet haben" - deutsche
Anfuehrungszeichen in doppelt gequoteten Python-Strings (dreimal), Code in
f-String-Einsetzungen, docker exec ohne sh -c verschluckt Globs, /proc-Suche
trifft die eigene Shell, und pydantic-core springt lokal wiederholt zurueck.
Alles auch in den Memory-Notizen, damit es nicht wieder entdeckt werden muss.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 12:06:32 +02:00
HitonabiandClaude Opus 5 fd1feaaee3 fix(ui): die Ablage war im UI ueberhaupt nicht einstellbar
Ampel / ampel (push) Successful in 28s
Der Grund, warum der erste Rip mit externem Encoder scheitern MUSSTE - und
Commander-Vorgabe: "Wenn ein externes Ziel eingehaengt ist, soll Rippy das
ausgewaehlte als Arbeitsziel verwenden. Das stellt man ja sowieso in den
Einstellungen ein. Das muss auch fuer den Automatik-Modus so sein."

Genau das ging nicht. outputDir stand in den Einstellungen, wurde von der
Vollautomatik (main.py) und der Schnellwahl (RipTargetModal) gelesen - aber es
gab NIRGENDS ein Eingabefeld. Die Ablage klebte auf /app/media, der
Container-Platte. Das Arbeitsverzeichnis hatte eine Auswahlliste der
eingehaengten Ziele, das Ziel nicht.

Folge im Praxistest: Rohdaten auf der NAS (die der PC erreicht), Ziel auf der
VM-Platte (die er nicht erreicht, kein Samba dort). Der externe Encoder konnte
lesen, aber nicht schreiben - und das haette man mit den vorhandenen
Bedienelementen gar nicht anders einstellen koennen.

JETZT: Ablage-Auswahl in Einstellungen -> Ripping, mit derselben Liste
eingehaengter Ziele wie das Arbeitsverzeichnis. Damit wirkt sie automatisch
auch in der Vollautomatik und in der Schnellwahl, weil beide outputDir lesen -
also genau so, wie der Commander es beschrieben hat.

DAZU die Pruefung, die den Vorfall verhindert haette: Sobald ein EXTERNER
Worker gemeldet ist, warnt das UI, wenn Ablage und Arbeitsverzeichnis nicht
beide auf einer erreichbaren Freigabe liegen. Drei Faelle, jeweils mit der
Konsequenz im Klartext:
  - Arbeitsverzeichnis auf der Container-Platte -> externer Encoder kann nicht lesen
  - Arbeit auf Freigabe, Ablage lokal -> kann lesen, nicht schreiben (der Vorfall)
  - beide auf VERSCHIEDENEN Freigaben -> laeuft, kostet aber eine Vollkopie

"Extern" ist dabei keine Heuristik ueber IPs oder Namen: caps.py meldet es
selbst (`extern`), weil /app im Rippy-Image immer existiert und ausserhalb nie.
Zusaetzlich meldet der Worker jetzt seine `pfad_map` - damit kann das UI im
naechsten Schritt sagen, ob die Uebersetzung ueberhaupt gesetzt ist.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 11:58:58 +02:00
HitonabiandClaude Opus 5 fe12401e34 fix(worker): Hardware-Encoder und CPU-Merkmale auf Windows - plus ehrliche Transcode-Fehler
Aus dem gescheiterten Test-Rip des Commanders (Job 95afdc89) und seiner
UI-Durchsicht. Der Reihe nach.

## 1. Der externe Encoder wurde SEHR WOHL gesehen (Diagnose-Korrektur)

Der Commander schloss aus der Meldung, das System sehe seinen PC nicht. Live
gemessen sagt das Gegenteil:

    meta.transcode_node = tobisnicerpc@TobisNicerPC
    VM-Worker-Log        = nur rip_disc, KEIN transcode_files
    22:19:41.271  Kompression eingereiht
    22:19:41.453  "Keine Roh-MKVs gefunden"   <- 182 ms spaeter

Das Routing hat funktioniert. Sein PC nahm die Aufgabe an und lehnte sie sofort
ab, weil er /app/media/rippy/<job> nicht finden kann - ein Pfad, der nur INNEN
im Container existiert. Der Rip war vollstaendig (79,6 GB auf der NAS).

## 2. Der Hardware-Encoder-Bug war meiner

leite_backends_ab() verlangte zusaetzlich ein Geraet: /dev/dri fuer
VAAPI/QSV/VCE bzw. nvidia-smi fuer NVENC. Unter WINDOWS gibt es beides nicht -
der PC des Commanders (RX 9070 XT) meldete deshalb nur CPU-Encoder, obwohl
HandBrakes Windows-Build vce_*/nvenc_*/qsv_* beherrscht. Der Bug traf genau den
Anwendungsfall, fuer den externe Worker gedacht sind.

Die Pruefung war ausserdem ueberfluessig: HandBrake probiert Hardware beim
Start selbst an und listet nur Nutzbares - auf der VM belegt durch
"qsv: not available on this system" bei gleichzeitig fehlendem qsv_* in --help.
Jetzt ist HandBrakes Liste die einzige Auskunft.

Dazu nach FAMILIE unterschieden (nvenc/qsv/vce/vaapi) statt alles in "vaapi" zu
werfen - eine AMD-Karte lief unter dem Intel-Namen. Hardware-AV1 bekommt eine
eigene Kennung, weil es die beste Kombination aus Tempo und Groesse ist und
sonst unsichtbar bliebe.

## 3. Vektorbefehle unter Windows - gemessen, nicht "unbekannt"

Es gibt dort kein /proc/cpuinfo, also meldete der Windows-Worker
"Vektorbefehle unbekannt" - gerade auf der Maschine, die encodieren soll.
Jetzt ueber IsProcessorFeaturePresent (kernel32, winnt.h dokumentiert) plus
CPU-Name aus der Registry. Auf dem Commander-PC gegengeprueft:

    vorher: AMD64 Family 26 Model 68 Stepping 0  /  Vektorbefehle unbekannt
    jetzt:  AMD Ryzen 7 9700X 8-Core Processor   /  avx512f  /  16 Kerne

Damit verschwindet die AVX2-Warnung fuer diesen Worker von selbst - genau das
hatte der Commander gefordert.

## 4. Ehrliche Fehlermeldung statt "Keine Roh-MKVs gefunden"

Neues _erreichbarkeit_pruefen() unterscheidet jetzt drei Faelle statt einem:
Pfad nicht erreichbar UND kein Mapping gesetzt (nennt RIPPY_PATH_MAP samt
Beispiel), Mapping gesetzt aber greift nicht, oder Pfad einfach nicht da. Und
es prueft BEIDE Pfade - im Fall des Commanders lag die Quelle auf der
erreichbaren NAS, das ZIEL aber auf der VM-Platte ohne Samba; das waere erst
beim Schreiben nach Stunden Rechenzeit aufgefallen.

Jede Meldung sagt jetzt ausdruecklich, dass die Rohdaten NICHT verloren sind
und "Neu komprimieren" genuegt.

## 5. Persoenliche Werte raus

Vier Platzhalter trugen die Umgebung des Commanders (192.168.178.20,
TOBIS-PC, seine Jellyfin- und Rippy-IP). In einem Repo, das weitergegeben
wird, hat das nichts verloren.

Nebenbei dreimal in die eigene Falle getappt: deutsche Anfuehrungszeichen in
DOPPELT gequoteten Python-Strings beenden den String vorzeitig. Der Bestand
nutzt dafuer einfach gequotete f-Strings - jetzt auch meine.

NOCH OFFEN und wichtig: RIPPY_PATH_MAP wird von niemandem GESETZT (Installer,
UI, Compose). Ein Windows-Worker kann damit grundsaetzlich nicht transcodieren.
Das ist der naechste Schritt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-26 11:51:47 +02:00
HitonabiandClaude Opus 5 61c38a0d14 docs(readme): eigener Abschnitt fuer Dockge, Portainer, Arcane und Shell
Ampel / ampel (push) Successful in 28s
Commander-Plan fuer die Uebergabe: "Repo auf den Dockge-Server laden, Compose
reinhauen, Profit?!" - und genau da sitzt die Falle, in die jeder zuerst tappt.

DER KERN, der jetzt oben im Abschnitt steht: Rippy hat KEINE Registry-Images.
api, worker und ui werden aus dem Repo gebaut (build: context: .). Die
Compose-Datei allein ist deshalb wertlos - in ein leeres Verzeichnis kopiert
gibt es sofort "failed to read dockerfile". Daraus folgt fuer JEDE Oberflaeche
dieselbe Regel: das Repo muss dort liegen, wo die Oberflaeche den Stack baut.

Je Werkzeug der konkrete Weg, weil sie sich genau darin unterscheiden:

- Dockge kann das Repo NICHT selbst holen -> hinein in den Stacks-Ordner
  klonen (Standard /opt/stacks). Dann ist die Compose des Repos die des Stacks,
  und man darf den Stack gerade NICHT neu in Dockge anlegen - sonst liegt eine
  leere Compose in einem anderen Ordner.
- Portainer KANN es selbst holen -> Stacks > Add stack > Repository mit
  Git-URL. Web-Editor und Upload funktionieren nicht (kein Build-Kontext).
  Geraeteknoten dort als Stack-Umgebungsvariablen statt .env.
- Arcane: Repo auf dem Host, Deploy per Shell - der Git-Sync zieht nicht
  selbststaendig (auf dieser Installation seit Wochen die geuebte Praxis).
- Shell: unveraendert git clone + sudo ./install.sh.

Dazu die Vorab-Pruefung als gemeinsamer Einstieg: ./install.sh --nur-pruefen
braucht kein root, aendert nichts und nennt vor allem die ECHTEN
Geraeteknoten - der einzige Punkt, der zuverlaessig zuschlaegt.

RICHTIGSTELLUNG an mir selbst: Ich hatte die Mount-Propagation als Huerde
dargestellt. Auf den meisten systemd-Hosts ist / schon rshared und /srv/rippy/
media erbt das - da ist nichts zu tun. Nur wenn Docker ueber "not a shared
mount" klagt, braucht es die Shell. Steht jetzt so drin.

Stoerungstabelle von vier auf sechs Faelle: "failed to read dockerfile" und
"Worker startet nicht, /dev/sgN fehlt" ergaenzt - die beiden, die ein
Oberflaechen-Nutzer als erste sieht. Interne Verweise gegengeprueft, alle vier
loesen auf.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 23:02:46 +02:00
HitonabiandClaude Opus 5 29444805a8 fix(build): der MakeMKV-Fallback der VM war seit Monaten tot - Kette jetzt dreistufig
Ampel / ampel (push) Successful in 28s
Beim Aufraeumen der VM-.env aufgefallen und nachgemessen (25.07.2026):

    https://www.makemkv.com/download        HTTP 200   <- Repo-Standard
    https://www.makemkv.com/download/old    HTTP 525   (Cloudflare)
    web.archive.org-Schnappschuss           HTTP 404   <- stand in der VM-.env

Die VM zeigte also auf eine KAPUTTE Adresse. Aufgefallen ist es nie, weil dort
die vendor/-Tarballs liegen und der Download-Zweig gar nicht erreicht wird.
Nimm die Tarballs weg, und jeder Bau scheitert mit 404 - waehrend die
Konfiguration gesund aussieht. Genau diese Sorte Fehler ist bei einer Uebergabe
teuer, weil sie erst beim Fremden zuschlaegt.

## Bereinigt (auf Commander-Wunsch, Sicherung liegt auf der VM)

.env.sicherung-vor-aufraeumen-20260725 angelegt, dann:
- MAKEMKV_URL_BASE raus -> es gilt der Compose-Standard, der liefert.
  Von Docker gegengeprueft: MAKEMKV_URL_BASE: https://www.makemkv.com/download
- JWT_SECRET_KEY raus -> Ueberrest der in v3.4 ausgebauten Anmeldung, wirkungslos.

## Fallbacks BEHALTEN, aber echt gemacht (Commander-Vorgabe)

Vorher war der "Fallback" eine Zeile, die man von Hand eintragen musste - und
die hier ins Leere zeigte. Jetzt eine automatische Kette:

  1. vendor/-Tarballs        (braucht kein Netz, zuverlaessigster Weg)
  2. MAKEMKV_URL_BASE
  3. MAKEMKV_URL_FALLBACK    (NEU, wird automatisch versucht wenn 2 versagt)

Stufe 3 ist ABSICHTLICH leer vorbelegt. Es gibt derzeit keine belegbare zweite
Quelle (siehe Messung oben), und eine einzutragen, die nicht liefert, waere
schlimmer als keine - genau das lag auf der VM vor. Wer eine eigene Quelle hat
(Spiegel im LAN), traegt sie ein und sie wird automatisch genutzt.

Scheitert alles, nennt die Fehlermeldung jetzt die beiden Wege, die
FUNKTIONIEREN, statt nur einen curl-Rueckgabewert zu hinterlassen.

## Geprueft, beide Zweige

- vendor-Pfad:   Bau durch, 828 MB
- Download-Pfad: im FREMDEN Klon ohne Tarballs gebaut - Bau durch, 777 MB,
  makemkvcon liegt unter /usr/local/bin/. Die leere Fallback-Stufe wird
  korrekt uebersprungen, "Erste Quelle lieferte nicht" erschien nicht.

docker compose config validiert. README und .env.example nennen die gemessenen
HTTP-Antworten, damit niemand wieder eine 404-Adresse als Fallback eintraegt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 22:50:54 +02:00
HitonabiandClaude Opus 5 b0205c42c9 refactor(install): erst ALLES pruefen, dann erst aendern
Ampel / ampel (push) Successful in 28s
Commander-Einwand: "Warum macht das install script den pre-check nicht selbst
vor der Installation?" Zu Recht - es tat es nur halb.

VORHER war Pruefen und Aendern verschraenkt:
  1 Voraussetzungen  pruefen (bricht ab)
  2 Laufwerk         pruefen (warnt)
  3 Verzeichnisse    AENDERT
  4 Mount            AENDERT
  5 .env             AENDERT
  6 Bauen            AENDERT

Nur die harten Voraussetzungen liefen vorab. Verzeichnisse wurden angelegt,
bevor klar war, ob der Rest durchlaeuft - scheiterte etwas in der Mitte, blieb
ein halb eingerichteter Rechner zurueck. Und --nur-pruefen war als if-Zweig
durch FUENF Schritte gefaedelt: so etwas laeuft zwangslaeufig aus dem Ruder,
weil jede neue Aktion daran denken muesste.

JETZT zwei klar getrennte Phasen:

  Phase 1  PRUEFEN     - fuenf Pruefungen, aendert NICHTS
  Weiche               - Probleme -> Abbruch mit Liste, nichts angefasst
  Phase 2  EINRICHTEN  - Verzeichnisse, Mount, .env, bauen, starten

Es gibt damit GENAU EINEN Pruef-Pfad, den beide Modi benutzen: --nur-pruefen
heisst schlicht "nach Phase 1 aufhoeren". Die Pruefung kann nicht mehr etwas
anderes behaupten als die Installation tut.

Die Weiche unterscheidet PROBLEME (verhindern die Installation) von HINWEISEN
(halten nicht auf) und fasst am Ende beides als Liste zusammen - vorher musste
man die Ausgabe rueckwaerts lesen, um zu wissen, ob es gereicht hat.

Neu mitgeprueft, weil es jetzt an einer Stelle passt:
- Ist der Elternpfad der Verzeichnisse ueberhaupt beschreibbar? (Vorher waere
  das erst beim mkdir aufgefallen - mitten in der Aenderungsphase.)
- Freier Plattenplatz mit Schwelle 60 GB, samt Hinweis auf die Groessen
  (Blu-ray roh ~40 GB, 4K-UHD bis 100 GB).
- Ist ueberhaupt .env.example da, also stehen wir im Rippy-Repo?
- Was in die .env geschrieben WUERDE, steht jetzt in Phase 1 als Ansage.

Auf der VM gegengeprueft: aus /tmp gestartet meldet es korrekt "kein
Rippy-Repo" und bricht ab, ohne etwas anzufassen; aus dem Repo heraus laeuft
die Pruefung sauber durch ("Alles in Ordnung, keine Einschraenkungen").

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 22:42:31 +02:00
HitonabiandClaude Opus 5 35cfcbcb07 style: echte Umlaute im ganzen Projekt + Installer im Rippy-Look
Ampel / ampel (push) Successful in 27s
Commander-Rueckmeldung: Umlaute fehlen. Ausloeser war sichtbar der Installer -
"Diese Maschine uebernimmt die Video-Kompression fuer Rippy" stand woertlich im
Screenshot.

## Die .ps1-Falle war loesbar, nicht unumgehbar

Bisher galt: ausgelieferte .ps1 MUESSEN ASCII sein, weil PowerShell 5.1 sie
ohne BOM als ANSI liest. Das ist nur die halbe Wahrheit - gemessen mit echtem
powershell.exe 5.1:

    ohne BOM:  $s = "Größe: äöü"   + Unerwartetes Token -> Skript kaputt
    mit  BOM:  Groesse: aeoeue         + laeuft, Length 16 korrekt

Alle drei Skripte sind jetzt UTF-8 MIT BOM und tragen echte Umlaute; unter 5.1
gegengeprueft (BOM vorhanden, Parser fehlerfrei, Text korrekt gelesen). Der
Kopfkommentar sagt das jetzt richtig statt "ASCII-only".

## Umstellung: Text ja, Bezeichner nein

Umlaute gehoeren in Kommentare und Anzeigetexte, nicht in Funktionsnamen oder
Datenschluessel. Deshalb je Sprache das passende Werkzeug:

- Python: ueber den TOKENIZER - angefasst wurden ausschliesslich COMMENT- und
  STRING-Tokens. 156 Stellen. Code ist damit garantiert unberuehrt.
- TypeScript: nur // und /* */ Kommentare sowie JSX-Text (kann per Definition
  kein Bezeichner sein). 24 Stellen. `const waehlen`, `let laeuft`, `plaetze`,
  `GeraetInfo` sind nachweislich unversehrt.
- install.sh: Anzeigetext, aber die Shell-Funktionen (gruen/rot/gelb/titel) und
  der Schalter --nur-pruefen bleiben ASCII - das sind Schnittstellen.
- Markdown: 0 Aenderungen, die Doku hatte schon Umlaute.

ZWEI FEHLER MEINES KONVERTERS, beide von Werkzeugen gefangen:

1. In f-Strings steht in {...} CODE, kein Text. Aus f"{groesse}" wurde
   f"{größe}", waehrend die Variable groesse hiess - Ruff meldete F821
   "Undefined name". Der Konverter lagert Einsetzungen jetzt aus.
2. Ein Dict-Schluessel wurde umbenannt: die Wortliste enthaelt das PRAEFIX
   "uebersprung", der Tabu-Schutz prueft aber ganze Woerter. bericht[...] ist
   wieder ASCII - Umlaute in Datenschluesseln brechen JSON-Runden und DB-Felder.

## Installer im Rippy-Look

Statt hellgrau jetzt dieselben Toene wie das Web-UI (aus lib/design.ts
uebernommen): slate-900 Flaeche, dunkle Eingabefelder, Amber-Hauptknopf wie
"Los geht's" im Wizard. Oben ein Kopfbereich mit dem Farbverlauf
amber -> indigo -> purple und dem Disc-Symbol - in WinForms per Paint-Ereignis
gezeichnet, weil es dort keine Verlaeufe von der Stange gibt.

Geprueft, nicht gehofft: Das Fenster wurde headless in ein PNG gerendert
(DrawToBitmap) und angesehen - Verlauf, Symbol, Umlaute und Farben sitzen.
RippyWorkerSetup.exe neu gebaut (57344 -> 60416 Bytes); Umlaute und das
requireAdministrator-Manifest sind in der .exe verifiziert.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 22:37:23 +02:00
HitonabiandClaude Opus 5 65edf8369e feat(worker-windows): Installation nach "Programme", Zielordner frei waehlbar
Ampel / ampel (push) Successful in 28s
Commander-Wunsch: nicht ins Benutzerprofil, sondern wie jedes andere Programm
nach C:\Program Files - und selbst waehlbar, mit diesem Standard.

## Was neu ist

- Feld "Installieren nach" mit Knopf "Aendern ..." (Ordner-Dialog). Standard
  ist [Environment]::GetFolderPath("ProgramFiles") + "Rippy Worker" - der
  ECHTE Pfad; deutsche Windows-Versionen zeigen im Explorer "Programme", der
  Pfad heisst trotzdem "Program Files".
- Der Ordner-Dialog liefert den ELTERN-Ordner, "Rippy Worker" haengt der
  Installer selbst an. Sonst koennte die Deinstallation einen fremden Ordner
  mitloeschen - sie macht Remove-Item -Recurse auf das Zielverzeichnis.
- install.ps1 bekommt -InstallDir mit demselben Standard.

## Drei Folgen, die mitbehandelt werden mussten

1. RECHTE. In C:\Program Files darf nur ein Administrator schreiben. Die .exe
   traegt jetzt ein requireAdministrator-Manifest (-requireAdmin in
   build-exe.ps1), fragt also beim Doppelklick EINMAL per UAC - danach stimmen
   die Rechte fuer alles Weitere. Verifiziert: "requireAdministrator" steckt im
   Manifest, "asInvoker" nicht mehr. Zusaetzlich prueft der Installer VOR dem
   Entpacken, ob er dort schreiben darf, und nennt bei Nein die zwei Wege
   (als Administrator starten ODER Ziel ins eigene Profil legen) - statt
   irgendwo tief "Zugriff verweigert" zu produzieren.

2. DAS LOG. tray.py schrieb worker.log NEBEN das Programm. Unter Program Files
   darf ein normaler Benutzer das nicht - der Worker waere beim Starten
   gescheitert, und zwar still. Das Log liegt jetzt in
   %LOCALAPPDATA%\Rippy Worker\worker.log, also da, wo veraenderliche Daten
   hingehoeren. Rueckfall auf das Programmverzeichnis bleibt fuer
   Installationen ins eigene Profil.

3. DER AUTOSTART. Bei einer Installation unter Programme ist es eine
   Installation FUER DIE MASCHINE - der Autostart geht deshalb in den
   Autostart-Ordner aller Benutzer (CommonStartup). Das loest zugleich ein
   Rechte-Problem: erhoeht man ueber ein FREMDES Administratorkonto, waere
   GetFolderPath("Startup") der Ordner dieses Admins, also der falsche. Bei
   einem Ziel im eigenen Profil bleibt es persoenlich. uninstall.ps1 raeumt
   beide Orte ab.

## Geprueft

- Leerzeichen im Pfad: die erzeugte .bat mit cd /d "%~dp0", PATH-Erweiterung
  und relativem Aufruf laeuft aus "C:\...\Rippy Test Ordner" korrekt durch.
- Alle drei .ps1 ASCII-rein und fehlerfrei geparst.
- RippyWorkerSetup.exe neu gebaut (52736 -> 57344 Bytes, Version 1.0.1.0).

UI: Der Copy-Paste-Befehl fuer den CLI-Weg sagt jetzt, dass PowerShell als
Administrator laufen muss, und nennt -InstallDir als Ausweg ohne Adminrechte.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 22:20:50 +02:00
HitonabiandClaude Opus 5 8f208ed0da fix(worker-windows): Autostart brach die ganze Installation ab
Ampel / ampel (push) Successful in 28s
Beim Commander live aufgetreten: Der Installer meldete
"FEHLER: FEHLER: Zugriff verweigert" samt dem Tipp, die IP koenne falsch sein -
und das, NACHDEM Worker-Code, Abhaengigkeiten und HandBrake schon fertig waren.
Die IP war also nie das Problem.

URSACHE: schtasks /create mit /tn "RippyWorker" legt die Aufgabe im
WURZELORDNER der Aufgabenplanung an, und das verlangt Administratorrechte. Der
Installer laeuft normal ohne. schtasks schrieb "FEHLER: Zugriff verweigert."
nach stderr, und weil im Skript $ErrorActionPreference = "Stop" steht, machte
PowerShell daraus einen TERMINIERENDEN Fehler - der catch-Block riss damit die
komplette Installation ab, obwohl nur der Autostart fehlte. Das doppelte
"FEHLER: FEHLER:" war der Hinweis: der aeussere Handler setzt sein Praefix vor
eine Meldung, die selbst schon mit "FEHLER:" begann, also aus schtasks kam.

FIX, zwei Teile:

1. Autostart ueber den Autostart-ORDNER statt schtasks. Eine Verknuepfung in
   [Environment]::GetFolderPath("Startup") braucht NIE Adminrechte - und der
   Nutzer kann sie dort selbst sehen und loeschen. Auf diesem Windows-PC
   gegengeprueft: Verknuepfung angelegt (1047 Bytes) mit Admin=False.
2. Ein Fehlschlag beim Autostart ist jetzt eine WARNUNG in eigenem try/catch,
   kein Abbruch. Der Worker ist zu dem Zeitpunkt fertig und startbar, und der
   Text sagt das auch - plus den Handweg (shell:startup).

In BEIDEN Installern (install-gui.ps1 und install.ps1, dort mit -Autostart) -
der CLI-Weg hatte denselben Fehler. uninstall.ps1 raeumt jetzt die
Verknuepfung weg UND versucht weiter schtasks /delete, damit aeltere
Installationen sauber verschwinden.

RippyWorkerSetup.exe neu gebaut (50688 -> 52736 Bytes): die GUI ist in der .exe
eingebettet, ohne Rebuild wirkt der Fix beim Nutzer nicht.

Nebenbei: build-exe.ps1 hatte zwei Gedankenstriche. Ausgelieferte .ps1 muessen
reines ASCII sein (PowerShell 5.1 liest sie als ANSI) - jetzt sind alle drei
Skripte ASCII-rein und parsen fehlerfrei.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 22:11:39 +02:00
HitonabiandClaude Opus 5 b76ca5d9be docs(savepoint): install.sh und README-Umbau nachgetragen
Ampel / ampel (push) Successful in 28s
Der Block dokumentiert jetzt auch die letzte Runde: ein Befehl statt
Checkliste, README neu aufgebaut, VM-CPU-Anleitung drin.

Ehrlich als UNGETESTET markiert (neuer Punkt 6): install.sh ist nie als root
durchgelaufen. Auf dieser VM sind alle root-Schritte No-Ops - Verzeichnisse
liegen da, die Propagation ist schon shared - und sudo verlangt hier ein
Passwort. Bewiesen sind Laufwerkserkennung (SCSI-Abgleich gegen die echte
Hardware), die .env-Logik in drei Faellen und die Syntax. Das Anlegen der
Verzeichnisse, mount --make-rshared und die systemd-Unit laufen erst bei einer
echten Neuinstallation - das gehoert in die Uebergabe statt in eine
Erfolgsmeldung.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 22:01:06 +02:00
HitonabiandClaude Opus 5 ca91e5b693 feat(install): ein Befehl statt Checkliste - install.sh nimmt die Handarbeit ab
Ampel / ampel (push) Successful in 28s
Commander-Rueckmeldung: "Das Docker Deployment ist mir zu kompliziert." Zu
Recht - die Installation war eine Checkliste aus sechs Schritten, von denen
zwei nur mit Fachwissen zu schaffen waren.

## Neu: sudo ./install.sh

Nimmt genau die Schritte ab, an denen man scheitern konnte:

1. Prueft Voraussetzungen (Linux, Docker, Compose) und nennt bei jedem Mangel
   den Installationsbefehl.
2. FINDET DAS LAUFWERK SELBST. Das war der schlimmste Punkt: MakeMKV braucht
   ZWEI Geraeteknoten, und die sg-Nummer ist je Host anders. Das Skript gleicht
   sie ueber die SCSI-Adresse in /sys ab statt zu raten. Auf der VM
   gegengeprueft: sr0 -> 3:0:0:0, sg1 -> 3:0:0:0, also dasselbe Geraet -
   korrekt als /dev/sr0 + /dev/sg1 erkannt.
3. Legt Ablage- und MakeMKV-Verzeichnis an.
4. Richtet die Mount-Propagation ein UND macht sie per systemd-.mount-Unit
   neustart-fest. Vorher stand in der README nur "reboot-fest persistieren" -
   ohne zu sagen wie; nach einem Reboot scheiterte das Einhaengen von
   NAS-Freigaben aus dem UI stillschweigend.
5. Schreibt die .env, ueberschreibt aber NIE einen bestehenden Wert.
6. Baut und startet, und nennt bei Fehlschlag die drei haeufigsten Ursachen
   mit Diagnosebefehl.

Wiederholbar (mehrfach ausfuehren aendert nichts kaputt) und damit auch der
Update-Weg: git pull && sudo ./install.sh

## Zwei Fallgruben, die beim Testen auffielen - beide meine eigenen

- --nur-pruefen verlangte root und brach ab. Ein Pruef-Modus, der nichts
  aendert, darf daran nicht scheitern - sonst kann man vor der Installation
  nicht nachsehen, ob alles passt. Behoben.
- .env.example hatte OPTICAL_SG=/dev/sg1 UNKOMMENTIERT vorbelegt. Damit haette
  der Installer den erkannten Wert nicht eingetragen ("steht schon drin") und
  auf jedem fremden Host still eine kaputte Konfiguration hinterlassen - genau
  das, was er verhindern soll. Beide Geraetezeilen sind jetzt auskommentiert;
  Compose hat ohnehin Vorgaben. Dazu eine Gegenprobe im Skript: zeigt ein
  wirksamer Wert auf ein Geraet, das es hier nicht gibt (".env von einem
  anderen Rechner"), wird das benannt statt kryptisch von Docker gemeldet.

## README neu aufgebaut

Vorher 293 Zeilen, in denen der Schnellstart zwischen lsscsi, sg-Knoten,
USB-Passthrough und mount --make-rshared begraben war. Jetzt: Installation in
zwei Zeilen oben, dann eine Tabelle "Wenn etwas nicht geht" mit den vier
Faellen, die praktisch alles abdecken. Alles Technische steht darunter in
aufklappbaren Abschnitten - inklusive der Handarbeits-Variante fuer die, die
sie wollen.

NEU und ausdruecklich gewuenscht: Abschnitt "Rippy schneller machen" mit dem
VM-CPU-Typ. Erklaert, warum Virtualisierer eine generische CPU ohne AVX2
geben, was das kostet (gemessene 28-55 h je 4K-Film), die genauen Schritte in
Proxmox (herunterfahren - Hardware/Processors/Type auf 'host' - starten, bzw.
qm set <vmid> --cpu host), warum ein Neustart von innen NICHT genuegt, und wie
man nachprueft: Rippy zeigt die Vektorbefehle seit v3.14 selbst an. Dazu der
Nachteil (keine Live-Migration auf andere CPUs) und die Alternative x86-64-v3
fuer Cluster.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 21:59:23 +02:00
HitonabiandClaude Opus 5 1eb1c91dd8 docs(savepoint): v3.15 - Aufraeum-Runde mit gemessenen Zahlen
Ampel / ampel (push) Successful in 28s
Fuenf Vorgaben, was daraus wurde:

Codebase sauber   -> vier tote Routen + zwei Module weg (main.py 1726 -> 1682
                     Zeilen), Tests halten sie draussen
UI schnell        -> /capabilities 1,010 s -> 0,003 s; Dashboard-Aufbau
                     1,03 s -> 0,028 s. Alle 15 Ladeendpunkte unter 10 ms
UI selbsterklaerend -> Wizard-Kasten "Was Rippy gerade sieht" mit
                     Handlungsanweisung je Problem, sichtbare Keys mit Pruefung
Idiotensicher     -> Wizard empfiehlt nach GEMESSENER CPU statt H.265 blind;
                     4K-Falle ist damit zu
Externe Worker    -> auf Windows gegengeprueft (Kerne/Modell korrekt, encoders
                     ohne HandBrake korrekt leer, SIMD ehrlich "unbekannt")

Dazu die offene 4K-Frage aus v3.14 beantwortet: Kompression ist je Disc-Typ
abwaehlbar, 4K kann verlustfrei bleiben waehrend DVD/Blu-ray weiter schrumpfen.

ARM-Vergleich drin: fast alles, was ARM automatisch macht, macht Rippy schon -
und meist gruendlicher. Zwei echte Luecken benannt und NICHT gebaut
(ISO-Sicherung fuer Datentraeger, mehrere Laufwerke gleichzeitig), weil das
Funktionen sind und keine Reparatur. Ehrlich dabei: ob Rippy parallel rippen
kann, ist unbewiesen - mit einem Laufwerk nicht testbar.

Offene Punkte stehen unter "NOCH OFFEN", darunter der VM-CPU-Typ (qemu64 statt
host - AVX2 waere ein VM-Neustart und 2-4x schneller).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 21:51:23 +02:00
HitonabiandClaude Opus 5 6a17af2118 feat(transcode,ui): Kompression je Disc-Typ abwaehlbar + Wizard rechnet mit der CPU
Ampel / ampel (push) Successful in 28s
Loest die offene Frage aus dem Savepoint ("UHD gar nicht komprimieren?") und
nimmt dem Wizard die Falle, in die er bisher fuehrte.

## Kompression je Disc-Typ abwaehlbar

Bisher gab es nur den globalen Schalter transcodeEnabled: alles komprimieren
oder nichts. Wer 4K verlustfrei behalten und DVDs trotzdem schrumpfen wollte,
hatte keine Moeglichkeit - obwohl genau das die vernuenftige Einstellung fuer
diese Maschine ist (4K-HEVC = gemessene 28-55 h je Film ohne AVX2).

Jetzt kann das Preset eines Disc-Typs auf den Reservewert "keine" stehen, dann
bleibt die verlustfreie Datei aus dem Rip stehen. Neue reine Funktion
komprimieren_fuer(disc_type, einstellungen); der globale Schalter schlaegt
weiter alles. preset_fuer() ueberspringt den Reservewert bewusst und gibt ihn
NIE als Preset-Namen zurueck - sonst bekaeme HandBrake `--preset keine` und
wuerde scheitern. Wer ueber "Neu komprimieren" ausdruecklich doch komprimieren
will, bekommt so ein brauchbares Preset statt eines Fehlers.

Der Reservewert kollidiert mit keinem echten Namen: gegengeprueft gegen alle
90 Presets aus `HandBrakeCLI --preset-list` im Worker-Image. Bei der
Gelegenheit auch die fuenf im UI angebotenen Namen geprueft - alle echt.

## Der Wizard empfiehlt nach GEMESSENER Rechenleistung

Vorher stand H.265 als Standard drin. Auf einer CPU ohne AVX2 sind das ein bis
zwei Tage pro 4K-Film - genau der Lauf, der am 25.07.2026 abgebrochen werden
musste. Der Wizard hatte die Zahlen sogar schon vorliegen (/capabilities
meldet cpu_simd und cpu_kerne), nur benutzt hat er sie nicht.

Jetzt: schwache CPU -> 4K wird nicht komprimiert, Blu-ray/DVD gehen auf H.264
(schneller als H.265). Starke CPU oder Hardware-Encoder -> H.265 durchgehend.
Der Wizard schreibt dabei ALLE vier Preset-Felder, nicht nur das allgemeine -
vorher fiel 4K auf ein 1080p-Preset zurueck und die Aufloesung war weg.

Gewarnt wird nur, wenn es belegt ist: schwacheEncoderCpu() verlangt mindestens
einen Worker mit BEKANNTER SIMD-Stufe und keinen mit Hardware-Encoder. Ein
Windows-Worker meldet "unbekannt" (dort gibt es kein /proc/cpuinfo) - dann wird
geschwiegen statt falsch gewarnt. Auf Windows gegengeprueft: 16 Kerne und
CPU-Modell kommen korrekt durch, encoders ist ohne HandBrake leer.

## Weitere Wizard-Haerten

- Kasten "Was Rippy gerade sieht": Laufwerk, Worker (mit Kernen/SIMD), freier
  Platz. Jede Zeile hat bei Problemen eine HANDLUNGSANWEISUNG statt nur eines
  Kreuzes - kein Laufwerk, kein Worker und wenig Platz sind die drei Faelle, in
  denen man vorher ratlos dastand.
- Laedt alle drei Quellen parallel (Promise.allSettled) und wiederholt im
  5-s-Takt: beim ersten Start laeuft der Worker noch hoch, vorher stand dort
  dauerhaft "Noch kein Worker gemeldet" ohne Aussicht.
- API-Keys sind SICHTBAR statt als Punkte: das sind kopierte Keys, keine
  Passwoerter, und einen Tippfehler sieht man in Punkten nicht.
- Keys werden direkt nach dem Speichern geprueft (/metadata/status). Ein
  falsch kopierter Key faellt sofort auf, statt erst beim ersten Rip als
  "Unknown Disc" - mit der Wahl "Key korrigieren" oder "Trotzdem fertigstellen".

## Einstellungen -> Verarbeitung

Alle drei Preset-Auswahlen bekommen "Nicht komprimieren", und beim 4K-Feld
erscheint die AVX2-Warnung mit der gemessenen Zahl - aber nur, wenn die
Maschine sie wirklich braucht.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 21:48:31 +02:00
HitonabiandClaude Opus 5 11597eb00c perf+cleanup(api): /capabilities war 1,0 s; vier tote Endpunkte entfernt
Ampel / ampel (push) Successful in 28s
Beides in main.py, deshalb ein Commit.

## 1. Das "Laggen" hatte genau eine Ursache

Gemessen ueber alle 15 Endpunkte, die das UI beim Laden braucht:

    /capabilities      1,010 s
    /system/updates    0,491 s   (haengt am Knopf, nicht am Seitenaufbau)
    /metadata/status   0,412 s   (dito)
    die anderen 12   < 0,025 s

/capabilities ist der einzige langsame, der beim SEITENAUFBAU zuschlaegt - und
fuenf Stellen holen ihn (Dashboard, Einstellungen, Worker-Tab, Wizard,
Rip-Dialog). Jede Seite zahlte eine Sekunde.

Die Ursache ist kein Fehler, sondern das Wesen des Celery-Pings: er sammelt
Antworten bis zum Timeout und kann nicht frueher aufhoeren, weil er nicht
weiss, wie viele Worker noch antworten wollen. Den Timeout zu kuerzen wuerde
Antworten langsamer Remote-Worker verschlucken - also genau die Maschinen, um
die es beim externen Encoding geht.

Jetzt pingt eine Hintergrund-Schleife im 5-s-Takt (neben Disc-Watcher und
Key-Refresh, die es dort schon gibt), der Endpunkt liest nur ab. Vorrat aelter
als 30 s - Schleife noch nicht angelaufen oder gestorben - dann EINMAL synchron
pingen: lieber langsam als falsch ("alles offline", obwohl alles laeuft).

## 2. Vier tote Endpunkte raus

Jeder ein Ueberrest eines ersetzten Entwurfs, keiner mit Aufrufer (mechanisch
gegengeprueft: alle api.*-Aufrufe des UI gegen alle Routen):

  POST /prescan                  Metadaten-Vorschau-Seite ist seit v3.4 weg.
                                 Die PreScan-Klasse bleibt - sie hat 5 echte
                                 Fundstellen, der Watcher ruft sie im Prozess.
  POST /jellyfin/format          Macht seit v3.2 der Worker (medien.py), und
                                 zwar an der richtigen Stelle: er kennt den
                                 Ausgabeordner und ist nach dem Rip am Zug.
                                 Mit ihm fallen nfo_generator.py und
                                 image_downloader.py weg (sonst unbenutzt).
  GET  /stream/jobs              Der unangenehmste: erst Placebo, am 23.07.
                                 "repariert" statt entfernt - aber ein
                                 EventSource im UI gab es nie (das Dashboard
                                 nutzt setInterval(..., 4000)). Also keine
                                 harmlose Leiche, sondern eine Endlosschleife
                                 je Verbindung, die jeder aufmachen konnte.
  GET  /worker-setup/windows-gui Ohne Aufrufer seit die .exe den .bat-Umweg
                                 ersetzt hat (v3.9). install-gui.ps1 selbst
                                 lebt weiter, sie steckt in der .exe.

main.py: 1726 -> 1682 Zeilen, dazu 279 Zeilen in zwei geloeschten Modulen.

Tests halten beide Seiten fest: die vier Routen muessen WEG bleiben, und die
drei, an denen die Worker-Installation haengt (/worker-setup/paket, /windows,
/windows-exe), muessen DA sein. Ausserdem eine Doppelung entfernt - mein
eigener _sicherer_dateiname-Test aus dem Vorcommit pruefte dasselbe wie der
bestehende test_dateiname_validierung_blockt_pfad_tricks, und der war die
ganze Zeit korrekt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 21:41:48 +02:00
HitonabiandClaude Opus 5 b546c79b9e docs(savepoint): deployt und aufgeraeumt - Stand 19:30 mit Belegen
Ampel / ampel (push) Successful in 28s
Der Block behauptete "nichts ist deployt" und fuehrte Fragment wie
Rohschnitt als offene Punkte. Beides ueberholt - genau solche stehen
gebliebenen Zusagen waren das Thema dieser Sitzung.

Nachgezogen mit Belegen statt Behauptungen:
- a1aabd5 laeuft, alle 5 Container up
- GET /capabilities antwortet cpu-x264/cpu-x265/cpu-av1 - KEIN Phantom-vaapi
  mehr, dazu QEMU Virtual CPU 2.5+, 4 Kerne, sse4_2 (AVX2-Warnung greift)
- Zombie-Erkennung 19:26:09, exakt 120 s nach Start, geprueft=0
- 604 Disc-Schluessel haben den Rebuild ueberlebt
- Fragment (67.633.152 B) und der verwaiste 75-GB-Rohschnitt geloescht,
  Platte 37 GB -> 111 GB frei

Neuer Befund dabei, nicht gebaut: "Job aus der Liste entfernen" loescht
bewusst keine Dateien - richtig so, macht die Rohdaten aber unerreichbar,
weil beides nur ueber die Job-ID verbunden ist. Der Rohschnitt war danach im
UI unsichtbar und "Neu komprimieren" unmoeglich. Das UI sollte beim Loeschen
sagen, wie viel daneben liegen bleibt.

Bei den vier toten Endpunkten steht jetzt, WARUM sie tot sind (jeder ein
Ueberrest eines ersetzten Entwurfs) und dass /stream/jobs der unangenehmste
ist: keine harmlose Leiche, sondern eine Endlosschleife je Verbindung.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 21:29:56 +02:00
HitonabiandClaude Opus 5 a1aabd591d fix(test): Ampel rot - der Backslash-Test prueft nichts
Ampel / ampel (push) Successful in 28s
Meine eigene Zeile aus dem vorigen Commit. Im Quelltext stand "a\b.mkv" mit
EINEM Backslash - Python liest \b als Backspace-Zeichen, der String enthaelt
also gar keinen Backslash, und _sicherer_dateiname gab korrekt True zurueck.
Der Test behauptete, den Backslash-Pfad zu pruefen, und tat es nicht.

Jetzt ein Raw-String r"a\b.mkv".

Warum das lokal nicht auffiel: test_api_smoke.py ueberspringt sich unter
Windows selbst (main.py -> detection.py -> fcntl). Genau die Luecke, die im
Savepoint als offener Punkt steht - hier hat sie sofort zugeschlagen. Lehre:
Tests, die nur in der Ampel laufen, sind erst nach dem Push bewiesen, und
Backslashes gehoeren in Raw-Strings.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 21:12:39 +02:00
HitonabiandClaude Opus 5 8394de6926 fix(transcode): "Abbrechen" wirkt sofort statt erst beim naechsten Prozent
Ampel / ampel (push) Failing after 28s
Fund des Commanders am laufenden Akira-Job (Nachtrag im vorigen Savepoint):
Job stand auf 'canceling', HandBrake lief weiter. Gemessen 3,4 Minuten
zwischen Anforderung (18:30:17) und Bestaetigung (18:33:38) - bei langsamerem
Fortschritt entsprechend mehr.

Ursache genau wie dort beschrieben: Der Abbruch wurde nur in
datei_fortschritt geprueft, und diese Closure stieg oben sofort wieder aus,
wenn sich die Prozentzahl nicht geaendert hatte ("if gesamt == letzter[0]:
return"). Bei einem Prozent je halber Stunde hing der Abbruch also an einem
Ereignis, das eine halbe Stunde lang nicht eintrat.

run_handbrake bekommt jetzt einen eigenen abbruch_cb neben progress_cb -
dasselbe Muster, das run_makemkv schon fuer log_cb benutzt, und aus
demselben Grund: der Fortschritts-Kanal verwirft Aufrufe. Er wird bei JEDER
Ausgabezeile aufgerufen und im Worker auf 5 s gedrosselt.

Nebeneffekt, der genauso wichtig ist: Er greift auch waehrend des
Scan-Durchlaufs, der ueberhaupt keine Encode-Prozente liefert. Dort war ein
Abbruch vorher grundsaetzlich unmoeglich - und seit die Prozent-Regex den
Scan korrekt ignoriert, waere das sonst sogar schlimmer geworden.

Die Leseschleife ist als _handbrake_schleife() herausgezogen, damit die
Reihenfolge (Abbruch VOR Fortschritt) ohne echtes HandBrake pruefbar ist.
Der Test belegt: zwei Scan-Zeilen genuegen fuer den Abbruch, es muss NICHT
auf eine Encode-Zeile gewartet werden.

Savepoint nachgezogen: Der Encode laeuft nicht mehr, ein Deploy ist
gefahrlos moeglich, und die alte "SOFORT ENTSCHEIDEN"-Passage (Platte
laeuft voll, wenn der Job fertig wird) ist damit gegenstandslos. Neu darin:
die drei Wege fuer UHD, und die Warnung, dass eine /proc-Suche nach
"HandBrake" die eigene Shell mittrifft - zwei Fehlalarme in dieser Sitzung.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 21:10:03 +02:00
HitonabiandClaude Opus 5 574354131c docs(savepoint): v3.14 - Durchsicht, mit den zwei eigenen Fehlschluessen
SAVEPOINT bekommt den Stand v3.14: der unwirksame Platten-Schutz zuerst
(wichtigster Fund), dann die gemessenen Werte, das Gebaute, die vier toten
Endpunkte als Entscheidungsvorlage - und ein Abschnitt "SOFORT ENTSCHEIDEN".

Der laufende Akira-Encode wird beim Fertigwerden mit dem DEPLOYTEN, alten
Code versuchen, 75 GB in 37 GB zu kopieren. keepOriginal steht auf true, und
den Wert hat die Aufgabe beim Start gelesen - jetzt umstellen aendert daran
nichts mehr. Der Savepoint nennt die drei Optionen mit Empfehlung.

Zwei Richtigstellungen an v3.13, beide durch Messung:
- "progress=99 ist ein Altwert aus dem Absturz" war falsch. Beide Startpfade
  setzen auf 0; der Wert kam frisch vom Scan-Durchlauf. Ein Bug, kein Ueberrest.
- Die Erwartung, _original_aufheben werde nur warnen, war falsch - siehe
  EXDEV-Fund im vorigen Commit.

Ehrlich als OFFEN markiert: Was die Platte am 25.07. mittags fuellte, ist
NICHT belegt. Es gibt keine Kopier-Reste, kein original-Verzeichnis und
keinen einzigen Log-Eintrag von _original_aufheben, das in beiden Zweigen
loggt. Der Mechanismus ist jetzt bewiesen, sein Zuschlagen an jenem Tag
nicht. Lieber offen lassen als eine dritte Vermutung aufstellen.

AGENTS bekommt Etappe 19 und einen neuen Abschnitt, der das wiederkehrende
Muster benennt: nicht aus einem Zustandswert auf einen Mechanismus
schliessen - vier belegte Faelle. Plus die Umkehrung, die diese Sitzung
gekostet hat: gleiches st_dev heisst NICHT gleicher Mount. Was ausprobierbar
ist, wird ausprobiert statt vorhergesagt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 21:05:38 +02:00
HitonabiandClaude Opus 5 ef0a574a70 fix(worker,api): Platten-Schutz griff nicht, Fortschritt log, Auswurf tat nichts
Vier Funde aus der Durchsicht, alle auf der VM gemessen.

1. DER PLATTEN-SCHUTZ AUS c065967 WAR WIRKUNGSLOS

_original_aufheben() entschied per os.stat().st_dev, ob umgehaengt oder
kopiert werden muss. Im Worker-Container gemessen - beides gleichzeitig wahr:

    st_dev /app/temp  = 2050
    st_dev /app/media = 2050        → identisch
    os.rename(...)    → EXDEV, "Invalid cross-device link"

Der Kernel vergleicht bei rename() den MOUNT, nicht das Geraet. /app/temp
(Docker-Volume) und /app/media (Bind-Mount) sind zwei Mounts DERSELBEN
ext4-Partition. Die Pruefung sah "gleiches Dateisystem", uebersprang die
Platzpruefung, und shutil.move kopierte doch - 75 GB bei 37 GB frei. Der
Schutz haette genau den Schaden zugelassen, gegen den er gebaut wurde.

Jetzt wird os.rename VERSUCHT statt vorhergesagt: klappt es, ist es
umgehaengt und fertig; kommt EXDEV, steht die Kopie fest und ERST DANN wird
der Platz geprueft. Das ist keine Vermutung mehr, sondern die Antwort des
Kernels. Vier Tests in test_original_aufheben.py, darunter genau der Fall,
der die Platte fuellte. Die zwei alten Tests in test_medien.py sind dorthin
gewandert - sie taeuschten per gefaelschtem os.stat "verschiedene
Dateisysteme" vor, also genau die Annahme, an der der Schutz scheiterte.

2. DIE FORTSCHRITTSANZEIGE ZEIGTE DEN SCAN, NICHT DEN ENCODE

get_progress_from_line matchte jede Zahl vor einem Prozentzeichen. HandBrake
gibt Prozente aber in drei Phasen aus (Formatstrings aus dem Binary gelesen):

    Scanning title %d of %d, preview %d, %.2f %%          → laeuft VOR dem
                                                            Encode bis 100 %
    Encoding: task %d of %d, %.2f %%       (%.2f fps, avg  → der echte Wert
    Encoding: task %d of %d, Searching for start time, ... → Vorlauf

Dazu warf `if progress > 0` im Aufrufer jeden Wert unter 1,00 % weg. Live
beobachtet: Anzeige stand auf 99 %, der Encode bei 1,06 %; sie fiel erst auf
1, als der Encode die 1-%-Marke ueberschritt. Jetzt wird nur die
Encoding-Zeile gelesen, `task N of M` mitgerechnet (sonst springt die
Anzeige bei Zwei-Pass-Presets mitten in der Datei zurueck), und -1 heisst
"keine Angabe" - dasselbe Muster wie bei get_progress_from_prgv.

3. "AUTOMATISCHER AUSWURF" WURDE VON NIEMANDEM GELESEN

Die Einstellung (Standard: ein, "Disc nach erfolgreichem Ripping automatisch
auswerfen") kam in keiner Zeile Backend-Code vor. DVD/Blu-ray warfen deshalb
NIE aus, Audio-CDs IMMER, weil abcde `-x` fest verdrahtet bekam. Jetzt
entscheidet die Einstellung beides: wirf_disc_aus() per CDROMEJECT-ioctl
(fcntl-guarded, der native Windows-Worker laedt das Modul auch) und `-x` nur
noch, wenn gewuenscht.

4. PFAD-PRUEFUNG FIEL AUF PRAEFIX-NAMEN HEREIN

Elf Stellen prueften mit nacktem startswith(MEDIA_ROOT). "/app/media-boese/x"
beginnt mit "/app/media", liegt aber ausserhalb - betroffen waren auch
/browse und /browse/mkdir, wo der Pfad vom Nutzer kommt. Neuer
Zwillings-Helfer unter_wurzel() in api/main.py und worker/tasks.py, alle elf
Stellen umgestellt, Tests in beiden.

Nebenbefund: _zielbasis() benutzte os.path.normpath - unter Windows werden
daraus Backslashes, die MEDIA_ROOT-Pruefung greift nicht mehr, und das
gewaehlte Ziel faellt still auf den Standard zurueck. Genau die Falle, die
_arbeitsverzeichnis() drei Zeilen weiter dokumentiert und mit posixpath
vermeidet. Live war es nie (nur aus rip_disc, das auf Windows verriegelt
ist), jetzt konsistent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 21:05:11 +02:00
HitonabiandClaude Opus 5 883c1c290b fix(caps,ui): Encoder werden gemessen statt behauptet
Der Modulkopf von caps.py verspricht "ehrlich erkannt, nicht behauptet" -
erkenne_encoder() tat aber drei Mal das Gegenteil:

1. cpu-x264 und cpu-x265 standen fest verdrahtet in der Liste ("immer
   dabei"). Ein Rip-Worker OHNE HandBrake behauptete damit, komprimieren zu
   koennen; jeder Transcode dort endete sofort mit "nicht installiert".
2. 'vaapi' wurde allein wegen /dev/dri gemeldet, ohne zu pruefen, ob
   HandBrake das ueberhaupt kann. Auf der VM gemessen: das Worker-Image
   kennt svt_av1/x264/x265/mpeg4/mpeg2/VP8/VP9/theora und KEINEN einzigen
   Hardware-Encoder. Rippy haette VAAPI versprochen und dann versagt.
3. Ueber die Rechenleistung sagte es gar nichts. Genau deshalb war nicht zu
   sehen, dass ein 4K-Encode auf dieser Maschine Tage braucht: CPU-Modell
   ist das generische "QEMU Virtual CPU version 2.5+", grep -c avx2
   /proc/cpuinfo = 0, nur bis sse4_2. x265 lebt von AVX2. Gemessen an der
   Leseposition des Quellstroms: 28-55 h fuer einen Film, 3,84 von 4 Kernen
   gesaettigt. Abhilfe waere der CPU-Typ 'host' in Proxmox.

Jetzt wird die Encoder-Liste aus `HandBrakeCLI --help` geparst (Abschnitt
-e/--encoder, Formatstrings im Worker-Image gemessen - AGENTS Regel D), und
Hardware zaehlt nur, wenn Geraet UND HandBrake-Unterstuetzung da sind. Neu
gemeldet: cpu-av1 (svt_av1 ist wirklich verfuegbar) sowie CPU-Modell,
Kernzahl und Vektorbefehlsstufe je Worker.

UI: Kerne/Vektorbefehle stehen bei jedem Worker (Worker-Tab und
Einstellungen -> System), dazu die ungefilterte HandBrake-Auskunft und eine
sichtbare Warnung, wenn AVX2 fehlt - inklusive des Hinweises auf den
VM-CPU-Typ. Der Warntext liegt in lib/encoder.ts, damit er nicht doppelt
im Code steht.

Mit im gleichen Zug (dieselbe Datei): der Schalter "Alle Tracks rippen" ist
entfallen. Er war ein Placebo - abcde bekommt keine Track-Auswahl und es gab
auch keine Oberflaeche, um eine Teilmenge zu waehlen. Eine Audio-CD wurde
also immer vollstaendig gerippt, egal wie der Schalter stand. An seiner
Stelle steht jetzt die Wahrheit.

7 Tests, Testdaten sind echte HandBrake-Ausgaben von der VM. Der Parser ist
zusaetzlich gegen die vollen 697 Zeilen der echten --help gegengeprueft.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 21:04:42 +02:00
HitonabiandClaude Opus 5 e0cb7b3ddc feat(worker): Zombie-Erkennung - Jobs, an denen niemand arbeitet
Nach einem Absturz oder Rebuild blieb ein Job auf 'transcoding' stehen,
obwohl weder ein Prozess lief noch etwas in den Queues stand. Folge: keine
Anzeige, kein Download - und der Knopf "Neu komprimieren" fehlte, weil
_kann_neu_komprimieren (api/main.py) status=='failed' verlangt. Der Job war
unerreichbar, obwohl die Rohdateien vollstaendig dalagen.

zombies.py haelt beim Worker-Start die Jobs in 'ripping'/'transcoding'/
'canceling' gegen Celerys active/reserved/scheduled und setzt sie ehrlich
auf 'failed', wenn niemand daran arbeitet.

Drei Sicherungen, weil ein falsch getoeteter Job teurer ist als eine
stehengebliebene Leiche:
- nur beim Start (da ist "es lief nichts" eindeutig; ein periodischer Lauf
  koennte einen Job erwischen, der legitim in der Warteschlange wartet)
- 120 s Gnadenfrist (Celery stellt unbestaetigte Aufgaben erneut zu)
- Vollzaehligkeit: antworten weniger Knoten als laut Herzschlag online sind,
  wird NICHTS gewertet - sonst waere der laufende Job eines beschaeftigten
  Remote-Workers eine falsche Leiche

Die Job-ID wird per Textsuche ueber die Inspektions-Antwort gefunden, nicht
per Position: sie steht bei rip_disc an zweiter, bei transcode_files an
erster Stelle, und Celery liefert args je nach Version als Liste oder Text.

13 Tests ohne Postgres/Redis, darunter "laufender Job wird nicht angetastet"
und "schweigender Worker verhindert jedes Urteil".

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 21:04:19 +02:00
HitonabiandClaude Opus 5 5cd1876c90 docs(savepoint): Nachtrag - 4K-Transcode abgebrochen, zwei neue Befunde
Ampel / ampel (push) Successful in 48s
Der im Uebergabestand als "laeuft" beschriebene 4K-Lauf wurde um 18:31 vom
Commander abgebrochen. Damit war die Aussage im Block darueber ueberholt -
nachgezogen, statt sie stehen zu lassen.

Zwei Befunde, beide gemessen:

1. 4K-HEVC ist auf dieser CPU nicht machbar: 18:02 bis 18:31 ergab 1 Prozent,
   hochgerechnet rund 50 Stunden fuer den Film. Zu entscheiden: UHD gar nicht
   komprimieren (Roh-MKV behalten), Hardware-Encoder (Remote-Worker mit GPU),
   oder bewusst bei 1080p bleiben. Preset-je-Disc-Typ ist richtig, reicht
   allein aber nicht.

2. Abbruch wirkt verzoegert (FEHLER, nicht behoben): Job steht seit 18:31 auf
   "canceling", HandBrake lief um 18:35 immer noch. Der Abbruch wird nur in
   datei_fortschritt geprueft, und die Closure laeuft nur bei geaenderter
   Prozentzahl ("if gesamt == letzter[0]: return"). Bei 1 Prozent alle 30
   Minuten sieht "Abbrechen" bis zu eine halbe Stunde lang wirkungslos aus.
   Der Abbruch gehoert unabhaengig vom Fortschritt geprueft.

Ausserdem festgehalten: die 1080p-Fassung wurde von HandBrake beim Start auf
0 Bytes gekuerzt, im Akira-Ordner liegt derzeit ein unbrauchbares Fragment.
Der 75-GB-Rohschnitt ist unversehrt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 20:32:34 +02:00
HitonabiandClaude Opus 5 b526a0a033 docs(savepoint): Uebergabestand v3.13 - gemessen vs. vermutet getrennt
Ampel / ampel (push) Successful in 46s
Uebergabe an eine neue Sitzung. Der Block trennt bewusst, was per Befehl auf
der VM geprueft wurde, von dem was offen bzw. nur erwartet ist - inklusive
zweier Fehlschluesse dieser Sitzung, damit die naechste Sitzung weiss, welchen
Aussagen sie nicht blind glauben soll.

Kern:
- Ein 4K-HandBrake-Lauf laeuft GERADE (Akira, Preset "H.265 MKV 2160p60 4K").
  Die vorherige 1080p-Datei wurde dabei auf 0 Bytes gekuerzt; der 75-GB-
  Rohschnitt liegt unversehrt in /app/temp/raw.
- progress=99 am Job ist ein Altwert aus dem Absturz, NICHT der echte Stand.
- Noch nicht bewiesen: dass _original_aufheben() im Ernstfall nur warnt statt
  die Platte vollzuschreiben. Genau dieser Pfad ist neu.
- Gefunden, nicht gebaut: Zombie-Erkennung. Nach dem Absturz stand der Job auf
  "transcoding", obwohl kein Prozess lief und beide Celery-Queues leer waren.
  _kann_neu_komprimieren verlangt status == "failed", deshalb fehlt dem Nutzer
  auch der "Neu komprimieren"-Knopf.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 20:08:51 +02:00
HitonabiandClaude Opus 5 8bb075c656 feat(rip): Arbeitsverzeichnis je Rip waehlbar statt global vorgegeben
Ampel / ampel (push) Successful in 28s
Commander-Vorgabe 25.07.2026: "Du sollst es nicht automatisch setzen, es soll
auswaehlbar sein - z. B. beim Rippen starten, oder VORHER wenn Vollautomatik
eingeschaltet ist."

Bisher gab es nur die globale Einstellung workDir, und die war ein freies
Textfeld - man musste den Container-Pfad (/app/media/...) kennen. Beim
Akira-Rip landeten deshalb 74 GB Rohdaten auf der 148-GB-VM-Platte, obwohl
eine NAS-Freigabe mit 2,3 TB eingehaengt war.

- RipTargetModal: neue Auswahl "Arbeitsverzeichnis fuer die Rohdaten",
  gespeist aus /storage-targets (mit Kennzeichnung als Netzwerk-Freigabe und
  freiem Platz je Ziel). Leer = "Standard aus den Einstellungen", der Wert
  wird zur Orientierung mit angezeigt. Bei Musik ausgeblendet - CD-Rips gehen
  direkt als FLAC ins Ziel, ohne Roh-Zwischenstufe.
- POST /jobs nimmt work_dir entgegen, mit derselben Pfad-Haerte wie das Ziel
  (_validiere_ziel: muss unter /app/media liegen), und legt es in die
  Job-Metadaten.
- _arbeitsverzeichnis(einstellungen, job_wahl) im Worker: Wahl dieses Rips ->
  Setting -> Container-Default. Damit bleibt die Einstellung genau das, was
  bei Vollautomatik-Rips greift, weil dort niemand gefragt wird. Der Text im
  Einstellungen-Tab sagt das jetzt auch so.
- posixpath statt os.path in _arbeitsverzeichnis: das sind immer
  Container-Pfade, auch wenn ein nativer Windows-Worker das Modul laedt (der
  uebersetzt erst spaeter per pfad_lokal). os.path.normpath machte unter
  Windows Backslashes daraus, wodurch die MEDIA_ROOT-Pruefung nicht mehr
  griff - lokal als Testfehler aufgefallen.
- Test deckt die Reihenfolge und die Ausbruchsversuche ab.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 19:59:37 +02:00
HitonabiandClaude Opus 5 c065967f4d fix(ui,transcode): Dialog-Falle, Arbeitsverzeichnis waehlbar, Original-Aufheben entschaerft
Ampel / ampel (push) Successful in 28s
Drei Befunde aus dem ersten echten UHD-Durchlauf (Akira). Der Rip und die
Kompression liefen sauber durch - danach hat "Original behalten" die Platte
vollgeschrieben und den fertigen Job als fehlgeschlagen markiert.

1. ORIGINAL-AUFHEBEN DARF DEN JOB NICHT MEHR TOETEN (tasks.py)
   Vorher stand dort ein nacktes shutil.move(raw_dir, ziel). Arbeits-
   verzeichnis (/app/temp, Docker-Volume) und Ziel (/app/media, Bind-Mount)
   sind VERSCHIEDENE Dateisysteme - os.rename scheitert mit EXDEV, shutil.move
   faellt auf Kopieren zurueck. Ergebnis am 25.07.: 74-GB-Vollkopie auf
   dieselbe Platte, Abbruch bei 41 GB mit ENOSPC, Platte 100 % voll, Worker-
   Container startete nicht mehr ("failed to mount: no space left on device"),
   und der Job galt als FEHLGESCHLAGEN - obwohl die komprimierte Datei
   (4,8 GB) fertig und in Ordnung war. Der Nutzer sah nur eine leere Queue.
   Jetzt: _original_aufheben() prueft erst, ob ueberhaupt kopiert werden muss
   (gleiches Dateisystem -> reines Umhaengen), prueft sonst den freien Platz
   VORHER, faengt jeden OSError ab, raeumt eine halbe Kopie weg und meldet das
   als WARNUNG. Der Job bleibt erfolgreich, die Roh-Datei bleibt liegen.
   Zwei Tests decken beide Wege ab.

2. ARBEITSVERZEICHNIS IST JETZT WAEHLBAR (Settings.tsx)
   Es war ein freies Textfeld - man musste den Container-Pfad (/app/media/...)
   KENNEN, um eine Netzwerk-Freigabe zu treffen. Genau daran ist es
   gescheitert, weshalb der 74-GB-Rohschnitt ueberhaupt erst auf der VM-Platte
   landete. Jetzt eine Auswahl aus /storage-targets (dieselbe Liste wie bei
   den Speicherzielen), inklusive Kennzeichnung als Netzwerk-Freigabe und
   freiem Platz je Ziel.

3. DIALOGE KLEBTEN IM PANEL (ui/Modal.tsx)
   "Rippen starten" im Laufwerke-Tab oeffnete den Dialog INNERHALB des
   Bereichs, teils abgeschnitten. Ursache: .glass-panel in index.css setzt
   backdrop-filter: blur(16px), und ein Element mit backdrop-filter wird zum
   Bezugsrahmen fuer position: fixed seiner Nachfahren - das Modal war damit
   an der Card ausgerichtet statt am Fenster. Modal rendert jetzt per
   createPortal an document.body. Behebt es fuer ALLE Dialoge auf einmal.

Aufgeraeumt: die abgebrochene 41-GB-Teilkopie unter
"/app/media/movies/Akira (1988)/original/" geloescht (nachweislich
unvollstaendig - 41 GB gegen 79,6 GB Quelle, Quelle intakt). Platte wieder
bei 78 %, Container laufen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 19:48:10 +02:00
HitonabiandClaude Opus 5 e84afc1718 feat(transcode): ein HandBrake-Preset je Disc-Typ statt eines fuer alles
Ampel / ampel (push) Successful in 29s
Rueckfrage des Commanders beim ersten echten UHD-Rip: "merkt Rippy, dass es
eine UHD ist, und nimmt direkt das 4K-Preset?" Antwort war nein. Die
Kompression fragte den Disc-Typ ueberhaupt nicht:

    preset = einstellungen.get("transcodePreset") or DEFAULT_HB_PRESET

Live eingestellt war "HQ 1080p30 Surround". Der gerade laufende Akira-Rip
waere also verlustfrei in 4K gerippt und danach auf 1080p heruntergerechnet
worden - und mit keepOriginal=False waere der 4K-Rohschnitt danach geloescht
worden. Umgekehrt wurde eine DVD auf 1080p hochskaliert, was nichts bringt.

- preset_fuer(disc_type, einstellungen) in ripping.py, pure und getestet.
  Reihenfolge: Preset des Disc-Typs -> allgemeines transcodePreset ->
  DEFAULT_HB_PRESET. Bestandsinstallationen aendern ihr Verhalten NICHT,
  solange die neuen Felder nicht gespeichert sind.
- Drei Einstellungen: transcodePresetDvd / transcodePresetBluray /
  transcodePresetUhd. transcodePreset bleibt als Rueckfall bestehen.
- transcode_files holt den Disc-Typ aus dem Job-Datensatz und schreibt ihn
  mit ins Log ("Disc-Typ 'uhd', Preset '...'").
- UI: drei Auswahlfelder statt einem, mit Klartext dazu, warum eine 4K-UHD
  auf ein 2160p-Preset gehoert.

Preset-Namen stammen aus "HandBrakeCLI --preset-list" im Worker-Image
(HandBrake 1.6.1) - nicht aus dem Kopf (AGENTS Regel D):
H.265 MKV 2160p60 4K, HQ 2160p60 4K HEVC Surround,
Super HQ 2160p60 4K HEVC Surround, H.265 MKV 1080p30, HQ 1080p30 Surround,
Super HQ 1080p30 Surround, H.265 MKV 576p25, H.265 MKV 480p30,
HQ 576p25 Surround.

Sofortmassnahme am laufenden Job (auf Ansage des Commanders): keepOriginal
auf True gesetzt - nur dieses eine Feld, gegengeprueft dass kein anderer
Schluessel veraendert wurde. Damit ueberlebt der 4K-Rohschnitt die
Kompression.

ACHTUNG - Deploy bewusst NICHT ausgefuehrt: docker compose up -d --build
wuerde den Worker-Container neu erstellen und den laufenden Akira-Rip
abbrechen. Erst nach Abschluss des Jobs deployen.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 11:38:52 +02:00
HitonabiandClaude Opus 5 f449c4ee34 fix(uhd): 4K-UHD geloest - makemkvcon holt Schluessel unter Linux nie
Ampel / ampel (push) Successful in 28s
Richtigstellung des Vortags-Befunds. Dort stand, MakeMKVs Schluessel-Kanal
sei abgeschaltet. Das war FALSCH: die Herleitung stuetzte sich auf zwei
Hostnamen aus alten Forumsbeitraegen (hkdata.fairuse.org,
hkdata.crabdance.com), die zwar wirklich nicht mehr aufloesen, von MakeMKV
aber laengst nicht mehr benutzt werden. Aufgedeckt durch den Einwand des
Commanders, unter Windows ginge es sofort.

Gegenprobe mit demselben Laufwerk und derselben Disc (Akira UHD, MKB v76):

                        Linux (Worker)      Windows
  Verbindungen          KEINE EINZIGE       185.84.108.20:443
  Meldung 3338          nie                 "Downloading latest HK"
  _private_data.tar     2048 B, 0 Keys      6,4 MB, 604 Keys
  Disc                  volume key unknown  TCOUNT:5, geht auf

Gegengeprueft mit leerem UND gefuelltem Speicher, mit und ohne --noscan,
mit dev:/dev/sr0 und disc:0, mit geloeschter update.conf. Linux fragt nie.
Die Meldungsvorlage "Downloading latest %1 to %2 ..." steckt sehr wohl im
Linux-Binary - sie loest nur nicht aus. Gleiches Symptom im MakeMKV-Forum,
seit Jahren offen (t=25782, t=34022). Der Dienst lebt; der Worker erreicht
185.84.108.20:443 sogar problemlos.

BEWIESEN: Nach Uebernahme des Windows-Schluesselspeichers oeffnet
makemkvcon auf der VM die Akira-UHD - "Operation successfully completed",
TCOUNT:5, fuenf Titel, identisch zum Windows-Ergebnis. Erster belegter
UHD-Disc-Zugriff auf der Rippy-Maschine.

- makemkv_daten.py (beide Zwillinge): zaehle_schluessel,
  private_data_pruefen, schluesselspeicher_status, private_data_schreiben.
  Die Pruefung lehnt einen Speicher OHNE hkd_*.bin ab - sonst laedt jemand
  den leeren Vorrat einer frischen Installation hoch, nichts aendert sich,
  und niemand versteht warum. Modulkopf komplett neu, inkl. der
  Fehldiagnose als Warnung fuer spaeter.
- API: GET/POST /system/keystore. Der Rohkoerper der Anfrage IST die Datei
  (binaer - JSON/Base64 waere Ballast, Multipart kann die API nicht).
  Groessengrenze 64 MB = client_max_body_size in nginx.conf.
- UI: neuer Block "Disc-Schluessel fuer 4K-UHD" UEBER dem KEYDB-Block, mit
  Schluessel-Anzahl, Upload und Anleitung fuer den Windows-Weg. KEYDB.cfg
  ist jetzt als Notnagel beschriftet. Worker-Plakette zeigt die Anzahl;
  0 heisst sichtbar "4K-UHD scheitert".
- tasks.py: UHD-Fehlertext sagt den Windows-Weg an und nennt die Anzahl
  bekannter Schluessel dieses Workers.
- caps.py meldet schluessel je Worker.
- Alle Falschaussagen korrigiert: UI (3), Anleitung (2), README (3),
  KONZEPT §8 + §10, Worker-Dockerfile, makemkv_key.py (dort stand "Den
  AACS-Schluessel zieht MakeMKV via LibreDrive ohnehin selbst aus dem
  Laufwerk" - gilt fuer Blu-ray, NICHT fuer UHD).
- SAVEPOINT v3.11, ROADMAP Etappe 18 (Etappe 17 mit Nachtrag), AGENTS.

Offen: voller UHD-Rip inkl. Transcode-E2E; und ob sich der Abruf unter
Linux doch anstossen laesst.

Quellen (AGENTS Regel D):
- Linux laedt keine Hashed Keys, gleiches Symptom:
  https://forum.makemkv.com/forum/viewtopic.php?t=25782
  https://forum.makemkv.com/forum/viewtopic.php?t=34022
- Schluessel als hkd_*.bin in _private_data.tar:
  https://forum.makemkv.com/forum/viewtopic.php?t=32675
- Meldungsformat: https://www.makemkv.com/developers/usage.txt

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 11:18:09 +02:00
HitonabiandClaude Opus 5 0935766f61 feat(uhd): KEYDB.cfg-Unterstuetzung - MakeMKVs Schluessel-Kanal liefert nichts mehr
Ampel / ampel (push) Successful in 28s
4K-UHD scheiterte an "The volume key is unknown for this disc". Am 25.07.2026
im Worker-Container nachgemessen: Laufwerk und MakeMKV sind in Ordnung
(LibreDrive v06.3 / Meldung 1011, Disc wird gelesen, AACS-Dump geschrieben) -
MakeMKV versucht gar nicht erst, online einen Schluessel zu holen. Belege:
_private_data.tar enthaelt nur die Index-Datei und KEINE hkd_*.bin; auch mit
geloeschter update.conf (Meldung 5074 belegt den Web-Kontakt) und mit
app_UpdateEnable="1" kam keiner; hkdata.fairuse.org und hkdata.crabdance.com
loesen weltweit nicht mehr auf (NXDOMAIN gegen Fritz!Box, 8.8.8.8, 1.1.1.1).
Betroffen war Akira UHD (MKB v76, Pressung Dez. 2020) - also gerade KEINE
Neuerscheinung. Der bisherige Fehlertext ("Disc neuer als die
Schluessel-Datenbank, mit einem der naechsten Updates rippbar") war falsch.

Einziger heute funktionierender Weg ist eine vom Nutzer selbst mitgebrachte
KEYDB.cfg. Rippy liefert KEINE Schluessel mit, laedt keine herunter und
verteilt keine - es stellt nur den Platz bereit und zeigt an, was dort liegt.

- Datenverzeichnis persistent gemountet (MAKEMKV_DATA_HOST, Default
  /srv/rippy/makemkv): KEYDB.cfg und AACS-Dumps ueberleben jeden Rebuild.
  Vorher loeschte jeder "up -d --build" beides - inklusive des Dumps, auf den
  die Fehlermeldung selbst verwies.
- entrypoint.sh und tasks.py schreiben settings.conf ergaenzend statt
  zerstoerend. Der entrypoint bricht bei nicht beschreibbarem Verzeichnis
  nicht mehr ab - mit "restart: unless-stopped" waere das ein Crashloop
  gewesen, in dem auch reines DVD-Rippen tot ist.
- Neues Zwillings-Modul makemkv_daten.py (docker/api + docker/worker,
  byteweise identisch; test_zwillinge_sind_byteweise_identisch wacht darueber
  und wurde durch absichtliches Verstellen als wirksam nachgewiesen).
- API: GET/POST/DELETE /system/keydb, GET /system/aacs-dumps(/{dateiname}).
  JSON-Body statt Multipart - python-multipart ist bewusst nicht installiert
  und wuerde die API beim Import toeten. nginx client_max_body_size 64m,
  sonst scheitert der Upload mit 413, bevor die API ihn sieht.
- UI (Einstellungen -> System): Status, Hochladen per Datei-Dialog, Entfernen,
  Dump-Download, KEYDB-Plakette je Worker (nur wo das Verzeichnis wirklich
  gemountet ist - ein Remote-Transcode-Worker truege sonst eine Warnung,
  die ihn nichts angeht).
- parse_msg() + log_cb: MakeMKV-Meldungen landen im Rippy-Log (gedrosselt:
  Code 1003 raus, keine Wiederholungen, max. 40 je Rip). Nebenbei behoben:
  der alte Parser (split(",", 4)[3]) schnitt jede Meldung am ersten Komma ab.
- Fuenf Stellen richtiggestellt, die behaupteten, MakeMKV-Updates braechten
  die neueste Disc-Schluessel-Datenbank mit (UI, Anleitung, README,
  Worker-Dockerfile, makemkv_key.py).

NICHT bewiesen: ein erfolgreicher UHD-Rip - es lag keine KEYDB.cfg mit dem
Akira-Schluessel vor. Belegt sind der Befund und die neue Mechanik. So steht
es auch im SAVEPOINT und in der ROADMAP.

Quellen (AGENTS Regel D):
- Datenverzeichnis + Dateiname GROSS/case-sensitiv:
  https://forum.makemkv.com/forum/viewtopic.php?t=30636
- hkd_*.bin in _private_data.tar:
  https://forum.makemkv.com/forum/viewtopic.php?t=32675
- headless settings.conf / app_UpdateEnable:
  https://forum.makemkv.com/forum/viewtopic.php?t=20364
- KEYDB.cfg-Zeilenformat (libaacs):
  https://github.com/ShiftMediaProject/libaacs/blob/master/KEYDB.cfg
- MSG-/PRGV-Format: https://www.makemkv.com/developers/usage.txt

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-07-25 01:26:08 +02:00
HitonabiandClaude Opus 4.8 f74f4e54f6 fix(api): Job-Meta (poster_path) an die Jobliste durchreichen
Ampel / ampel (push) Successful in 32s
GET /jobs nutzt response_model=List[Job]; das Job-Model hatte kein meta-Feld,
also schnitt FastAPI die Disc-Metadaten (poster_path) weg -> Dashboard.tsx
bekam job.meta = undefined -> Filmstreifen-Platzhalter statt TMDB-Poster,
sowohl in der Jobliste als auch im aktiven Rip-Header (beide aus /jobs).

Additiv: meta: Optional[Dict] ins Job-Model + in _job_row_to_model parsen
(json.loads wie im Detail-Endpunkt, defensiv gegen kaputtes JSON). Keine
UI-Aenderung noetig -- posterUrl() rendert dann die vorhandenen Poster.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-25 00:03:41 +02:00
HitonabiandClaude Opus 4.8 0832ef777c chore(handoff): portabel machen + Doku/Onboarding glaetten (Review-Umsetzung)
Ampel / ampel (push) Successful in 27s
Aus dem Weitergabe-Review. Kein Verhaltenswechsel fuer den Ursprungs-Host
(alle Defaults = bisheriges Verhalten):

Portabilitaet:
- Laufwerk-Geraeteknoten via .env parametrisiert (OPTICAL_SR/OPTICAL_SG,
  Defaults sr0/sg1) - der #1-Blocker: auf Fremdhosts liegt das sg-Node woanders.
- deploy.sh generisch (RIPPY_VM/RIPPY_REPO_URL/... aus der Umgebung) - keine
  festen Besitzer-Adressen (interne IP + DDNS) mehr im Repo.
- POSTGRES_PASSWORD in compose durchverdrahtet (Default rippy) - war No-op.

Aufraeumen (toter/irrefuehrender Code):
- udev/ entfernt (fehlende Regeldatei, falscher Container-Name; durch ioctl-
  Polling ersetzt - reine Altlast).
- docker/postgres/*, docker/redis/*, init.sql entfernt (nie eingebunden).

Onboarding:
- FirstRunWizard verdrahtet: App.tsx fragt GET /setup und zeigt den
  Einrichtungs-Assistenten beim ersten Start (war gebaut, aber nie gerendert).

Doku:
- README: Laufwerk-Abschnitt auf .env, ENV-Tabelle (OPTICAL_*/POSTGRES),
  rshared-Anleitung, neuer Abschnitt "Haertung fuer fremde/exponierte Netze".
- config_validation.py: TMDB Pflicht->empfohlen, Zeichensalat-Tippfehler gefixt.
- .env.example: TMDB-Wording, OPTICAL_*-Variablen.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-24 23:32:59 +02:00
HitonabiandClaude Opus 4.8 6a082cf77c fix(mounts): mounten() idempotent - stale/tote Mounts vor Re-Mount loesen
Ampel / ampel (push) Successful in 28s
Folgefix zum remount-Vorfall 24.07.: mounten() fiel bei einem TOTEN Mount
(os.path.ismount wirft OSError) auf den echten `mount` durch und stapelte auf die
Leiche. Ueber viele Neustarts (via rshared propagiert, ueberlebt Container-Recreate)
wuchs das auf 12 Schichten; die tote oberste blockierte jeden Zugriff (ls-Timeout,
obwohl SMB-445 offen) -> Medien-Mount unbrauchbar.

Fix: _stale_mounts_loesen(ziel) loest per lazy `umount -l` alle Schichten, bevor neu
gemountet wird -> kein Stapeln mehr, Re-Mount idempotent. Ein gesunder Mount wird
weiterhin frueh erkannt (os.path.ismount) und unangetastet gelassen.

Tests (test_mounts_helpers.py): Loesch-Schleife bis leer (monkeypatch) + Verdrahtung.
Ruff gruen.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-24 22:04:00 +02:00
HitonabiandClaude Opus 4.8 46a8f50c34 fix(api): remount nicht-blockierend (Netz-Mount darf API-Start nicht haengen)
Ampel / ampel (push) Successful in 28s
Vorfall 24.07.: Beim API-Start blockierte der synchrone CIFS-Schreibtest in
alle_remounten()/mounten() im Kernel (wait_for_response), als der SMB-Server
langsam war -> ~5 min "Waiting for application startup", kein Endpoint bedient
(bis der soft-Mount per Timeout abbrach). startup_event() lief isoliert sauber,
also war es der blockierende Netz-Mount, nicht die App-Logik.

Fix: remount als Hintergrund-Task (asyncio.create_task) statt await -> die API
kommt sofort hoch, die Mounts stellen sich her sobald der Server antwortet.
Test (test_api_smoke.py): haelt den Nicht-blockierend-Vertrag per Quelltext-
Inspektion fest, im Stil der anderen Verdrahtungs-Tests.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-24 21:50:32 +02:00
HitonabiandClaude Opus 4.8 3f47b504c2 feat(api): MakeMKV-Beta-Key automatisch erneuern
Ampel / ampel (push) Successful in 28s
Der kostenlose Beta-Key wechselt ~monatlich und laeuft zum Monatsende ab; bisher
musste er von Hand nachgetragen werden, sonst blockt Blu-ray-Ripping irgendwann
still. Neu: taeglicher Forum-Abgleich (t=1053) -> Key in die Settings
(makemkvAppKey). Der Worker liest ihn VOR jedem Rip (tasks.py) -> wirkt ohne
Rebuild ab dem naechsten Rip.

- docker/api/makemkv_key.py: extract_key (pure, testbar) + fetch_current_key +
  refresh_once/refresh_loop; loggt in die App-Logs (add_log).
- docker/api/main.py: refresh_loop als startup-Task.
- docker/api/test_makemkv_key.py: Parser-Tests - fingen den Bug, dass Beta-Keys
  laenger als 64 Zeichen sind (Regex {50,} statt {64}).

Betrifft nur die Software-Lizenz (oeffentlicher Gratis-Key), NICHT Disc-Schluessel
- die zieht MakeMKV via LibreDrive selbst. Ruff gruen, 4 Tests gruen, Live-Fetch
gegen das echte Forum verifiziert.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-24 21:27:38 +02:00
HitonabiandClaude Fable 5 71c618073e docs: Anleitung auf .exe-Installer, SAVEPOINT v3.9
Ampel / ampel (push) Successful in 36s
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 19:20:28 +02:00
HitonabiandClaude Fable 5 20cdfedb85 feat(installer): fertige .exe mit Rippy-Icon + ohne Konsolenfenster (statt .vbs)
Ampel / ampel (push) Successful in 28s
Commander-Einwand: .vbs ist abgekuendigt (Win11 24H2 Feature-on-Demand) und
wird oft als gefaehrlich geflaggt. Loesung: echte .exe.
- RippyWorkerSetup.exe (50 KB): install-gui.ps1 via ps2exe kompiliert —
  eingebettetes Rippy-Disc-Icon (deploy/worker-windows/rippy.ico), kein
  Konsolenfenster (-noConsole), WinForms (-STA). E2E getestet: Fenster
  oeffnet, conhost-Zaehler unveraendert (kein Konsolenfenster).
  Vorgebaut auf Windows (build-exe.ps1) + committet — eine Windows-.exe
  kann nicht von Linux (Rippy-Host) gebaut werden. WICHTIG: friert KEINE
  Versionen ein — HandBrake wird zur Laufzeit (GitHub latest) und der
  Worker-Code live von Rippy geholt; nur bei GUI-Aenderungen neu bauen.
- API: GET /worker-setup/windows-exe (FileResponse); Dockerfile kopiert die
  .exe ins Image. .gitattributes: *.exe/*.ico als binary.
- UI (Worker -> Windows): 'Installer herunterladen (.exe)' als Haupt-Weg
  (generisch, GUI fragt Adresse ab; die einzutragende IP wird als Hinweis
  angezeigt). .vbs-Erzeugung entfernt. CLI bleibt Profi-Alternative.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 19:15:42 +02:00
HitonabiandClaude Fable 5 b1d9ece9b2 feat(installer): kein Konsolenfenster (.vbs-Starter) + Rippy-Icon im Installer-Fenster
Ampel / ampel (push) Successful in 28s
Commander-Wunsch: kein Konsolenfenster + Icon.
- Starter ist jetzt eine .vbs (statt .bat): wscript startet PowerShell mit
  Fensterstil 0 = KOMPLETT versteckt, kein Konsolenfenster. Nur das
  WinForms-Installer-Fenster erscheint. Download-Datei: rippy-worker-setup.vbs
  (weiter CLIENT-seitig mit eingetragener LAN-IP erzeugt).
- install-gui.ps1: Fenster-Icon = Rippy-Disc (zur Laufzeit gezeichnet,
  Indigo-Kreis + weisses Loch) — erscheint in Titelleiste + Taskleiste.
  (Die Datei selbst kann Windows-bedingt kein Icon tragen — nur .exe/.lnk.)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 19:03:19 +02:00
HitonabiandClaude Fable 5 b337525bed docs+ui: grafischen Windows-Installer in Anleitung, SAVEPOINT v3.8
Ampel / ampel (push) Successful in 28s
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 18:52:57 +02:00
HitonabiandClaude Fable 5 4fb29d16cf feat(worker): grafischer Windows-Installer (GUI statt CLI)
Ampel / ampel (push) Successful in 28s
Commander-Wunsch: die CLI-Installation ist grausam. Jetzt:
- install-gui.ps1 (WinForms, ASCII-only): Fenster mit Feldern (Rippy-IP,
  Worker-Name, Autostart-Checkbox), Install-Knopf mit Live-Log, danach
  'Worker starten'-Knopf. Gleiche Schritte wie der CLI-Installer
  (Worker-Code + HandBrake latest + venv + Tray/Start/Uninstall).
  Braucht nur Python 3.10+, keine externe GUI-Runtime.
- API: GET /worker-setup/windows-gui serviert die GUI; Dockerfile kopiert
  sie ins worker_dist/.
- UI (Worker-Tab, Windows): 'Grafischen Installer herunterladen (.bat)' als
  Haupt-Weg — die .bat wird CLIENT-seitig mit der eingetragenen LAN-IP
  erzeugt (Blob-Download), Doppelklick laedt+startet die GUI von Rippy.
  Der CLI-Befehl bleibt als Profi-Alternative.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 18:47:57 +02:00
HitonabiandClaude Fable 5 57171b4c88 ui(system): Versionslage exakt darstellen — MakeMKV aktualisierbar, Docker-HandBrake bewusst Debian-stabil
Ampel / ampel (push) Successful in 28s
Commander-Wunsch: das UI soll die Werkzeug-Versionslage genau so zeigen,
wie sie ist. Klarstellung im System-Tab:
- Hinweis bei 'Installierte Werkzeuge': MakeMKV aktuell haltbar (wichtig
  wegen Schluessel-DB), HandBrake im Docker-Worker bewusst Debian-stabil
  (kein separates Update), native Worker holen die neueste.
- Update-Check: MakeMKV mit gruenem '✓ aktuell' bzw. Update-Befehl (echtes
  To-do). HandBrake NICHT mehr als 'Update noetig' alarmieren — neutral als
  'Debian-Version, bewusst so' + Info, dass die nativen Worker die neueste
  nutzen.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 18:42:01 +02:00
HitonabiandClaude Fable 5 3aef344b95 docs: SAVEPOINT v3.7 — Mount-Reparatur, HandBrake-Konsistenz, Encoder-Wahl (live bewiesen)
Ampel / ampel (push) Successful in 28s
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 18:34:12 +02:00
HitonabiandClaude Fable 5 dc1ceda0c2 fix(capabilities): Node-Zuordnung eindeutig bei mehreren Workern pro Host
Ampel / ampel (push) Successful in 28s
Laufen zwei Worker auf demselben Rechner (Befund 24.07.: alter + neuer
Windows-Worker auf TobisNicerPC), war die Node-Zuordnung mehrdeutig — der
Hostname-Match traf irgendeinen. Jetzt disambiguiert der Name-Teil des
Celery-Knotens (WORKER_NAME), sonst Fallback auf den ersten Host-Treffer.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 18:33:22 +02:00
HitonabiandClaude Fable 5 2de0899ac6 fix(installer): install.ps1 ASCII-sauber (Gedankenstrich zerschoss das Skript)
Ampel / ampel (push) Successful in 28s
PowerShell 5.1 liest .ps1 als ANSI, nicht UTF-8. Der Gedankenstrich '—' in
einem Write-Host-String dekodierte zu 'â€"' — das eingebettete Anfuehrungs-
zeichen zerriss die Zeichenkette und der Parser scheiterte (unerwartetes
Token). Alle Nicht-ASCII-Zeichen durch ASCII ersetzt.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 18:27:51 +02:00
HitonabiandClaude Fable 5 47d07d6168 fix(mounts): Reparatur crashte an makedirs + reachable-Check auf 3s begrenzt
Ampel / ampel (push) Successful in 28s
- mounten(): FileExistsError von os.makedirs abgefangen und ismount OSError
  toleriert — ein toter Mount taeuschte isdir, die Reparatur brach ab.
- ist_erreichbar(): 'timeout 3 ls' statt os.listdir — der direkte Zugriff
  blockierte sonst ~10s bis zum CIFS-Timeout (traege Speicherziele-Seite).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 18:23:12 +02:00
HitonabiandClaude Fable 5 4ba02047db Drei Praxis-Bugs: tote NAS-Mounts reparierbar, HandBrake-Versionen konsistent, Encoder-Wahl beim Rip
Ampel / ampel (push) Successful in 28s
1) Speicher-Mounts robust (Befund: toter CIFS-Mount nach NAS-Ausfall/Rebuild —
   mounted:false, verschwand aus 'Verfuegbare Ziele', Neu-Anlegen -> 409, man
   sass fest):
   - mounts.py: ist_erreichbar() (listdir, soft-Mount bricht schnell ab),
     ist_gemountet() faengt OSError toter Mounts, aushaengen() mit
     umount -l Fallback, reparieren() (lazy abhaengen + frisch mounten).
   - /storage-mounts liefert 'reachable'; POST bei existierendem Namen:
     aktiv -> 409, tot -> automatische Reparatur mit neuen Angaben;
     neuer POST /storage-mounts/{name}/repair (gespeicherte Zugangsdaten).
   - /storage-targets crasht nicht mehr an totem Mount (os.path.ismount
     OSError abgefangen).
   - UI: eigene 'Netzwerk-Mounts'-Liste mit Status (aktiv/nicht erreichbar/
     getrennt) + Reparieren- und Entfernen-Knopf — tote Mounts sind sichtbar
     und wiederherstellbar statt zu verschwinden.

2) HandBrake-Versionen konsistent (Befund: Docker 1.6.1, Windows-Skript
   fest 1.9.2, Update-Check meldet 1.11.2 — verwirrend):
   - Windows-Installer zieht jetzt DYNAMISCH die neueste Version (GitHub
     latest, Fallback 1.11.2) — passt zum Update-Check.
   - Update-UI erklaert klar: Docker = stabiles Debian-Paket (bewusst aelter,
     kein Fehler), Windows = neueste. MakeMKV-Update zeigt den Befehl.

3) Encoder-/Worker-Auswahl beim Rip (Feature):
   - Celery worker_direct=True: jeder Worker konsumiert zusaetzlich seine
     Direkt-Queue. API-Helper transcode_queue(node) routet gezielt an den
     gewaehlten Worker, faellt aber sicher auf die geteilte transcode-Queue
     zurueck, wenn er offline ist (kein Haengenbleiben).
   - /capabilities liefert den Celery-Node je Worker; POST /jobs nimmt
     transcode_node (-> Job-meta); rip_disc + retry-transcode routen danach.
   - Rip-Dialog: Encoder-/Worker-Dropdown, sichtbar ab 2 Online-Workern.
   - ping_worker-Task zum Verifizieren des gezielten Routings.
   - Nebenfund gefixt: DeviceDiscovery leitete die Titel-Auswahl (titles)
     gar nicht an die API weiter — jetzt titles + transcode_node.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 18:19:57 +02:00
Hitonabi fe1387b1ec fix(ui): typLabel in DeviceDiscovery definiert (Laufwerks-Details-Button gefixt) & Settings Tab-Wechsel robuster gemacht
Ampel / ampel (push) Successful in 28s
2026-07-24 17:04:18 +02:00
HitonabiandClaude Fable 5 67a4a76afa fix(ui): Worker-Adressfeld nicht mehr mit window.location vorbelegen
Ampel / ampel (push) Successful in 28s
Befund (Commander, Screenshot): Das Feld 'Rippy-Adresse' fuellte sich
automatisch mit window.location.hostname — also der Adresse, ueber die man
das UI geoeffnet hat (bei ihm die eigene PC-IP hinter einem Forward/Proxy,
192.168.178.98). Das ist NICHT zwingend die direkte LAN-IP der
Rippy-Maschine, die der Worker fuer Redis/Postgres (6379/5432) braucht —
der generierte Befehl zeigte damit auf den falschen Host ('Verbindung
verweigert').

Fix:
- Kein Auto-Default mehr (Feld leer); leeres Feld -> sichtbarer
  Platzhalter <RIPPY-IP> im Befehl (erkennbar unvollstaendig statt still
  falsch).
- Label auf 'LAN-IP der Rippy-Maschine (Docker-Host)' geschaerft +
  dauerhaft sichtbarer Hilfetext: die IP der Rippy-Maschine, NICHT dieses
  PCs, und auch dann die direkte LAN-IP wenn das UI ueber Domain/Proxy
  geoeffnet wurde.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 16:53:12 +02:00
Hitonabi b130eeb967 feat(ui): Master-Panel 'Ripping Operations' DIREKT unter Laufwerke verschoben
Ampel / ampel (push) Successful in 28s
2026-07-24 16:44:33 +02:00
Hitonabi bf80f9dfd4 refactor(ui): Current Job, Ripping Queue und Job-Historie in ein einziges Master-Panel bündig unter Laufwerke zusammengeführt
Ampel / ampel (push) Successful in 27s
2026-07-24 16:43:10 +02:00
Hitonabi e0864828c2 style(ui): Ripping Queue Kachel per flex-1 vertikal gestreckt fuer exakt buendigen unteren Abschluss mit Recently Ripped
Ampel / ampel (push) Successful in 28s
2026-07-24 16:41:26 +02:00
Hitonabi 60abf42359 feat(ui): Laufwerke & im Laufwerk erkannte Disc nach ganz oben verschoben, Ripping Queue exakt nach SC1 aufgebaut
Ampel / ampel (push) Successful in 28s
2026-07-24 16:39:56 +02:00
Hitonabi e18315814c feat(ui): 5-Kachel-Banner ohne schwarze Loecher gefuellt, Vollstaendige Job-Tabelle mit TMDB-Beschreibungen wiederhergestellt
Ampel / ampel (push) Successful in 28s
2026-07-24 16:36:12 +02:00
Hitonabi 9b19b74d39 fix(ui): 100% Dark Mode erzwungen (White Mode entfernt), Echte API-Daten fuer Server Status gebunden & Tabs-Breite/Scrollbalken behoben
Ampel / ampel (push) Successful in 28s
2026-07-24 16:33:50 +02:00
Hitonabi 9bc8ad11b2 fix(ui): Zentrierung fuer Anleitung & Einstellungen gefixt, zufaellige Mockup-Filme durch echte API-Daten ersetzt
Ampel / ampel (push) Successful in 28s
2026-07-24 16:31:45 +02:00
Hitonabi 0f20d9d8f4 feat(ui): Rebuild Layout EXACTLY 1:1 matching SC1 Mockup (Top Header Nav, 5-Panel Movie Wall, 2-Column Dashboard Grid with Sparkline & Recently Ripped)
Ampel / ampel (push) Successful in 28s
2026-07-24 16:25:21 +02:00
Hitonabi f0a8455fc2 style(ui): Visuelle Hero Showcase Banner & Poster Cards Grid auf dem Dashboard
Ampel / ampel (push) Successful in 28s
2026-07-24 16:22:40 +02:00
Hitonabi 3643f74eb1 style(ui): Visuelles High-End Overhaul fuer Cinematic Cinema OS (3D Spin-Disc, Hero Banner, Radial Gauges & Poster Grid)
Ampel / ampel (push) Successful in 27s
2026-07-24 16:18:58 +02:00
HitonabiandClaude Fable 5 b8162753a9 chore: Single Source of Truth = main (stable-Branch + Gruen-Gate abgeschafft)
Ampel / ampel (push) Successful in 27s
Commander-Entscheid 24.07.: nur noch EIN Branch. Der stable-Zwischenbranch
war vestigial — die VM deployt ohnehin aus main (git pull), das Gruen-Gate
hat den Live-Deploy nie real gegated.

- ci.yml: Beförderungs-Schritt (push -> stable) entfernt; die Ampel prueft
  nur noch (Ruff/pytest/Vite-Build), Rot heisst weiterhin: nicht deployen.
- deploy.sh: klont/resettet auf main statt stable.
- AGENTS §C, README (Entwicklung), DESIGN-2.0-Briefing: auf main-only
  umgeschrieben. Design-2.0-Briefing als ERLEDIGT markiert.
- SAVEPOINT v3.6.

Branches stable / design-2.0 / kernumbau-2026-07-23 werden nach diesem
Push geloescht (Inhalte vollstaendig in main).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 16:13:10 +02:00
Hitonabi bd00d4c728 refactor(ui): Dashboard, DeviceDiscovery & Settings auf Cinematic Cinema OS umgestellt
Ampel / ampel (push) Successful in 27s
2026-07-24 16:04:50 +02:00
Hitonabi 90b708302e refactor(ui): Modals & Unterseiten auf Primitives & dark: umgestellt 2026-07-24 16:04:46 +02:00
Hitonabi 7004d798d6 feat(ui): Primitives & Design Tokens fuer Cinematic Cinema OS 2026-07-24 16:04:41 +02:00
HitonabiandClaude Fable 5 7b6f836475 docs: Design-2.0-Briefing zur Uebergabe an Gemini + ROADMAP-Zeiger
Ampel / ampel (push) Successful in 27s
Vollstaendige Auftragsbeschreibung fuer den UI-Umbau: 428 theme-Ternaries
-> Tailwind-dark: + UI-Primitives, Ist-Zustand vermessen (Datei-Inventar
mit Ternary-Zahlen), harte Regeln (nur UI, Funktion 1:1, Deutsch, Ampel
gruen), empfohlener Weg, Definition of Done, Copy-Paste-Startprompt.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 15:56:44 +02:00
HitonabiandClaude Fable 5 fdbe1748e5 docs: SAVEPOINT — Windows-Worker Tray + Deinstallation E2E bewiesen
Ampel / ampel (push) Successful in 27s
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 15:48:53 +02:00
HitonabiandClaude Fable 5 404a002d5c Windows-Worker: Tray-Symbol + rueckstandsfreie Deinstallation
Ampel / ampel (push) Successful in 27s
- tray.py (nur nativer Windows-Worker; Docker unberuehrt): pystray+Pillow-
  Tray neben der Uhr — Status, Worker starten/stoppen, Rippy oeffnen,
  Log anzeigen, Beenden (stoppt den Worker mit). Celery laeuft als
  Kind-Prozess ohne Konsolenfenster (CREATE_NO_WINDOW), Log in worker.log.
- install.ps1 erzeugt jetzt start-tray.bat (pythonw, empfohlen),
  start-worker.bat (Konsole/Debug) und uninstall.ps1: stoppt alle
  Prozesse aus dem Ordner, loescht die Autostart-Aufgabe, meldet den
  Worker per DELETE /workers/{name} in Rippy ab und entfernt den Ordner
  komplett. -Autostart registriert die Tray-Variante (onlogon).
- UI-Beschreibung + Anleitung entsprechend ergaenzt.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 15:44:29 +02:00
HitonabiandClaude Fable 5 3987c31b1e Update-Check im System-Tab, Worker-Adressfeld mit Heimnetz-Warnung, Save-Knopf raus aus dem Worker-Tab
Ampel / ampel (push) Successful in 28s
1. Update-Erkennung (Commander-Frage 'wie kriegen wir Updates mit?'):
   GET /system/updates vergleicht installierte Versionen (Worker-Info) mit
   makemkv.com (Versionsnummer der Download-Seite) und der HandBrake-
   GitHub-Release-API (releases/latest), 12 h gecacht. Einstellungen ->
   System: 'Auf Updates prüfen' + fertiger Update-Befehl bei MakeMKV.
   Selbst-Update gibt es bewusst NICHT (waere Docker-Socket-Zugriff);
   dafuer ist MAKEMKV_VERSION jetzt per .env uebersteuerbar — Update ohne
   Code-Aenderung. HandBrake-Abweichung wird als Info dargestellt
   (Debian-Paket hinkt der offiziellen Version bewusst hinterher).
2. Worker-Anbindung: editierbares Adressfeld statt stillschweigend
   window.location.hostname — Befund: ueber die externe Domain kopierte
   Befehle liefen in den Reverse-Proxy (401) und Worker koennen Redis/
   Postgres eh nur im Heimnetz erreichen. Amber-Warnung bei oeffentlich
   aussehender Adresse, Anleitung ergaenzt.
3. 'Einstellungen speichern' ist im Worker-Tab ausgeblendet — dort gibt
   es nichts zu speichern, der Knopf verwirrte nur.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 15:39:20 +02:00
HitonabiandClaude Fable 5 76b4286ad3 Windows-Worker: Pfad-Mapping fuer echte Transcodes + leere-Titel-Meldung + E2E-Beweis dokumentiert
Ampel / ampel (push) Successful in 27s
- pfad_lokal (tasks.py, mit Tests): RIPPY_PATH_MAP uebersetzt
  Container-Pfade (/app/temp, /app/media) auf Netzlaufwerke des nativen
  Workers — ohne Mapping unveraendert (Docker-Worker).
- Rip-Dialog: 'done' mit 0 Titeln bekommt Klartext (Disc vermutlich
  nicht entschluesselbar) statt leerer Tabelle.
- SAVEPOINT: E2E-Beweis des nativen Windows-Workers dokumentiert
  (test-windows-nativ online, HandBrake 1.9.2, echte LAN-IP).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 15:29:56 +02:00
HitonabiandClaude Fable 5 3a4eb25392 Track-Auswahl-Tabelle, nativer Windows-Worker (via UI angeboten), Anleitungs-Tab
Ampel / ampel (push) Successful in 29s
Volle Titel-Auswahl vor dem Rip (Etappe-12-Rest):
- worker.tasks.scan_tracks: makemkvcon info -> Titel-Liste (Dauer/Groesse/
  Kapitel, apdefs-Attr 8/9/11) in die settings-Tabelle 'tracks:<device>';
  API: POST /devices/{n}/scan-tracks + GET /devices/{n}/tracks (Polling).
- Rip-Dialog: 'Disc scannen' -> Tabelle mit Checkboxen, Vorauswahl ab
  5 min, Groessen-Summe; gewaehlte Titel als meta.titles in den Job.
- rip_titel_auswahl: ein makemkvcon-Aufruf je Titel (mkv kann nur einen
  Titel oder all), Fortschritt anteilig. Parser-Tests dabei.

Nativer Windows-Worker OHNE Docker (Commander-Wunsch):
- Die Rippy-Instanz versorgt sich selbst: GET /worker-setup/windows
  liefert install.ps1, /worker-setup/paket den Worker-Code als Zip
  (api-Dockerfile kopiert docker/worker/*.py als worker_dist/ ins Image).
- install.ps1: Python-Check, venv + requirements, HandBrakeCLI 1.9.2 vom
  offiziellen GitHub-Release (URL per HEAD verifiziert), start-worker.bat
  mit celery -Q transcode --pool=solo (Celery-Doku: Windows nur solo),
  optional -Autostart via schtasks onlogon.
- tasks.py laedt jetzt auch ohne fcntl (Import-Guard) — rip_disc ist auf
  solchen Workern hart verriegelt (Klartext-Fehler statt Crash).
- Einstellungen -> Worker: Varianten-Umschalter Linux(Docker)/Windows(nativ)
  mit passenden Copy-Paste-Befehlen.

Anleitungs-Tab: Rippy erklaert sich selbst (Disc-Weg, Serien, NAS,
Media-Server, Benachrichtigungen, Key, Worker, Downloads, FAQ).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 15:18:08 +02:00
HitonabiandClaude Fable 5 325d95af6f build(worker): lokale MakeMKV-Tarballs (vendor/) schlagen den Download
Ampel / ampel (push) Successful in 34s
Cloudflare drosselt BuildKit-Downloads von makemkv.com hartnaeckig (24.07.
viermal, auch MIT --retry-all-errors, waehrend dieselben URLs ausserhalb
des Builds laden). Dauerhafter Ausweg statt Mirror-Hack: Tarballs einmal
nach docker/worker/vendor/ legen (untracked, .gitignore) — der Build nutzt
sie dann direkt und faellt sonst auf curl+Retry zurueck.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 14:26:24 +02:00
HitonabiandClaude Fable 5 8eb5653848 Restefeger: Auth komplett raus, Serien-Flow + Episoden-Matching, Jellyfin-Refresh, Duplikat-Warnung, echtes Nur-Hauptfilm
Ampel / ampel (push) Successful in 55s
AUTH ENTFERNT (Commander-Entscheid 24.07., KONZEPT §10): /token- und
/api-keys-Endpoints, auth.py, test_auth.py, passlib/bcrypt/PyJWT/
python-multipart, JWT_SECRET_KEY-Pflicht. Heimnetz-only, das UI hatte nie
einen Login — die Auth-Oberflaeche war Placebo und die passlib/bcrypt-
Falle brach die Ampel. Rate-Limit pro IP bleibt. Schnellstart laeuft
jetzt ganz ohne .env-Pflichtwerte.

Serien-Flow (Etappe-12-Kern, ARM-Wunde #395):
- Rip-Dialog: Serienname + Staffel -> Ablage <Serie>/Season NN
  (jellyfin.org/docs Naming-Schema); tvshow.nfo + poster.jpg im
  Serien-Ordner, bei Staffel 2 nicht ueberschrieben.
- Episoden-Matching per Laufzeitabgleich: HandBrakeCLI --scan
  ('+ duration:', handbrake.fr/docs) je MKV gegen TMDB-Staffel-Laufzeiten
  (GET /metadata/tv/{id}/season/{n}; tv-season-details-API).
  Ordnungserhaltend; komplette Staffel auf einer Disc klappt auch bei
  uniformen Anime-Laufzeiten (Sequenz-Stufe). Umbenannt wird NUR bei
  eindeutiger Zuordnung — sonst ehrliches Log. Mit Tests.

Weitere Punkte:
- Jellyfin/Emby-Bibliotheks-Refresh nach jedem fertigen Rip
  (POST /Library/Refresh, X-Emby-Token lt. jellyfin.org/docs) —
  URL/Key + Test-Knopf in Einstellungen -> Ripping.
- Duplikat-Warnung: Disc-Fingerabdruck (jetzt Teil des Prescan-Ergebnisses
  + der Job-Metadaten) gegen die Historie; Karte zeigt 'bereits gerippt',
  Vollautomatik ueberspringt Duplikate.
- 'Nur Hauptfilm' ECHT: makemkvcon info -> TINFO-Attr-9-Laufzeiten
  (usage.txt) -> laengster Titel -> mkv dev:X <nr>. Vorher wirkungsloses
  Setting; pro Rip im Dialog uebersteuerbar. Mit Tests.
- OMDb-Treffer eingedeutscht via TMDB /find (external_source=imdb_id,
  de-DE; find-by-id-API).
- Dashboard: Speicherplatz-Anzeige (amber < 60 GB) + CSV-Export
  (GET /jobs/export, Semikolon+BOM fuer deutsches Excel).
- Metadaten-Seite entfernt (Abnahme durch Commander-Auftrag) inkl.
  Placebo-Endpoints /metadata/lookup (scannte Dummy-Device) und
  /metadata/confirm (schrieb nie gelesenen Cache-Key).
- Doppel-Jahr-Fix: 'X (2009) (2009)' in Log und Ordnernamen.
- Remote-Worker-Blocker: redis (6379) + postgres (5432) waren NIE
  veroeffentlicht — kein Remote-Worker konnte sich je verbinden. Ports
  jetzt offen (Heimnetz-Kompromiss, kommentiert) + API_URL fuer Worker.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 14:22:19 +02:00
HitonabiandClaude Fable 5 e7a7d5fdb4 build(worker): MakeMKV-Download mit Retry + dokumentierter Lokal-Mirror-Ausweg
Ampel / ampel (push) Successful in 31s
Cloudflare drosselte am 24.07. wiederholt GENAU die BuildKit-Downloads
(ausserhalb des Builds gingen dieselben URLs mit 200 durch) — drei
Deploy-Anlaeufe starben an curl exit 22. Zwei Gegenmittel:
- curl --retry 5 --retry-delay 15 --retry-all-errors im Download-RUN
  (curl-Doku; --retry-all-errors wiederholt auch bei 4xx/5xx)
- Lokal-Mirror-Rezept im Kommentar: Tarballs von Hand laden, per
  nginx:alpine servieren, MAKEMKV_URL_BASE aufs LAN zeigen — so wurde
  der 1.18.4-Build auf der VM letztlich gebaut.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 13:54:37 +02:00
HitonabiandClaude Fable 5 c9270d08e1 MakeMKV 1.18.4 + UHD-Fehler-Ursachen im Klartext (Laufwerk ist geflasht — Disc-Key war das Problem)
Ampel / ampel (push) Successful in 29s
Diagnose auf der VM (Summer-Wars-UHD, MKB v82):
- 'Using LibreDrive mode (v06.3)' — der BU40N-Crossflash IST erledigt,
  das Laufwerk liest UHD. Der Fehlschlag kam von 'The volume key is
  unknown for this disc': die Disc ist neuer als MakeMKVs
  Schluessel-Datenbank — mit 1.17.7 UND der aktuellsten 1.18.4 bewiesen
  (beide Versionen live gegen die Disc getestet).

Konsequenzen:
- MakeMKV-Pin von 1.17.7 auf 1.18.4 gehoben: der 1.18er Scan-Haenger
  (Forum t=38128) wird ueberall mit --noscan umgangen (info-Lauf mit
  1.18.4 auf der BU40N sauber durchgelaufen), die Flash-Faehigkeit von
  1.17.7 wird nicht mehr gebraucht. Aktuelle Version = aktuellste
  AACS-Key-DB. URL-Base -> /download (dort liegt nur die aktuelle).
- run_makemkv reicht KRITISCHE Meldungen (volume key unknown, Key
  abgelaufen, too old version) in den Fehlertext durch — vorher stand
  da nur die nichtssagende letzte Zeile 'Failed to open disc'.
- UHD-Klartext in tasks.py unterscheidet jetzt die zwei Faelle:
  volume-key-unknown (MakeMKV/Disc-Alter, AACS-Dump aus /root/.MakeMKV/
  im MakeMKV-Forum einreichen) vs. Failed-to-open ohne LibreDrive
  (Firmware-Hinweis).
- SAVEPOINT: Flash-Status korrigiert (war als offen dokumentiert).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 13:44:42 +02:00
HitonabiandClaude Fable 5 5778ac4645 Praxis-Feedback-Runde: CIFS-Cap-Fix, TMDB v3-Keys, 4K-UHD-Typ, Vollautomatik, Job-Verwaltung, Worker-Namen
Ampel / ampel (push) Successful in 29s
Zwei bewiesene Bug-Fixes:
- SMB-Mount 'Unable to apply new capability set': mount.cifs hebt
  CAP_DAC_READ_SEARCH an, die in Dockers Default-Caps fehlt (auf der VM
  reproduziert: Bounding-Set a82425fb ohne Bit 2; mit der Capability
  verschwindet der Fehler). Fix: cap_add DAC_READ_SEARCH fuer den
  api-Container.
- TMDB fiel still aus: Client konnte nur v4-Bearer-Tokens, der uebliche
  32-Hex-v3-Key bekam 401 und die Suche lieferte nur OMDb. Jetzt beide
  Key-Arten (ist_v4_token + api_key-Query-Param lt.
  developer.themoviedb.org, mit Tests) — damit kommen auch die deutschen
  Texte an (language=de-DE war ueberall schon gesetzt). Neu:
  GET /metadata/status + 'Verbindung pruefen' in Einstellungen -> APIs
  (Live-Check am Cache vorbei).

Features aus dem Commander-Feedback:
- 4K UHD als eigener Disc-Typ: classify >= 55 GiB (BD-66/BD-100; BD-50
  bleibt bluray), beide detection.py + Tests, eigene Badge-Farbe in
  Dashboard/Laufwerken, Prescan-Label '4K UHD'. UHD-Rip-Fehler 'Failed to
  open disc' (Code 11) bekommt Klartext: LibreDrive-Firmware noetig.
- Vollautomatik (Setting autoRipStart): Disc erkannt -> Rip startet ohne
  Popup in den Schnellwahl-Ordner (Serie->Serien, sonst Filme, CD->Musik).
- Job-Verwaltung: 'Neu komprimieren' nur noch mit can_retry (Rohdaten
  liegen wirklich da), DELETE /jobs/{id} + 'Erledigte aufraeumen'
  (Dateien bleiben immer), 'Alle herunterladen' im Job-Detail
  (gestaffelte Einzel-Downloads statt Server-Zip von 40-GB-Dateien).
- Worker zuordenbar: WORKER_NAME-Env als stabiler Anzeigename (fixt auch
  die Offline-Leichen nach Rebuilds), info.hostname/ip gemeldet,
  Online-Abgleich ueber hostname, DELETE /workers/{name} + Papierkorb im
  UI, Quelle-Anzeige an der Disc-Karte ('Quelle: TMDB - 99 % sicher').
- Ripping-Tab nach Medium gegliedert (Video/Audio-CD/Allgemein) +
  Untertitel-Klartext (--all-audio/--all-subtitles bleiben komplett),
  CD -> Musik-Vorauswahl im Ziel-Dialog, Ordner-Verwaltung beschriftet
  und standardmaessig eingeklappt.
- Docs: SAVEPOINT v3.3, ROADMAP Etappe 14 + Ideen (nativer
  Windows-Worker, deutsche OMDb-Texte via TMDB-Find), README.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 13:29:10 +02:00
HitonabiandClaude Fable 5 ab75134931 feat: Download-Knopf fuer fertige Rips — Dateien direkt im Browser statt scp
Ampel / ampel (push) Successful in 29s
- GET /jobs/{id}/files: Dateiliste aus job.output_path (Name + Groesse)
- GET /jobs/{id}/files/{name}: FileResponse-Stream; Validierung strikt —
  output_path muss unter /app/media liegen, nackter Dateiname (kein
  Slash/.., kein Dotfile), realpath-Check gegen Symlink-Ausbrueche.
  Mit Test (test_dateiname_validierung_blockt_pfad_tricks).
- UI: 'Download'-Knopf in der Aktion-Spalte bei fertigen Jobs; die
  Dateiliste mit Groessen + Download-Links lebt im Job-Detail-Popup
  (ein Dropdown wuerde im overflow-x-auto-Tabellencontainer clippen).
- nginx: proxy_buffering off + proxy_read_timeout 3600s waren fuer SSE
  schon gesetzt — grosse Downloads brauchen keine Aenderung.

Wunsch aus der Uebernahme-Session (Commander-Sammelliste 24.07.).

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-24 09:01:38 +02:00
315 changed files with 67628 additions and 5226 deletions
+11 -1
View File
@@ -29,11 +29,21 @@ Thumbs.db
.dockerignore
.docker/
# Test
# Test — ** ist Pflicht, sonst greifen die Muster NUR in der obersten Ebene
# des Bau-Kontexts. Ohne ** landeten am 28.08.2026 dreissig test_*.py in beiden
# Laufzeit-Images (im laufenden Container nachgezaehlt: find /app -name
# "test_*.py" | wc -l -> 30). Schadet nichts, gehoert aber nicht ins Image.
tests/
**/tests/
test_*.py
**/test_*.py
*_test.py
**/*_test.py
.pytest_cache/
**/.pytest_cache/
**/__pycache__/
conftest.py
**/conftest.py
# Build
dist/
+54 -5
View File
@@ -1,15 +1,31 @@
# Rippy-Umgebung — nach .env kopieren und Werte eintragen.
# Die .env liegt NUR auf der VM (gitignored), nie im Repo.
# PostgreSQL (intern; Compose nutzt aktuell rippy/rippy — Härtung folgt)
# PostgreSQL (intern). Default rippy; für eine exponierte Umgebung hier ein starkes
# Passwort setzen — Compose nutzt diesen Wert jetzt wirklich (DB + App-Verbindung).
POSTGRES_PASSWORD=rippy
# JWT-Signierschlüssel — PFLICHT, API startet sonst nicht.
# Erzeugen: openssl rand -hex 32
JWT_SECRET_KEY=
# Optisches Laufwerk (Host-Geräteknoten) — je Rechner UNTERSCHIEDLICH!
# Der Worker braucht den SCSI-CD-ROM-Knoten (meist /dev/sr0) UND den passenden
# generischen sg-Knoten des Laufwerks.
#
# BEWUSST AUSKOMMENTIERT: Die sg-Nummer ist JE HOST ANDERS. Ein vorbelegter Wert
# wäre auf den meisten Rechnern falsch — und zwar unbemerkt, weil er dann „schon
# gesetzt" aussieht. `install.sh` findet beide Knoten selbst (Abgleich über die
# SCSI-Adresse in /sys) und trägt sie hier ein.
#
# Von Hand ermitteln, falls gewünscht: lsscsi -g
# Ohne Eintrag gelten die Compose-Vorgaben /dev/sr0 und /dev/sg1.
#OPTICAL_SR=/dev/sr0
#OPTICAL_SG=/dev/sg1
# (JWT/Auth wurde am 24.07.2026 komplett entfernt — Rippy ist Heimnetz-only,
# Commander-Entscheid, siehe KONZEPT.md Abschnitt 10. Härtung für exponierte
# Netze: siehe README, Abschnitt "Härtung für fremde/exponierte Netze".)
# Metadaten-APIs
# TMDB (Pflicht für Metadaten-Lookup): kostenlos auf themoviedb.org
# TMDB (empfohlen für Metadaten-Lookup; ohne Key startet Rippy trotzdem, Key auch
# später im UI setzbar): kostenlos auf themoviedb.org
TMDB_API_KEY=
# TVDb (optional, Serien-Fallback)
THETVDB_API_KEY=
@@ -22,3 +38,36 @@ OMDB_API_KEY=
# Bequemer: im UI unter Einstellungen → System eintragen (gilt ab dem
# nächsten Rip, ohne Neustart, und schlägt diesen Env-Wert).
MAKEMKV_APP_KEY=
# MakeMKV-Datenverzeichnis auf dem HOST (bleibt über Rebuilds hinweg erhalten).
# Hier hinein gehört die KEYDB.cfg für 4K-UHD-Discs; hier landen auch die
# AACS-Dumps fehlgeschlagener Discs. Beides ist ab Einstellungen → System
# im Browser erreichbar — dieser Pfad ist nur für den Fall, dass du die
# Dateien direkt auf der Maschine anfassen willst.
#MAKEMKV_DATA_HOST=/srv/rippy/makemkv
# MakeMKV-Version fürs Worker-Image (Einstellungen → System meldet Updates).
# Update: Version hier anheben, dann auf der Rippy-Maschine
# docker compose build worker && docker compose up -d worker
# (bei Cloudflare-Zicken vorher Tarballs nach docker/worker/vendor/ legen)
#MAKEMKV_VERSION=1.18.4
# ---------------------------------------------------------------------------
# MakeMKV-Bezug beim Image-Bau (nur nötig, wenn der Download klemmt)
# ---------------------------------------------------------------------------
# Am 25.07.2026 nachgemessen, welche Quellen wirklich liefern:
# https://www.makemkv.com/download HTTP 200 <- der Standard, funktioniert
# https://www.makemkv.com/download/old HTTP 525 (Cloudflare)
# web.archive.org-Schnappschuss HTTP 404
# Normalerweise ist hier NICHTS einzutragen.
#MAKEMKV_URL_BASE=https://www.makemkv.com/download
#
# Zweite Quelle, die bei Fehlschlag der ersten automatisch probiert wird.
# Trage hier nur etwas ein, das du selbst geprüft hast — eine Adresse, die nicht
# liefert, lässt die Konfiguration gesund aussehen und den Bau später scheitern.
# Genau so lag es auf der Rippy-VM: dort stand eine 404-Adresse, und nur die
# vendor-Tarballs retteten jeden Bau, ohne dass es jemandem auffiel.
#MAKEMKV_URL_FALLBACK=http://192.168.178.10:8099
#
# Der zuverlässigste Weg bleibt ohne Netz: Tarballs von makemkv.com/download
# laden und nach docker/worker/vendor/ legen — der Bau nimmt sie dann von dort.
+2
View File
@@ -1,3 +1,5 @@
# Shell-Skripte brauchen LF — mit CRLF scheitert der Interpreter im Container
# ("/bin/sh^M: bad interpreter"). Wir entwickeln auf Windows, gebaut wird auf Linux.
*.sh text eol=lf
*.exe binary
*.ico binary
+17 -7
View File
@@ -52,6 +52,17 @@ jobs:
if [ -n "$pkg_dateien" ]; then
echo "== Node/TypeScript erkannt =="
# Rippy v5 (rippy-windows/) braucht Node >= 22 (node:sqlite, Vite 7).
# Das Runner-Image (docker.gitea.com/runner-images:ubuntu-latest)
# bringt Node 24 nativ mit — am 30.08.2026 nachgemessen. Ein
# actions/setup-node-Schritt scheiterte hier dagegen (Lauf 221);
# deshalb die Prüfung als Klartext statt Beschaffungs-Magie.
node_major=$(node -p 'parseInt(process.versions.node)' 2>/dev/null || echo 0)
echo "-- Node im Runner: $(node -v 2>/dev/null || echo 'FEHLT')"
if [ "$node_major" -lt 22 ]; then
echo "❌ Node zu alt für rippy-windows (braucht >= 22) — Runner-Image prüfen."
rot=1
fi
while IFS= read -r pkg; do
[ -n "$pkg" ] || continue
d=$(dirname "$pkg")
@@ -72,13 +83,12 @@ jobs:
fi
exit $rot
- name: Grün-Gate — grünen Stand auf 'stable' befördern (Arcane deployt von dort)
- name: Ergebnis
if: success()
shell: bash
run: |
if [ "${GITHUB_REF_NAME:-}" = "main" ]; then
git push origin +HEAD:refs/heads/stable
echo "✅ main → stable befördert. Arcane-GitSync zieht 'stable' und deployt."
else
echo "Kein main-Push — keine Beförderung."
fi
# Single Source of Truth: 'main' (24.07.2026, Commander-Entscheid —
# der stable-Zwischenbranch ist weg). Die Ampel PRÜFT nur noch und
# befördert nichts; deployt wird direkt aus 'main' (git pull auf der
# VM bzw. ./deploy.sh). Rot heißt weiterhin: nicht deployen.
echo "✅ AMPEL GRÜN. Deploy-Quelle ist 'main' — von dort deployen."
+4
View File
@@ -54,3 +54,7 @@ logs/
# Data
*.db
*.sqlite
dist/
# Design-Canvas-Arbeitsdateien (leben im Claude-Artifact, nicht im Git)
design-entwuerfe/
+138 -5
View File
@@ -17,16 +17,41 @@ abschwächen). Keine Tests = rot = nicht fertig. Der Commander liest die Ampel,
gestrichenes Muss-Feature → erst den Commander fragen, NIE still ersetzen.
(Vorgefallen: Muss-Feature „MakeMKV lossless" wurde still durch lossy HandBrake ersetzt.)
**C. Deployment läuft AUTOMATISCH über das Grün-Gate.** Ampel grün auf `main`
CI befördert den Stand auf Branch `stable` → Arcane-GitSync zieht `stable` und
deployt. Du deployst also durch PUSHEN, nicht durch Kommandos. `./deploy.sh` ist
NUR der Notfall-Hebel (Arcane down o. ä.); nie freihändig per SSH auf der VM bauen.
**C. Single Source of Truth ist `main` — es gibt nur diesen einen Branch**
(seit 24.07.2026; der `stable`-Zwischenbranch ist abgeschafft). Die CI-Ampel
läuft bei jedem Push und PRÜFT nur (Ruff/pytest/Vite-Build) — sie befördert
nichts mehr. Deployt wird direkt aus `main`: auf der VM `git pull` bzw.
`./deploy.sh` (verifiziere vorher, dass die Ampel für den Commit GRÜN ist —
rot heißt: nicht deployen). Nie freihändig per SSH auf der VM bauen.
(Vorgefallen: Doppel-Anlage `Rippy` + `rippy` auf der VM durch Freihand-Deploys.)
**D. Externe Schnittstellen NIE aus dem Kopf.** Vor Nutzung fremder CLI-Flags oder
Bibliotheks-APIs: `--help`/Doku prüfen und die Fundstelle im Commit nennen.
(Vorgefallen: erfundene Celery-Methode `self.send_task`, erfundene abcde-Flags.)
### Zwei Schreibfallen, die am 28.08.2026 mehrfach gekostet haben
**1. Deutsche Anführungszeichen in doppelt gequoteten Zeichenketten.**
Das öffnende `„` ist U+201E und harmlos. Das schließende ist das **gerade
ASCII-Zeichen** `"` — es beendet die Python-Zeichenkette. Der Fehler erscheint
dann am Gedankenstrich dahinter, also an einer Stelle, an der nichts falsch
ist. An einem Tag vier Mal passiert.
falsch: "einen Ordner unter „Benutzer" wählen"
richtig: 'einen Ordner unter „Benutzer" wählen'
**Regel: Steht ein `„` in der Zeichenkette, gehört sie in EINFACHE
Anführungszeichen.**
**2. Bash-Heredocs mit Windows-Pfaden.** `<<'EOF'` sollte literal sein,
halbiert in dieser Umgebung aber Backslashes — aus `C:\\Users` wird `C:\Users`,
und das ist eine ungültige Escape-Sequenz. An einem Tag fünf Mal passiert,
zuletzt beim Schreiben genau dieses Absatzes.
**Regel: Dateien mit Windows-Pfaden oder Umlauten mit dem Write-Werkzeug
schreiben, nicht per Heredoc.** Wo es doch sein muss: Backslashes über
`chr(92)` zusammensetzen.
## Workflow
1. **Read:** KONZEPT.md + ROADMAP.md lesen. Verstehen, welche Etappe dran ist.
@@ -53,10 +78,118 @@ Bibliotheks-APIs: `--help`/Doku prüfen und die Fundstelle im Commit nennen.
- Kein Proxmox-LXC-Nesting-Workaround — das Projekt lebt bewusst in normalem Docker.
- Kein ARM-Fork — Rippy ist ein Eigenbau von Grund auf.
## Aktueller Stand (24.07.2026)
## Aktueller Stand (26.07.2026)
-**E2E bewiesen (v3.1):** BD-50 komplett durch die Kette (43 GB → 4,8 GB)
-**Etappe 13 (v3.2):** Universal-Komfort-Runde — Media-Server-Integration,
echte Benachrichtigungen, SMB-Klartext-Fehler, UHD-Arbeitsverzeichnis,
MakeMKV-Key via UI, Job-Detail-Popup, Toast-Feedback, Ampel-Blocker behoben
-**Etappe 17 (v3.10):** 4K-UHD-Disc-Schlüssel — persistentes
MakeMKV-Datenverzeichnis + `KEYDB.cfg` im UI
-**Etappe 18 (v3.11):** 4K-UHD gelöst — `makemkvcon` holt Schlüssel
unter Linux nie, unter Windows schon; Schlüsselspeicher übernehmbar.
Akira-UHD geht auf der VM auf (`TCOUNT:5`, bewiesen)
-**Etappe 19 (v3.14):** Durchsicht Frontend/Backend — vier Placebos weg
(Fortschritt log, Auswurf tat nichts, „Alle Tracks" konnte nichts, Encoder
wurden behauptet statt gemessen), Zombie-Erkennung gebaut, Pfad-Prüfung
gehärtet, und der Platten-Schutz aus `c065967` als **unwirksam** entlarvt
-**Etappe 20 (v3.15):** Aufräum-Runde — `/capabilities` 1,010 s → 0,003 s
(Ping im Hintergrund), Kompression je Disc-Typ abwählbar (4K verlustfrei),
Wizard empfiehlt nach gemessener CPU, vier tote Routen entfernt
-**Etappe 21 (v3.17):** Der Blocker externes Encoden ist zu —
`RIPPY_PATH_MAP` leitet Rippy aus seinen eigenen Mounts ab, der Installer holt
es selbst; Presets kommen vom Worker statt aus dem Quelltext; Dashboard ohne
Placebos, mit Restzeit. Dazu vier Bestandsfehler, alle live gemessen (u. a.
„Neu komprimieren" ging nie, und `os.path.isdir` hing im Kernel)
-**Etappe 22 (v3.18):** Auswurf wirkt endlich (MakeMKV verriegelt die Tür —
erst entriegeln, dann prüfen statt glauben), externer Worker meldet sein Log
nach Rippy, zeigt den laufenden Job und nimmt mehrere Aufträge an. Dazu **die
Mount-Ursache**: Die CIFS-Verbindung lebt in der Netz-Namespace des
api-Containers und stirbt mit ihm — eine Wache heilt das jetzt selbst
-**Etappe 23 (v3.19):** Sprachwahl vor dem Rip (Ton + Untertitel, Automatik
einstellbar), Auswurf wirkt wirklich (MakeMKV verriegelt die Tür), externer
Worker mit Verwaltungsfenster/Deinstaller/Slots, Schlüssel-Automatik für 4K,
Mount-Wiederanbindung 202 s → 8 s, Weitergabe an einem frischen Klon geprüft
-**Etappe 24 (v3.20):** Rippy bremste sich selbst aus — das Rate-Limit lag
unter der eigenen Last (100/min gegen 123/min), hinter dem Proxy teilten alle
Clients einen Eimer, und ein abgewiesener Abruf leerte das UI. Dazu: der
„Neu"-Knopf kennt jetzt die Phase (Rip oder Kompression) und fragt, wo er es
nicht weiß; zwei Fehler im Deploy-Weg behoben
- 📝 **Details immer in SAVEPOINT.md** — diese Sektion nennt nur die Etappe
## Was diese Sitzungen wiederholt gekostet hat
**Nicht aus einem Zustandswert auf einen Mechanismus schließen.** Vorgefallen:
aus „kein Schlüssel da" → „Server abgeschaltet" (falsch), aus Status
`transcoding` → „Celery hat neu zugestellt" (falsch), aus `progress=99`
„Altwert aus dem Absturz" (falsch — ein Bug), aus gleichem `st_dev`
`os.rename` funktioniert" (falsch — der Kernel vergleicht den Mount).
Jedes Mal hätte eine Messung von unter einer Minute gereicht.
**Und die Umkehrung gilt genauso:** gleiches `st_dev` heißt NICHT gleicher
Mount. Wo eine Eigenschaft ausprobierbar ist, probiere sie aus, statt sie
vorherzusagen.
**Ein Hintergrund-Prozess, der still scheitert, ist schlimmer als einer, der
laut scheitert** (26.07.2026). Ein `except Exception: pass` in einer
Vorrats-Schleife hat eine Stunde gekostet: Der Vorrat blieb leer, die Funktion
lief direkt aufgerufen einwandfrei, und der Grund stand nirgends. Gefunden erst
über die Thread-Zustände (`/proc/<pid>/task/*/stat`, Zustand `D` = im Kernel
blockiert). Jede Hintergrund-Schleife MELDET ihren Fehler, und wer einen Vorrat
anlegt, macht sein Alter abfragbar (`GET /health/vorraete`) — sonst ist am
Endpunkt selbst nichts zu sehen.
**Ein Rückgabewert ist kein Beweis, wo die Wirkung prüfbar ist** (26.07.2026,
zweimal am selben Abend). `CDROMEJECT` quittiert Erfolg auf einem verriegelten
Laufwerk und wirft nichts aus; `mount` quittiert Erfolg auf einer Verbindung, die
Sekunden später stirbt. Beide Fehler waren monatelang unsichtbar, weil der Code
dem Rückgabewert glaubte. Nach einer Aktion den ZUSTAND fragen — und wenn er
flattert, zweimal mit Abstand.
**Bei „zu langsam" die DAUER je Schritt messbar machen, nicht die plausibelste
Ursache beheben** (26.07.2026). Eine Mount-Wiederanbindung brauchte 150 s; die
erste, sehr plausible Erklärung war falsch, und die Änderung machte es langsamer
(202 s). Erst Zeitstempel im Log zeigten die Stelle: ein `os.makedirs` in Zeile
eins, das drei Minuten im Kernel hing. Danach 8 s. Wer eine Dauer nicht
aufschlüsselt, optimiert die falsche Stelle.
**Netz-Pfade nie ungebremst anfassen.** `os.path.isdir`/`open` auf einem toten
CIFS-Mount blockieren im Kernel und lassen sich aus Python NICHT abbrechen. Ein
Kind-Prozess lässt sich abbrechen: `timeout N ls -d <pfad>` (Muster in
`mounts.ist_erreichbar` und `rohdaten.verzeichnis_da`). Und „konnte nicht
nachsehen" ist etwas anderes als „ist nicht da" — beides zu vermischen erzeugt
falsche Aussagen im UI.
**Ein verpasster Abruf ist keine Nachricht über die Welt** (26.07.2026). Im UI
stand fünfmal `catch(() => [])`: Jeder fehlgeschlagene Abruf hieß damit „es gibt
keine Jobs, keine Laufwerke, keine Ablagen" — die Liste leerte sich für einen
Takt und füllte sich vier Sekunden später wieder. Der Commander meldete das als
„wird oft neu geladen", und die Ursache war unsichtbar, weil der Fehlerzweig
nichts protokollierte. Wer nichts Neues weiß, behält, was er wusste: bei
Fehlschlag `null` und den alten Stand stehen lassen — nie einen leeren Wert, der
als Aussage gelesen wird.
**Eine eigene Schutzbremse gegen die eigene Last rechnen** (26.07.2026). Das
Rate-Limit stand auf 100 Anfragen/min, während ein einziger offener Tab 111/min
verursacht (Dashboard 75 + Log-Kasten 24 + Laufwerke 12). Rippy bremste sich
also permanent selbst aus, und niemand sah es: Der 429 stand in keinem Log, und
das UI verbuchte ihn als Leermeldung. Dazu der zweite Fehler — hinter einem
Reverse-Proxy ist `request.client.host` IMMER der Proxy, also hatten Browser,
zweiter Tab und Windows-Tray EINEN gemeinsamen Eimer (812 von 876 Anfragen kamen
scheinbar von einer IP). Wer eine Grenze setzt, rechnet die eigene Grundlast vor,
schreibt sie als Kommentar dazu und lässt jedes Greifen protokollieren.
**Eine geschluckte Warnung ist eine Falle** (26.07.2026). `cp "$ENV_SRC" .env
2>/dev/null || echo "WARNUNG: …"` scheiterte auf der Ziel-VM bei JEDEM Deploy,
weil die .env dort anders lag. Die Zeile scrollte im Build-Rauschen vorbei,
gebaut wurde still mit einer zwei Tage alten Kopie — mit einem toten
Download-Notbehelf darin, an dem jeder worker-Build abbrach. Entweder abbrechen
oder so laut werden, dass es nicht zu übersehen ist (Dateidatum, Kandidatenliste);
ein `|| echo` in einem 200-Zeilen-Log ist keins von beidem.
**Wenn der Commander eine Korrelation nennt, ist das eine Spur.** „Wenn der
Worker installiert ist, wird der Bereich oft neu geladen" klang nach Bauchgefühl
und war exakt richtig: `tray.py` fragt `/api/jobs` über Port 80, landet damit im
Rate-Limit-Eimer des Browsers und drückt ihn über die Grenze. Dieselbe Lehre wie
bei „auf Windows ginge das sofort" (Disc-Schlüssel) — die Beobachtung ernst
nehmen, auch wenn die vermutete Erklärung („Celery-Ping?") daneben liegt.
+1493
View File
File diff suppressed because it is too large Load Diff
+1131
View File
File diff suppressed because it is too large Load Diff
+96 -2
View File
@@ -35,8 +35,8 @@ Ein modular aufgebautes System, das bei Disc-Einwurf automatisch den Typ erkennt
| AcoustID-Fingerprinting (chromaprint) | ✔ M | | |
| Multi-Disc-Set-Handling (Release-Group-Resolver) | ✔ M | | |
| SQLite-Cache für API-Rate-Limits | ✔ M | | |
| JWT-Auth (Access 15min/Refresh 7 Tage) | ✔ M | | |
| Rate-Limiting (100/min pro API-Key) | ✔ M | | |
| ~~JWT-Auth (Access 15min/Refresh 7 Tage)~~ — GESTRICHEN 24.07.2026, siehe §10 | | | |
| Rate-Limiting pro Client-IP — ~~100/min~~ **600/min** (26.07.2026, siehe Abweichungen) | ✔ M | | |
| Celery-Queue + Redis mit AOF-Persistence | ✔ M | | |
| React-UI (statisch via Nginx) | ✔ M | | |
| Proxmox LXC Template + Ansible Playbooks | ✔ M | | |
@@ -127,6 +127,7 @@ Ein modular aufgebautes System, das bei Disc-Einwurf automatisch den Typ erkennt
| Risiko | Status | Behandlung |
|--------|--------|------------|
| MakeMKV-Beta-Key-Management | Gelöst | Key-Erneuerung als Cron-Job; DMCA-Ausnahme in DE |
| **Disc-Schlüssel für 4K-UHD (AACS 2.0)** | **Gelöst mit Handgriff** | Am 25.07.2026 auf beiden Maschinen gemessen: `makemkvcon` unter **Linux** ruft Disc-Schlüssel nie ab (kein einziger Verbindungsversuch, mit leerem wie gefülltem Speicher, mit und ohne `--noscan`, `dev:` wie `disc:`), die **Windows**-Version tut es (Meldung 3338). Rippy stellt ein persistentes Datenverzeichnis bereit und nimmt den Schlüsselspeicher `_private_data.tar` einer Windows-Installation sowie ersatzweise eine `KEYDB.cfg` entgegen; damit ging Akira UHD auf der VM auf. Rippy liefert, lädt und verteilt KEINE Schlüssel. Siehe §10 (25.07.2026) |
| LXC-Device-Node-Änderungen | Gelöst | udev-Resolver (UUID/Serial) |
| Pending-Queue / State-Manager | Gelöst | Redis mit AOF-Persistence |
| Hybrid-Discs | Offen | MVP erkennt nur Standard; als "Kann" notiert |
@@ -175,3 +176,96 @@ Ein modular aufgebautes System, das bei Disc-Einwurf automatisch den Typ erkennt
- **23./24.07.2026 — udev → ioctl:** Der im Konzept beschriebene udev-Daemon
ist im Container prinzipbedingt nicht lauffähig; die Disc-Wache pollt per
Kernel-ioctl (3 s) — gleiches Verhalten, universell lauffähig.
- **24.07.2026 — AUTH GESTRICHEN (Commander-Entscheid):** Das Muss-Feature
„JWT-Auth" ist komplett entfernt (Endpoints, auth.py, Abhängigkeiten,
Env-Pflicht). Begründung: Rippy läuft ausschließlich im Heimnetz, das UI
hatte nie einen Login-Flow — die Auth-Oberfläche war Placebo und die
passlib/bcrypt-Abhängigkeit hat die CI-Ampel gebrochen. Rate-Limiting
(pro IP) bleibt. Wer Rippy je nach außen öffnet, stellt einen
Reverse-Proxy mit eigener Auth davor (z. B. Authelia/Caddy basicauth).
- **26.07.2026 — Rate-Limit von 100/min auf 600/min:** Das Muss-Feature
(„Rate-Limiting pro Client-IP") bleibt unverändert, nur die Zahl ändert sich.
Begründung: 100/min lag UNTER Rippys eigener Last. Nachgerechnet an den
Taktgebern im UI verursacht ein einziger offener Tab 111 Anfragen pro Minute
(Dashboard 75 + Log-Kasten 24 + Laufwerks-Suche 12), ein installierter
Windows-Worker weitere 12. Die Bremse griff also im Normalbetrieb permanent —
97 Antworten mit HTTP 429 im nginx-Log —, und weil das UI einen abgewiesenen
Abruf als „nichts da" verbuchte, leerte sich die Job-Liste im Sekundentakt.
Genau das hat der Commander als „wird oft neu geladen" gemeldet. 600/min =
10 Anfragen pro Sekunde: Luft für mehrere Tabs und Worker, während der Zweck
der Bremse (ein Skript in einer Endlosschleife, Hunderte pro Sekunde) weiter
erfüllt ist. Die Rechnung steht als Kommentar in `ratelimit.py` und ist durch
`test_grenze_deckt_die_eigene_last_ab` festgehalten — wer die Zahl senkt, muss
dort vorbei. Zweiter Teil derselben Reparatur: Hinter dem nginx ist
`request.client.host` immer der Proxy, alle Clients teilten sich also EINEN
Eimer; jetzt gilt `X-Real-IP`.
- **25.07.2026 — 4K-UHD-Disc-Schlüssel: Rippy stellt Platz bereit, keine
Schlüssel:** Das Muss-Feature „MakeMKV-Ripping (lossless)" bleibt
unverändert; ergänzt wird nur ein **persistentes MakeMKV-Datenverzeichnis**
(`MAKEMKV_DATA_HOST`, im Worker `/root/.MakeMKV`, in der API
`/app/makemkv-data`) samt Bedienung im UI. Begründung: Am 25.07.2026 auf
BEIDEN Maschinen nachgemessen — `makemkvcon` unter Linux ruft Disc-Schlüssel
nie ab, die Windows-Version tut es. (Erste Fassung dieses Eintrags behauptete,
MakeMKVs Schlüssel-Kanal sei abgeschaltet; das war falsch und wurde am selben
Tag richtiggestellt.) Rippy nimmt deshalb den Schlüsselspeicher
`_private_data.tar` einer MakeMKV-Installation entgegen und ersatzweise eine
`KEYDB.cfg`. **Rippy liefert und verteilt KEINE Disc-Schlüssel und
lädt auch keine herunter** — es hält nur den Platz für Dateien bereit,
die der Nutzer selbst mitbringt, zeigt ehrlich an, was dort liegt, und gibt
die AACS-Dumps heraus, die MakeMKV ohnehin selbst schreibt. Das ist genau
die Grenze, die `docker/api/makemkv_key.py` in Zeile 14 zieht: die
kostenlose Beta-LIZENZ der Software ist etwas anderes als das
Entschlüsseln oder Verteilen von Disc-Schlüsseln.
- **24.07.2026 — Serien-Flow:** Staffel-Ablage <Serie>/Season NN plus
Episoden-Zuordnung per Laufzeitabgleich (TMDB) — erfüllt Etappe-12-Ziel
„Serien-Episoden-Erkennung" in der ersten Ausbaustufe (nur bei
EINDEUTIGER Zuordnung wird umbenannt).
- **28.08.2026 — DISC-SCHLÜSSEL: die Grenze vom 25.07. ist verschoben
(Commander-Entscheid).** Der Eintrag vom 25.07.2026 oben sagt: *„Rippy
liefert und verteilt KEINE Disc-Schlüssel und lädt auch keine herunter."*
**Das gilt ab jetzt nicht mehr unverändert.** Auf ausdrückliche Entscheidung
des Commanders bekommt Rippy v2 einen automatischen Abruf — mit den
bisherigen Wegen als Rückfallebene. Umgesetzt als Kette in DREI Stufen, die
der Reihe nach abgearbeitet wird und anhält, sobald eine trägt:
1. **Eigener Bestand** (Schlüsselspeicher der Installation) — immer zuerst.
Gefüllt vom Windows-Knoten, der die Schlüssel über die eigene
MakeMKV-Lizenz selbst abruft (unter Linux tut `makemkvcon` das nie,
Messung 25.07.2026), und von jedem Import.
2. **Automatischer Abruf** von der konfigurierten Quelle — wenn Stufe 1
die Disc nicht kennt.
3. **Import von Hand** (`_private_data.tar`, `KEYDB.cfg` über das UI) —
unverändert aus v1.
Fünf Regeln gehören zum Entscheid dazu: (a) die Bezugsadresse steht in der
KONFIGURATION und ist LEER vorbelegt — ohne Eintrag ist Stufe 2
übersprungen; eine vorbelegte Adresse, die irgendwann tot ist, wäre genau
die Falle aus `.env.example` („lässt die Konfiguration gesund aussehen und
den Bau später scheitern"). (b) Ein funktionierender Bestand wird NIE still
überschrieben — neue Datei daneben, prüfen, dann tauschen. (c) Ein
Fehlschlag ist LAUT (kein `except: pass`, Meldung im Log und im UI).
(d) Das UI zeigt Herkunft und Alter jedes Eintrags. (e) **Rippy bringt
selbst nichts mit** — weder Installer noch Docker-Image enthalten Schlüssel
oder eine vorbelegte Bezugsadresse; was abgerufen wird, trägt der Betreiber
der Installation ein. Ausführlich in `KONZEPT-V2.md` § 7.5 und § 10.
- **28.08.2026 — SPEICHERZIELE: der Host mountet, Rippy prüft
(Commander-Entscheid).** Das Muss-Feature „NFS/Bind-Mount für Medien-Store"
(§ 6) bleibt; was wegfällt, ist das Mounten DURCH Rippy. Begründung ist der
Befund vom 26.07.2026: Die CIFS-Verbindung lebt in der Netz-Namespace des
api-Containers und stirbt mit ihm — dagegen läuft heute eine Mount-Wache.
In v2 hängt der Host ein (fstab, `.mount`-Unit oder Compose-Volume-Treiber),
und Rippy erzeugt dafür die fertige, kopierbare Zeile. Die Eingabemaske im
UI bleibt; der Knopf „Verbinden" wird zu „Zeile kopieren". Die gesamte
PRÜF-Logik aus `mounts.py` bleibt erhalten (Erreichbarkeit mit Zeitgrenze
im Kindprozess, SMB-Klartextfehler, Pfad-Map-Vorschlag). Folge:
`CAP_SYS_ADMIN`, `DAC_READ_SEARCH`, `apparmor:unconfined`,
`propagation: rshared` und die Mount-Wache fallen ersatzlos weg.
- **28.08.2026 — RIPPY v2: drei Betriebsmodi statt eines
(Commander-Auftrag).** Die Multi-Container-Architektur aus § 6 bleibt als
EINER von drei Modi bestehen. Dazu kommen eine native Windows-Installation
ohne Docker und eine Headless-Linux-Anwendung — beide mit demselben
Webinterface. Technisch tragen alle drei denselben Kern; ein Modus ist nur
die Auswahl der Treiber hinter vier Ports (Store, Queue, Bus, Drives).
Damit sind Postgres und Redis für Einzelinstallationen keine Pflicht mehr
(SQLite + lokale Queue), bleiben im verteilten Modus aber unverändert.
Vollständige Spezifikation: **`KONZEPT-V2.md`**, Etappen in `ROADMAP.md`.
+444 -126
View File
@@ -2,156 +2,474 @@
Disc rein → automatisch erkannt (Titel, Poster, Metadaten) → verlustfrei
gerippt (MakeMKV) → auf Arbeitsgröße komprimiert (HandBrake) → fertig
abgelegt, wo DU willst (lokal, NAS, jede Freigabe). Modernes Web-UI,
Echtzeit-Fortschritt, komplett in Docker, komplett lokal.
abgelegt, wo du willst (lokal, NAS, jede Freigabe). Modernes Web-UI, komplett
in Docker, komplett lokal — keine Cloud, keine Telemetrie.
## Schnellstart
---
Voraussetzungen: Docker + Docker Compose, ein optisches Laufwerk am Host.
## Installation
Du brauchst: einen **Linux-Rechner mit Docker** und ein **optisches Laufwerk**.
**Welche Distribution, ist gleichgültig** — Debian, Ubuntu, Arch, Fedora,
openSUSE, Alpine. Rippy bringt alles Nötige (MakeMKV, HandBrake, abcde) in
seinen eigenen Containern mit; vom Host braucht es nur Docker und einen Kernel,
der das Laufwerk sieht. `install.sh` erkennt das Paketwerkzeug selbst und nennt
dir den passenden Befehl, falls etwas fehlt.
```bash
git clone <repo-url> rippy && cd rippy
cp .env.example .env # JWT_SECRET_KEY eintragen (openssl rand -hex 32)
mkdir -p /srv/rippy/media # Ablage-Basis (anpassbar in docker-compose.yml)
sudo ./install.sh
```
Das war es. Am Ende steht die Adresse im Terminal — im Browser öffnen, der
**Einrichtungs-Assistent** übernimmt den Rest.
Zuerst nur nachsehen, ob alles passt, ohne etwas zu ändern:
```bash
./install.sh --nur-pruefen
```
<details>
<summary><b>Was <code>install.sh</code> für dich macht</b> (aufklappen)</summary>
Es nimmt genau die Schritte ab, an denen man vorher scheitern konnte:
1. **Prüft die Voraussetzungen** — Linux, Docker, Compose. Fehlt etwas, steht
der Installationsbefehl dabei.
2. **Findet dein Laufwerk selbst.** MakeMKV braucht **zwei** Geräteknoten:
`/dev/srN` und den passenden `/dev/sgM`. Welche sg-Nummer dazugehört, ist
**je Rechner anders** — das Skript gleicht sie über die SCSI-Adresse ab
statt zu raten. (Genau daran ging vorher die Handarbeit schief.)
3. **Legt die Verzeichnisse an** (`/srv/rippy/media` für die Filme,
`/srv/rippy/makemkv` für MakeMKVs Daten).
4. **Richtet die Mount-Propagation ein** und macht sie neustart-fest — sonst
funktioniert das Einhängen von NAS-Freigaben aus dem UI nach jedem Reboot
nicht mehr.
5. **Schreibt die `.env`** mit den gefundenen Werten. Bestehende Werte werden
**nie** überschrieben.
6. **Baut und startet** alles.
Das Skript ist **wiederholbar**: mehrmals ausführen ändert nichts kaputt. Es
ist auch der Update-Weg — siehe unten.
</details>
### Aktualisieren
```bash
git pull && sudo ./install.sh
```
---
## Mit einer Docker-Oberfläche (Dockge, Portainer, Arcane)
**Die eine Sache, die du wissen musst:** Rippy hat **keine fertigen Images in
einer Registry.** Die drei Dienste `api`, `worker` und `ui` werden aus dem Repo
gebaut (`build: context: .`). Die Compose-Datei allein ist deshalb wertlos —
wer sie in ein leeres Verzeichnis kopiert, bekommt sofort
*„failed to read dockerfile"*.
Daraus folgt für **jede** Oberfläche: **das Repo muss dort liegen, wo die
Oberfläche den Stack baut.** Alles andere ist Kleinarbeit.
| | kann das Repo selbst holen? | Weg |
|---|---|---|
| **Shell** | — | `git clone` + `sudo ./install.sh` |
| **Dockge** | nein | Repo **in** den Stacks-Ordner klonen |
| **Portainer** | **ja** | Stack aus *Repository* (Git-URL) |
| **Arcane** | nein | Repo auf dem Host, Deploy per Shell |
### Vorab-Prüfung — braucht kein root, ändert nichts
Egal welche Oberfläche: Führe nach dem Klonen einmal das hier aus. Es sagt dir
in fünf Sekunden, ob die Maschine passt — vor allem, **welche Geräteknoten dein
Laufwerk wirklich hat**:
```bash
./install.sh --nur-pruefen
```
### Dockge
Dockge verwaltet Stacks als Verzeichnisse. Klone das Repo **in** den
Stacks-Ordner (Standard `/opt/stacks`, bei dir ggf. anders):
```bash
cd /opt/stacks
git clone <repo-url> rippy
cd rippy && ./install.sh --nur-pruefen
```
Dockge zeigt `rippy` danach als Stack an, und „Start" baut die Images. Du musst
**keine Compose-Datei einfügen** — die des Repos ist die des Stacks. Lege den
Stack also **nicht** neu in Dockge an, sonst landet eine leere Compose-Datei in
einem anderen Ordner und der Bau scheitert.
### Portainer
Portainer kann das Repo selbst klonen, das ist hier der bequemste Weg:
**Stacks → Add stack → Repository**, Git-URL eintragen, Compose-Pfad
`docker-compose.yml`. Der Web-Editor und „Upload" funktionieren **nicht**
beide liefern keinen Build-Kontext.
Die Geräteknoten trägst du als Stack-Umgebungsvariablen ein (statt in eine
`.env`), falls sie von `/dev/sr0` und `/dev/sg1` abweichen:
```
OPTICAL_SR=/dev/sr0
OPTICAL_SG=/dev/sg0
```
Welche es sind, sagt dir auf dem Host `lsscsi -g` — oder die Vorab-Prüfung oben.
### Arcane
Das Repo liegt auf dem Host (z. B. `~/projects/rippy`), Arcane verwaltet die
Container. Deployt wird per Shell — Arcanes Git-Sync zieht **nicht**
selbstständig:
```bash
cd ~/projects/rippy && git pull --ff-only && docker compose up -d --build
```
### Was keine Oberfläche für dich tun kann
Drei Dinge passieren auf dem **Host**, nicht im Container — deshalb gibt es
`install.sh` überhaupt:
1. **Geräteknoten.** MakeMKV braucht `/dev/srN` **und** den passenden
`/dev/sgM`; die sg-Nummer ist je Rechner anders. Stimmt sie nicht, **startet
der Worker-Container gar nicht.** Das ist der Fehler, der praktisch immer als
erster kommt.
2. **Ablage-Ordner** `/srv/rippy/media` und `/srv/rippy/makemkv`.
3. **Mount-Propagation** (`rshared`) für das Einhängen von NAS-Freigaben aus dem
UI. Auf den meisten systemd-Hosts ist `/` schon `rshared` und es ist nichts
zu tun — nur wenn `docker compose up` über *„not a shared mount"* klagt,
braucht es die Shell.
Punkt 1 ist der einzige, der zuverlässig zuschlägt. `sudo ./install.sh` erledigt
alle drei; danach kannst du den Stack dauerhaft über die Oberfläche fahren.
---
## Wenn etwas nicht geht
Die sechs Fälle, die praktisch alles abdecken:
| Symptom | Ursache & Lösung |
|---|---|
| **`failed to read dockerfile`** | Die Compose-Datei liegt ohne das Repo da. Rippy hat **keine Registry-Images**, die drei Dienste werden gebaut. Siehe **[Mit einer Docker-Oberfläche](#mit-einer-docker-oberfläche-dockge-portainer-arcane)**. |
| **Worker-Container startet nicht, `/dev/sgN` nicht gefunden** | Die sg-Nummer ist **je Rechner anders**; die Vorgaben `sr0`/`sg1` passen nur zufällig. `./install.sh --nur-pruefen` sagt dir die richtigen (oder `lsscsi -g`), dann in die `.env` bzw. als Stack-Variablen eintragen. **Der Fehler, der praktisch immer als erster kommt.** |
| **„Kein optisches Laufwerk gefunden"** | In einer **VM**? Das Laufwerk muss per **USB-Passthrough** durchgereicht werden, nicht als emuliertes CD-ROM (`media=cdrom`) — das kann keine SCSI-Kommandos, MakeMKV sieht es nie. Proxmox: `qm set <vmid> -usb0 host=<hersteller>:<produkt>,usb3=1`. Auf echter Hardware: `ls /dev/sr*` prüfen. |
| **Build bricht beim MakeMKV-Download ab** | Cloudflare drosselt manchmal. Der zuverlässige Weg: Tarballs von makemkv.com/download händisch nach `docker/worker/vendor/` legen, dann `sudo ./install.sh` erneut — der Build nimmt sie von dort und braucht kein Netz. Hast du eine eigene Quelle (Spiegel im LAN), trage sie als `MAKEMKV_URL_FALLBACK` in die `.env` ein; sie wird automatisch versucht, wenn makemkv.com nicht liefert. |
| **Kompression läuft ewig** | Deine CPU kann kein AVX2. Rippy zeigt das jetzt selbst an (Einstellungen → System, „Vektorbefehle"). Siehe **[Rippy schneller machen](#rippy-schneller-machen)**. |
| **4K-UHD: „The volume key is unknown"** | Erwartbar und **kein Fehler in Rippy**. Siehe **[4K-UHD](#4k-uhd)**. |
Logs ansehen: `docker compose logs -f` · Status: `docker compose ps`
---
## Rippy schneller machen
**Läuft Rippy in einer virtuellen Maschine, ist das hier der wirksamste
Handgriff überhaupt** — und er kostet fünf Minuten.
Virtualisierer geben der VM standardmäßig eine **generische CPU** (bei
Proxmox/KVM heißt sie `kvm64` bzw. `qemu64`). Die kann absichtlich nur alte
Befehlssätze, damit sich eine VM zwischen verschiedenen Wirten verschieben
lässt. Der Preis: **kein AVX2** — und genau davon lebt der Video-Encoder x265.
Was das ausmacht, ist auf der Rippy-Maschine gemessen worden: ein 4K-Film in
H.265 brauchte **28 bis 55 Stunden**, bei voll ausgelasteten Kernen. Mit AVX2
sind typisch **2- bis 4-mal schneller** drin.
**So stellst du es um (Proxmox):**
1. VM **herunterfahren.** Ein Neustart von innen genügt nicht — Proxmox
übernimmt Hardware-Änderungen nur bei einem echten Stopp.
2. Im Web-UI: VM auswählen → **Hardware****Processors** → Doppelklick →
**Type** auf **`host`** stellen → OK.
Oder auf der Proxmox-Konsole:
```bash
qm set <vmid> --cpu host
```
3. VM **starten.**
**Nachprüfen — Rippy sagt es dir selbst:** Einstellungen → System, Zeile
„Vektorbefehle" beim Worker. Steht dort jetzt `avx2` oder `avx512f` statt
`sse4_2`, hat es geklappt und die amberfarbene Warnung verschwindet.
Auf der Kommandozeile: `grep -o avx2 /proc/cpuinfo | head -1`.
<details>
<summary>Nachteile von <code>host</code> — der Vollständigkeit halber</summary>
Die VM sieht dann die echte CPU. Dadurch lässt sie sich nicht mehr auf einen
Wirt mit anderem Prozessor **live** verschieben. In einem Heim-Cluster mit
einem einzigen Wirt ist das ohne Bedeutung. Wer mehrere Wirte hat und
Live-Migration nutzt, wählt statt `host` das neueste Modell, das **alle**
Wirte beherrschen (z. B. `x86-64-v3` — das enthält AVX2).
</details>
**Kein AVX2 möglich?** Dann zwei Auswege, beide im UI:
- **4K nicht komprimieren** (Einstellungen → Verarbeitung → Preset für 4K-UHD →
„Nicht komprimieren"). Die verlustfreie Datei bleibt stehen: beste Qualität,
20100 GB je Film. Der Einrichtungs-Assistent wählt das bei schwacher CPU
von selbst.
- **Andere Maschine komprimieren lassen** — siehe
[Weitere Maschinen als Worker](#weitere-maschinen-als-worker).
---
## Der Alltag
### Rippen
Disc einlegen. Rippy erkennt sie, zeigt Titel und Poster, du wählst das Ziel —
oder du stellst die **Vollautomatik** an (Einstellungen → Ripping) und es
läuft ohne Nachfrage los.
- **Alle Tonspuren und Untertitel bleiben erhalten** (wichtig für Anime/O-Ton).
- **Nur Hauptfilm** auf Wunsch — der längste Titel, Extras bleiben weg.
- **Serien:** Serienname + Staffel angeben → Ablage `<Serie>/Season NN`, und
die Episoden werden per Laufzeitabgleich (TMDB) zu „Serie S01E02.mkv"
benannt. Nur bei eindeutiger Zuordnung, sonst bleiben die Namen — mit Log.
- **Audio-CDs** laufen über abcde zu FLAC mit MusicBrainz-Tags.
- Schon gerippte Discs erkennt Rippy am Fingerabdruck und warnt.
- Vor dem Start wird der freie Platz gegen die Disc-Größe geprüft.
### Kompression
Ein **eigenes Preset je Disc-Typ** (Einstellungen → Verarbeitung) — Rippy
erkennt den Typ selbst. Das ist wichtig, weil ein 1080p-Preset eine 4K-UHD
stillschweigend herunterrechnet und eine DVD sinnlos hochskaliert.
Jeder Typ kann auch auf **„Nicht komprimieren"** stehen: dann bleibt der
verlustfreie Rip liegen. Sinnvoll für 4K, wenn die Ablage groß genug ist.
Die Rohdatei wird erst nach erfolgreicher Kompression gelöscht („Original
behalten" als Option). Fehlgeschlagene Kompressionen lassen sich ohne
Neu-Rip erneut anstoßen.
### Ablage & Media-Server
Einstellungen → Ripping: dein System wählen (Jellyfin, Emby, Kodi, Plex oder
keins). Fertige Rips heißen dann „Titel (Jahr)"; für Jellyfin/Emby/Kodi legt
Rippy zusätzlich `movie.nfo` + `poster.jpg` dazu. Bei **Jellyfin/Emby** mit
Server-URL + API-Key stößt Rippy nach jedem Rip sofort einen
Bibliotheks-Scan an — Disc rein, Film erscheint im Server.
**NAS-Freigaben** hängst du unter Einstellungen → Speicherziele direkt aus dem
UI ein (NFS/SMB). Sie erscheinen sofort in der Ziel-Auswahl und werden beim
Start automatisch wieder verbunden.
⚠️ Zugangsdaten liegen unverschlüsselt in der lokalen Datenbank — bewusster
Heimnetz-Kompromiss. Lege fürs NAS einen eigenen, eingeschränkten Benutzer an.
### Benachrichtigungen
Einstellungen → Benachrichtigungen: eine Webhook-URL eintragen, „Test senden"
drücken, speichern. Rippy erkennt den Dienst an der URL selbst:
| Dienst | URL-Beispiel |
|---|---|
| Discord | `https://discord.com/api/webhooks/…` |
| Slack | `https://hooks.slack.com/services/…` |
| ntfy (Handy-Push) | `https://ntfy.sh/mein-geheimes-thema` |
| Eigenes (Home Assistant, n8n, …) | beliebige HTTPS-URL |
---
## 4K-UHD
4K braucht **zwei** Dinge, die normale BD/DVD nicht brauchen: ein
**LibreDrive-fähiges Laufwerk** (MakeMKV-Forum: „Ultimate UHD Drives Flashing
Guide") **und** den **Schlüssel dieser Pressung**.
**Der Schlüssel ist die eigentliche Hürde — aus einem überraschenden Grund.**
Am 25.07.2026 auf beiden Maschinen gemessen (Akira UHD, MKB v76, Pressung
Dezember 2020): Laufwerk und MakeMKV waren in Ordnung — „Using LibreDrive mode
(v06.3)", die Disc wurde gelesen — und trotzdem kam „The volume key is unknown
for this disc".
> **`makemkvcon` unter Linux holt Disc-Schlüssel nie aus dem Netz.
> Die Windows-Version tut es.**
Gemessen: Linux baute in keinem einzigen Lauf eine Verbindung nach draußen auf
— geprüft mit leerem und gefülltem Schlüsselspeicher, mit und ohne `--noscan`,
mit `dev:` und `disc:`, und mit erzwungener frischer Prüfung. Dieselbe Disc am
selben Laufwerk unter Windows: „Lade aktuelle HK …", Verbindung zum
Schlüssel-Server, Disc geht auf. **Ein MakeMKV-Update ändert daran nichts, und
es ist kein Fehler in Rippy.**
**Der Weg drumherum** (Einstellungen → System):
1. MakeMKV auf einem **Windows-PC** installieren (gleicher Beta-Key).
2. Laufwerk anstecken, Disc **einmal öffnen** — dabei lädt MakeMKV die
Schlüssel nach.
3. In MakeMKV unter *Preferences → General* das „MakeMKV data directory"
nachschlagen und die Datei **`_private_data.tar`** daraus bei Rippy
hochladen.
Rippy zeigt an, **wie viele Disc-Schlüssel** dieser Worker kennt. Steht dort 0,
scheitert jede unbekannte UHD. Für neue Discs den Schritt gelegentlich
wiederholen. Rippy prüft die Datei und lehnt sie ab, wenn kein einziger
Schlüssel drinsteckt — sonst ändert sich nichts und niemand versteht, warum.
**Kennt MakeMKV die Pressung selbst nicht**, bleibt die **`KEYDB.cfg`** als
Notnagel (gleicher Tab). Und: **AACS-Dumps herunterladen** — den Dump legt
MakeMKV bei jeder unbekannten Disc selbst ab, und genau den braucht man, wenn
man im MakeMKV-Forum um den Schlüssel für eine neue Pressung bittet.
> ⚠️ **Rippy liefert keine Disc-Schlüssel mit, lädt keine herunter und
> verteilt keine.** Rippy hält nur den Platz für eine Datei bereit, die du
> selbst mitbringst, und zeigt ehrlich an, was dort liegt. Der
> MakeMKV-**Beta-Key** ist die Lizenz für die *Software* — zwei völlig
> verschiedene Dinge.
⚠️ UHD-Rohdaten sind bis 100 GB groß. Ist die Platte zu klein, lege das
**Arbeitsverzeichnis** (Einstellungen → Verarbeitung) auf eine eingehängte
Freigabe. Rippy bricht sonst **vor** dem Rip mit Klartext ab statt nach 40 GB
mit voller Platte.
---
## Weitere Maschinen als Worker
Die Kompression läuft als eigener Task auf der Queue `transcode` — **jede**
Maschine im Netz kann sie übernehmen. Einstellungen → Worker zeigt für beide
Varianten einen Copy-Paste-Befehl:
- **Windows (nativ, ohne Docker)** — braucht nur Python. Der Installer kommt
als fertige `.exe` von Rippy selbst; Worker-Code und HandBrake holt er zur
Laufzeit.
- **Linux (Docker)** — `deploy/remote-transcode-worker.yml`.
Rippy zeigt für jeden Worker an, **was er wirklich kann**: Encoder, Kernzahl,
Vektorbefehle. Für einen **GPU-Worker** wichtig: das Bild braucht ein
HandBrake mit `nvenc_*` bzw. `qsv_*` — die Anzeige nennt HandBrakes
ungefilterte Auskunft, damit du das nachprüfen kannst. Das mitgelieferte
Linux-Worker-Bild hat **keinen** Hardware-Encoder.
Ohne Zusatz-Worker macht der eingebaute CPU-Worker alles selbst — Rippy bleibt
All-in-one.
---
## Für Fortgeschrittene
<details>
<summary><b>Umgebungsvariablen (.env)</b></summary>
`install.sh` füllt die hostabhängigen Werte selbst. Alles hier ist optional —
UI-Einstellungen überstimmen die Env-Variablen.
| Variable | Zweck |
|---|---|
| `TMDB_API_KEY` | Metadaten (deutsche Texte). Bequemer im Assistenten — beide Key-Arten gehen (v3-Schlüssel und v4-Token) |
| `OMDB_API_KEY` | zweite Metadaten-Quelle (Fallback) |
| `THETVDB_API_KEY` | Serien-Fallback |
| `WORKER_NAME` | Anzeigename des eingebauten Workers (Standard `rippy-hauptworker`) |
| `MAKEMKV_APP_KEY` | MakeMKV-Beta-Key. Bequemer im UI unter Einstellungen → System — gilt ab dem nächsten Rip, ohne Rebuild |
| `MAKEMKV_VERSION` | MakeMKV-Version für den Image-Build |
| `MAKEMKV_URL_BASE` | Download-Quelle für den Build. Normalerweise **nichts eintragen** — der Standard `makemkv.com/download` liefert (am 25.07.2026 mit HTTP 200 geprüft; `/download/old` gibt 525, ein web.archive.org-Schnappschuss 404) |
| `MAKEMKV_URL_FALLBACK` | zweite Quelle, die bei Fehlschlag der ersten **automatisch** versucht wird. Leer = keine. Trage nur ein, was du selbst geprüft hast: eine Adresse, die nicht liefert, lässt die Konfiguration gesund aussehen und den Build später scheitern |
| `MAKEMKV_DATA_HOST` | Host-Verzeichnis für MakeMKVs Daten (Standard `/srv/rippy/makemkv`) — Schlüsselspeicher, `KEYDB.cfg`, AACS-Dumps. Persistent, überlebt jeden Rebuild |
| `OPTICAL_SR` / `OPTICAL_SG` | Geräteknoten des Laufwerks. **Findet `install.sh` selbst** |
| `POSTGRES_PASSWORD` | DB-Passwort (Standard `rippy`) |
</details>
<details>
<summary><b>Installation ohne install.sh (von Hand)</b></summary>
Falls du jeden Schritt selbst machen willst:
```bash
cp .env.example .env
mkdir -p /srv/rippy/media /srv/rippy/makemkv
# Laufwerksknoten ermitteln — die sg-Nummer ist je Host anders!
lsscsi -g # zeigt Modell + zugehoerigen /dev/sgN
# in die .env: OPTICAL_SR=/dev/sr0 und OPTICAL_SG=/dev/sgN
# Nur falls 'docker compose up' meldet:
# "path ... is mounted on / but it is not a shared mount"
mount --bind /srv/rippy/media /srv/rippy/media
mount --make-rshared /srv/rippy/media # neustart-fest als systemd-.mount-Unit
docker compose up -d --build
```
Dann `http://<host>` öffnen — der **Einrichtungs-Assistent** startet beim
ersten Mal automatisch (API-Keys, Verarbeitung, erkannte Hardware).
Braucht klassisches Linux-Docker mit `SYS_ADMIN` — nicht Docker Desktop,
rootless oder Podman. Die Mount-Propagation ist nur für das Einhängen von
NAS-Freigaben **aus dem UI** nötig; Freigaben auf dem Host einhängen geht immer.
### Laufwerk anpassen
</details>
Standard ist `/dev/sr0` (+ `/dev/sg1` für den Worker — MakeMKV spricht
Laufwerke über die SCSI-Generic-Schicht an). Andere Geräte? Lege eine
`docker-compose.override.yml` an:
<details>
<summary><b>Wie es intern funktioniert</b></summary>
```yaml
services:
api:
devices: ["/dev/sr1:/dev/sr0"]
worker:
devices: ["/dev/sr1:/dev/sr0", "/dev/sg2:/dev/sg1"]
```
1. **Disc-Wache** — ioctl-Polling, kein udev. Im Container läuft kein udevd,
die udev-Datenbank ist leer; `udevadm info` liefert dort prinzipbedingt
nichts.
2. **Rip** — MakeMKV, verlustfrei. Der einzige Weg durch AACS: HandBrake kann
verschlüsselte Discs nicht lesen, deshalb sind es zwingend zwei Stufen.
3. **Kompression** — HandBrake als eigener Celery-Task auf eigener Queue,
deshalb an andere Maschinen routbar.
4. **Metadaten** — Volume-Label → TMDB → OMDb → MyAnimeList, mit
Ähnlichkeits-Bewertung und Korrektur-Popup an der Disc-Karte.
Welche sg-Nummer dein Laufwerk hat, verrät `lsscsi -g` oder
`ls -la /sys/class/scsi_generic/`.
</details>
**Laufwerk in einer VM?** Per USB-Passthrough anhand der Vendor-ID
durchreichen (Proxmox: `qm set <vmid> -usb0 host=xxxx:yyyy,usb3=1`) —
NICHT als emuliertes CD-ROM (`media=cdrom`), das kann keine SCSI-Kommandos.
<details>
<summary><b>Härtung für exponierte Netze</b></summary>
## Wie es funktioniert
Rippy ist bewusst **Heimnetz-only**: keine Authentifizierung, und Redis +
PostgreSQL veröffentlichen Ports für Remote-Worker. Im vertrauten LAN ein
akzeptierter Kompromiss — **exponiere Rippy niemals ungeschützt an ein
öffentliches Netz.**
1. **Disc-Wache** (ioctl-Polling, kein udev-Gefrickel) erkennt Einlegen,
identifiziert die Disc (Volume-Label → TMDB → OMDb-Fallback) und zeigt
sie mit Poster auf dem Dashboard. Klick auf einen Job-Titel öffnet die
Detail-Ansicht (Poster, Jahr, Beschreibung, Ablagepfad).
2. **Rip** (MakeMKV, verlustfrei — der einzige Weg durch AACS): Ziel wählst
du beim Start (Filme/Serien/Musik/eigener Pfad, inkl. Netzwerk-Ziele).
Vor dem Start prüft Rippy den freien Platz gegen die Disc-Größe.
Audio-CDs laufen über abcde → FLAC + MusicBrainz.
3. **Kompression** (HandBrake, eigener Job auf eigener Queue): x265/x264,
Preset im UI wählbar; Rohdatei wird erst nach Erfolg gelöscht
(„Original behalten" als Option). Fehlgeschlagene Kompressionen lassen
sich ohne Neu-Rip neu anstoßen.
4. **Media-Server-Ablage**: Unter Einstellungen → Ripping (oder im
Einrichtungs-Assistenten) wählst du dein System — Jellyfin, Emby, Kodi,
Plex oder keins. Fertige Rips heißen dann „Titel (Jahr)" statt
Job-UUID; für Jellyfin/Emby/Kodi legt Rippy zusätzlich movie.nfo +
poster.jpg dazu (Kodi-NFO-Schema, lesen alle drei nativ). Plex nutzt
nur die Benennung.
5. **4K-UHD**: braucht ein LibreDrive-fähiges Laufwerk (MakeMKV-Forum:
„Ultimate UHD Drives Flashing Guide"). Normale BD/DVD gehen mit jedem
Laufwerk. ⚠️ UHD-Rohdaten sind bis 100 GB groß — wenn die Platte der
Rippy-Maschine dafür zu klein ist, lege das **Arbeitsverzeichnis**
(Einstellungen → Verarbeitung) auf eine eingehängte Freigabe, z. B.
`/app/media/nas-arbeit`. Rippy bricht sonst VOR dem Rip mit einer
Klartext-Meldung ab statt nach 40 GB mit voller Platte.
- **Zugriff kapseln:** UI und API (`:8000`) hinter einen Reverse-Proxy mit Auth
oder nur über VPN erreichbar machen.
- **DB/Broker abschotten:** starkes `POSTGRES_PASSWORD`; die Ports
`5432`/`6379` nur an ein internes/VPN-Interface binden statt an `0.0.0.0`;
Redis mit `--requirepass` starten und das Passwort in `REDIS_URL` ergänzen.
- **CORS:** `main.py` erlaubt `*` (nötig, weil UI und API getrennte Ports
sind) — hinter einem Proxy auf die echte UI-Herkunft einschränken.
- **NAS-Zugangsdaten** liegen im Klartext in der DB — ein weiterer Grund, den
DB-Port nie offen ins unsichere Netz zu hängen.
## Speicherziele (NAS, Freigaben)
</details>
Unter **Einstellungen → Speicherziele** hängst du NFS- oder SMB-Freigaben
direkt aus dem UI ein — sie erscheinen sofort in der Ziel-Auswahl beim
Rippen und werden beim Start automatisch wieder verbunden.
Technik: der api-Container läuft mit `CAP_SYS_ADMIN` und einem
rshared-Bind auf `/srv/rippy/media`, Mounts propagieren zu allen
Containern. ⚠️ Zugangsdaten liegen unverschlüsselt in der lokalen
Postgres-DB — bewusster Heimnetz-Kompromiss; lege fürs NAS einen eigenen,
eingeschränkten Benutzer an.
<details>
<summary><b>Updates der Werkzeuge</b></summary>
## Benachrichtigungen
„Auf Updates prüfen" (Einstellungen → System) vergleicht mit makemkv.com und
den offiziellen HandBrake-Releases, 12 h gecacht.
**Einstellungen → Benachrichtigungen**: eine Webhook-URL eintragen, „Test
senden" drücken, speichern — fertig. Rippy meldet Job-Ende (fertig,
fehlgeschlagen, abgebrochen) und erkennt den Dienst an der URL selbst:
**MakeMKV** aktualisieren: `MAKEMKV_VERSION=x.y.z` in die `.env`, dann
`sudo ./install.sh`. Der Beta-Key wechselt etwa monatlich (Forum-Thread
t=1053) und wird im UI gepflegt — ohne Rebuild.
| Dienst | URL-Beispiel | Format |
|---|---|---|
| Discord | `https://discord.com/api/webhooks/…` | `{"content": …}` |
| Slack | `https://hooks.slack.com/services/…` | `{"text": …}` |
| ntfy (Handy-Push) | `https://ntfy.sh/mein-geheimes-thema` | Roh-Text + Titel |
| Eigenes (HA, n8n, …) | beliebige HTTPS-URL | `{"title","message","level"}` |
**HandBrake** kommt im Docker-Worker bewusst aus Debian (stabil, hinkt der
offiziellen Version hinterher); der native Windows-Worker nutzt die aktuelle.
## System & MakeMKV-Beta-Key
⚠️ Ein MakeMKV-Update hilft **nicht** gegen „The volume key is unknown" —
MakeMKV liefert überhaupt keine Disc-Schlüssel mit, es holt sie zur Laufzeit,
und die Linux-Version holt sie nie. Siehe [4K-UHD](#4k-uhd).
**Einstellungen → System** zeigt die Werkzeug-Versionen jedes Workers
(MakeMKV, HandBrake), den Key-Status und den freien Speicherplatz. Der
MakeMKV-Beta-Key (wechselt ~monatlich, Forum-Thread t=1053) wird hier im
UI eingetragen und gilt ab dem **nächsten Rip** — ohne Rebuild, ohne
Neustart; er schlägt den Key aus der `.env`. Nur die MakeMKV-*Version*
steckt im Image: `docker compose build worker && docker compose up -d worker`.
</details>
## Verarbeitung & Hardware
**Einstellungen → Verarbeitung** zeigt ehrlich an, welche Encoder deine
Worker WIRKLICH haben (CPU x264/x265, VAAPI bei AMD/Intel-GPU, NVENC bei
NVIDIA) — jeder Worker meldet seine Fähigkeiten selbst beim Start.
### Optional: GPU-Maschine im Netz als Transcode-Worker
Die Kompression läuft als eigener Celery-Task auf der Queue `transcode`
JEDE Maschine im Netz kann sie übernehmen (siehe
`deploy/remote-transcode-worker.yml`). Ohne Zusatz-Worker macht der
eingebaute CPU-Worker alles selbst — Rippy bleibt All-in-one.
## Umgebungsvariablen (.env)
| Variable | Pflicht | Zweck |
|---|---|---|
| `JWT_SECRET_KEY` | ✔ | Signierschlüssel (openssl rand -hex 32) |
| `TMDB_API_KEY` | empfohlen | Metadaten — alternativ im UI/Wizard eintragbar |
| `OMDB_API_KEY` | optional | zweite Metadaten-Quelle (Fallback) |
| `THETVDB_API_KEY` | optional | Serien-Fallback |
| `MAKEMKV_APP_KEY` | optional | MakeMKV-Beta-Key (Forum); DVDs gehen ohne — bequemer: im UI unter Einstellungen → System pflegen |
| `MAKEMKV_URL_BASE` | optional | alternative Download-Quelle für den Image-Build |
UI-Einstellungen (Wizard/Settings) überstimmen die Env-Variablen.
## Rippy woanders bereitstellen
Rippy ist reines Docker Compose — es läuft auf **jedem Linux-Host mit
Docker**, nicht nur auf der Original-VM. Es gibt (noch) keine fertigen
Registry-Images; gebaut wird beim ersten `up` direkt aus dem Repo.
Voraussetzungen auf dem Ziel-Host:
1. Linux (x86_64) mit Docker + Compose-Plugin.
2. Ein optisches Laufwerk, das der Host sieht (`ls /dev/sr* /dev/sg*`).
In einer VM: per **USB-Passthrough** (Vendor-ID) durchreichen, NICHT
als emuliertes CD-ROM — siehe „Laufwerk anpassen" oben.
3. Ablage-Basis anlegen: `mkdir -p /srv/rippy/media` (oder Pfad in
`docker-compose.yml` anpassen — muss ein rshared-fähiger Bind sein).
Dann wie im Schnellstart: klonen, `.env` füllen, `docker compose up -d
--build`, `http://<host>` öffnen — der Einrichtungs-Assistent führt durch
den Rest (API-Keys, Media-Server, Verarbeitung). Updates: `git pull &&
docker compose up -d --build`.
Nicht mitnehmen musst du: Gitea, Arcane, den CI-Runner — das ist die
Entwicklungs-Infrastruktur DIESER Installation, nicht Teil von Rippy.
---
## Entwicklung
CI („Ampel") läuft bei jedem Push: Ruff, pytest, Vite-Build. Grün auf
`main` wird automatisch auf `stable` befördert — deploye von `stable`.
CI („Ampel") läuft bei jedem Push: Ruff, pytest, Vite-Build. Es gibt genau
einen Branch, `main` — die Ampel prüft nur, deployt wird direkt aus `main`.
Rot heißt: nicht deployen.
Regeln für Beiträge: [AGENTS.md](AGENTS.md) · Konzept: [KONZEPT.md](KONZEPT.md) ·
Fahrplan: [ROADMAP.md](ROADMAP.md)
Fahrplan: [ROADMAP.md](ROADMAP.md) · Stand: [SAVEPOINT.md](SAVEPOINT.md)
+388 -16
View File
@@ -332,25 +332,397 @@ auffiel, in einem Rutsch. Alles gebaut, Tests dabei, Ampel-Blocker behoben.
Claude and KrBrZ".
- [x] README: Media-Server, Benachrichtigungen, UHD-Arbeitsverzeichnis,
„Rippy woanders bereitstellen" (beliebiger Docker-Host).
- [x] **Download-Knopf für fertige Rips** (Wunsch aus der Übernahme-Session):
GET /jobs/{id}/files (+ Datei-Stream, Pfad-Validierung strikt unter
/app/media inkl. realpath-Check), Download-Knopf in der Aktion-Spalte,
Dateiliste mit Größen im Job-Detail-Popup — vorher kam man an fertige
MKVs nur per scp. nginx hatte proxy_buffering off schon (SSE).
**Offen aus dieser Runde:** nichts — Rest siehe Etappe 12 und Ideen unten.
---
## Ideen-Katalog (24.07.2026, priorisiert) — Lücken, die noch offen sind
## Etappe 14 (24.07.2026): Praxis-Feedback-Runde — erste echte Nutzung
1. **Serien-Staffel-Flow**: Beim Rippen einer Serien-Disc Staffel/Disc-Nr
abfragen → Ablage `Show/Season 02/`, Episoden-Matching wie Etappe 12.
2. **Duplikat-Warnung**: Disc-Fingerprint schon in der Job-Historie →
„schon am X gerippt — trotzdem?" (Fingerprint-Infrastruktur existiert).
3. **Jellyfin-Bibliotheks-Refresh** nach Ablage (API-Key + URL in den
Einstellungen, POST /Library/Refresh) — der letzte Schritt zur
Null-Klick-Kette Disc→Bildschirm.
4. **Track-Auswahl vor dem Rip** (awaiting_selection, Etappe 12) — spart
bei Bonus-Material-Discs Stunden.
5. **Auth vor schreibende Endpoints** + Login-Flow im UI (JWT existiert).
6. **Speicherplatz-Kachel im Dashboard** (Media/Arbeitsverzeichnis als
Balken — /system/info liefert die Daten schon).
7. **Rip-Historie exportieren** (CSV/JSON) für die Sammlung-Übersicht.
8. **Design 2.0**: Design-Tokens statt Theme-Ternaries in jeder Zeile —
die `theme === 'dark' ? … : …`-Kaskaden sind der größte UI-Schuldenberg.
**Quelle:** Commander-Feedback nach dem ersten richtigen Arbeiten mit v3.2.
- [x] SMB-Mount-Blocker: CAP_DAC_READ_SEARCH für mount.cifs (auf der VM
reproduziert + bewiesen), Compose-Fix.
- [x] TMDB-Key-Falle: v3-Schlüssel wurden still 401 (Client konnte nur
v4-Bearer) — beide Arten unterstützt, „Verbindung prüfen" im UI.
- [x] 4K UHD als eigener Disc-Typ (≥ 55 GiB) mit eigener Farbe + Klartext-
Fehler bei Nicht-LibreDrive-Laufwerken.
- [x] Vollautomatik-Setting (Disc rein → Rip startet ohne Popup).
- [x] Job-Verwaltung: can_retry (Knopf nur bei vorhandenen Rohdaten),
Einzel-Löschen, „Erledigte aufräumen", „Alle herunterladen".
- [x] Worker: WORKER_NAME-Anzeigename + IP/ID, verwaiste Einträge löschbar.
- [x] Ripping-Tab nach Medium (Video/Audio/Allgemein), Untertitel-Klartext,
CD → Musik-Vorauswahl im Ziel-Dialog, Ordner-Verwaltung eingeklappt.
---
## Etappe 15 (24.07.2026): Restefeger — der Ideen-Katalog wird abgearbeitet
**Commander-Auftrag:** „Arbeite alles ab, abgesehen von Auth — das ist
irrelevant und kann komplett raus."
- [x] **AUTH KOMPLETT ENTFERNT** (Commander-Entscheid): /token- und
/api-keys-Endpoints, auth.py, test_auth.py, passlib/bcrypt/PyJWT,
JWT_SECRET_KEY-Pflicht — alles raus (KONZEPT §10). Der Schnellstart
braucht keine .env-Pflichtwerte mehr. Rate-Limit pro IP bleibt.
- [x] **Serien-Staffel-Flow**: Im Rip-Dialog Serienname + Staffel →
Ablage `<Serie>/Season NN`; tvshow.nfo + poster.jpg landen im
Serien-Ordner (werden bei Staffel 2 nicht überschrieben).
- [x] **Episoden-Erkennung per Laufzeitabgleich** (ARM-Wunde #395):
Datei-Laufzeiten (HandBrake-Scan) gegen TMDB-Episoden-Laufzeiten,
ordnungserhaltend; komplette Staffel auf einer Disc geht auch bei
uniformen Laufzeiten. Umbenannt wird NUR bei eindeutiger Zuordnung
(„Serie S01E02.mkv"), sonst bleiben die Namen + ehrliches Log.
- [x] **Jellyfin/Emby-Bibliotheks-Refresh** nach jedem fertigen Rip
(POST /Library/Refresh, X-Emby-Token) — URL/Key + Test-Knopf in den
Einstellungen. Die Null-Klick-Kette Disc→Bildschirm steht.
- [x] **Duplikat-Warnung**: Disc-Fingerabdruck gegen die Job-Historie —
Hinweis auf der Disc-Karte, Vollautomatik überspringt Duplikate.
- [x] **„Nur Hauptfilm" ECHT**: das Setting war wirkungslos — jetzt
Info-Lauf → längster Titel → nur der wird gerippt; pro Rip im
Dialog übersteuerbar. (Volle Track-Tabelle bleibt Ausbaustufe.)
- [x] **Deutsche Texte für OMDb-Treffer** via TMDB /find (IMDb-ID → de-DE).
- [x] **Speicherplatz in der Dashboard-Leiste** (amber unter 60 GB frei).
- [x] **CSV-Export** der Job-Historie (Semikolon+BOM, Excel-tauglich).
- [x] **Metadaten-Seite entfernt** (+ Placebo-Endpoints /metadata/lookup
und /metadata/confirm — lookup scannte ein Dummy-Device).
- [x] **Doppel-Jahr-Fix** („X (2009) (2009)" in Log/Ordnernamen).
- [x] **Remote-Worker-Blocker**: redis/postgres waren nie veröffentlicht —
kein Remote-Worker konnte sich je verbinden. Ports 6379/5432 jetzt
offen (Heimnetz-Kompromiss, dokumentiert) + API_URL für Worker.
---
## Etappe 16 (24.07.2026): Track-Tabelle + nativer Windows-Worker + Anleitung
- [x] **Volle Titel-Auswahl vor dem Rip**: scan_tracks-Worker-Task,
Polling-Endpoints, Tabelle (Dauer/Größe/Kapitel, Vorauswahl ≥ 5 min)
im Rip-Dialog, Multi-Titel-Rip (ein makemkvcon-Aufruf je Titel,
Fortschritt anteilig). Parser mit Tests.
- [x] **Nativer Windows-Worker ohne Docker**: install.ps1 + Worker-Code
werden von der Rippy-Instanz selbst serviert (/worker-setup/*);
HandBrakeCLI 1.9.2 vom offiziellen GitHub-Release; celery
--pool=solo -Q transcode; optional Autostart. UI bietet Linux- und
Windows-Variante. E2E auf echtem Windows-PC bewiesen.
- [x] **Anleitungs-Tab**: Rippy erklärt sich selbst (Disc-Weg, Serien,
NAS, Media-Server, Benachrichtigungen, Key, Worker, FAQ).
---
## Etappe 17 (25.07.2026): 4K-UHD-Schlüssel (KEYDB.cfg)
**Quelle:** Messung am 25.07. live auf der Rippy-VM im Worker-Container.
Eine 4K-UHD (Akira, MKB v76, Pressung Dezember 2020) scheitert an „The
volume key is unknown for this disc" — obwohl makemkvcon „Using LibreDrive
mode (v06.3)" und „Using direct disc access mode" meldet, die Disc liest
und den AACS-Dump ablegt (Meldung 3332). Das Debug-Log geht ohne einen
einzigen Netz-Versuch von „Loaded content hash table" direkt auf den
Fehler; `_private_data.tar` enthielt nur die Index-Datei und keine einzige
`hkd_*.bin`; auch mit gelöschter `update.conf` (Meldung 5074 belegt den
Web-Kontakt) und `app_UpdateEnable = "1"` kam kein Schlüssel; die
Forum-Schlüssel-Server `hkdata.fairuse.org` und `hkdata.crabdance.com`
lösen weltweit nicht mehr auf. **Fazit: Ein MakeMKV-Update löst das
nicht** (das behauptete v3.3 — dort richtiggestellt). Der einzige heute
funktionierende Weg ist eine `KEYDB.cfg` im MakeMKV-Datenverzeichnis.
> ⚠️ **Nachtrag am selben Tag (siehe Etappe 18): Die letzte Folgerung war
> falsch.** Die beiden toten Hostnamen stammen aus alten Forumsbeiträgen und
> werden von MakeMKV längst nicht mehr benutzt — der Dienst lebt. Richtig
> ist: `makemkvcon` unter **Linux** fragt nie nach Schlüsseln, die
> **Windows**-Version schon. Alles hier Gebaute bleibt richtig und nötig,
> nur die `KEYDB.cfg` ist nicht der Haupt-, sondern der Ersatzweg.
**Gebaut:**
- [x] **Persistentes Datenverzeichnis**: `${MAKEMKV_DATA_HOST:-/srv/rippy/makemkv}`
vom Host gemountet — Worker `/root/.MakeMKV`, API `/app/makemkv-data`,
beide mit `MAKEMKV_DATA_DIR`. `KEYDB.cfg` und AACS-Dumps überleben
jeden Rebuild. `.env.example` erklärt die Variable.
- [x] **entrypoint.sh entschärft**: `settings.conf` wird ergänzt statt
überschrieben (der Beta-Key hatte sonst alles andere gelöscht),
`app_UpdateEnable = "1"` gesetzt.
- [x] **Zwillings-Modul `makemkv_daten.py`** (identisch in `docker/api/`
und `docker/worker/`) als einzige Wahrheit über das Verzeichnis:
Status lesen, Inhalt prüfen, atomar schreiben, löschen, Dumps
auflisten — alles reine Funktionen, damit die Ampel sie ohne
Postgres/Redis testen kann.
- [x] **API**: `GET/POST/DELETE /system/keydb`, `GET /system/aacs-dumps`
und `GET /system/aacs-dumps/{dateiname}`. Der Inhalt kommt bewusst
als JSON-Body — es gibt kein `python-multipart`, ein Endpunkt mit
`UploadFile`/`File()` würde die API beim Import töten.
- [x] **UI (Einstellungen → System)**: Status der `KEYDB.cfg` (Pfad,
Größe, Anzahl Disc-Einträge, Datum), Inhalt einfügen, entfernen,
AACS-Dumps herunterladen — ohne SSH auf die VM.
- [x] **MakeMKV redet endlich**: `parse_msg()` in `ripping.py` + Log-Callback
in `tasks.py` schreiben MakeMKV-Meldungen ins Rippy-Log (gedrosselt:
Code 1003 raus, keine Wiederholungen, max. 40 je Rip). UHD-Fehlertext
ehrlich neu geschrieben; `caps.py` meldet `keydb: ja | nein | unbekannt`.
- [x] **Doku nachgezogen**: README (UHD-Voraussetzungen, System-Panel,
`MAKEMKV_DATA_HOST`, Bereitstellung), SAVEPOINT v3.10 inkl.
Richtigstellung von v3.3, KONZEPT §8 + §10.
**Offen aus dieser Runde:**
- [ ] **Der Nachweis mit einer echten `KEYDB.cfg` steht aus.** Zum
Zeitpunkt der Änderung lag keine Datei vor, die den Akira-Schlüssel
enthält — belegt sind der Befund und die Mechanik, NICHT ein
erfolgreicher UHD-Rip.
- [ ] Damit bleibt auch der volle Transcode-E2E an einer UHD weiter offen
(siehe SAVEPOINT v3.7) — an normalen BD/DVD ist die Kette bewiesen.
**Nachtrag zu „Offen":** Beide Punkte sind mit Etappe 18 erledigt — Akira
ging auf der VM auf, allerdings über den Schlüsselspeicher statt über eine
`KEYDB.cfg`.
**Ausdrücklich nicht gebaut (und wird es auch nicht):** Rippy liefert
keine Disc-Schlüssel mit, lädt keine herunter und verteilt keine. Es
stellt nur den Platz für eine Datei bereit, die der Nutzer selbst
mitbringt, und zeigt ehrlich an, was dort liegt.
---
## Etappe 18 (25.07.2026): 4K-UHD gelöst — Schlüsselspeicher statt KEYDB.cfg
**Quelle:** Einwand des Commanders („wenn ich MakeMKV lokal auf meinem
Windows-PC installiere, würde es SOFORT gehen — wir übersehen etwas
Gewaltiges"). Er hatte recht. Gegenprobe mit demselben Laufwerk und
derselben Disc an einem Windows-PC:
| | Linux (Worker) | Windows |
|---|---|---|
| Verbindungen beim Disc-Öffnen | **keine einzige** | 185.84.108.20:443 |
| Meldung 3338 „Downloading latest HK" | nie | ja |
| `_private_data.tar` | 2048 B, 0 Schlüssel | 6,4 MB, 604 Schlüssel |
| Disc | „volume key is unknown" | **TCOUNT:5, geht auf** |
Gegengeprüft mit leerem UND gefülltem Speicher, mit und ohne `--noscan`,
mit `dev:/dev/sr0` und `disc:0`, mit gelöschter `update.conf`: Linux
fragt nie. Die Meldungsvorlage „Downloading latest %1 to %2 ..." steckt
sehr wohl im Linux-Binary — sie löst nur nicht aus. Gleiches Symptom im
MakeMKV-Forum, seit Jahren offen (t=25782, t=34022).
**Damit ist die Diagnose aus Etappe 17 („der Schlüssel-Kanal ist tot")
widerlegt.** Sie stützte sich auf zwei Hostnamen aus alten Forumsbeiträgen,
die MakeMKV längst nicht mehr benutzt.
**Gebaut:**
- [x] **Schlüsselspeicher im Modul**: `zaehle_schluessel`,
`private_data_pruefen`, `schluesselspeicher_status`,
`private_data_schreiben` in `makemkv_daten.py` (beide Zwillinge).
Die Prüfung lehnt einen Speicher OHNE `hkd_*.bin` ab — sonst lädt
jemand den leeren Vorrat einer frischen Installation hoch, es ändert
sich nichts, und niemand versteht warum.
- [x] **API**: `GET /system/keystore` und `POST /system/keystore`. Der
Rohkörper der Anfrage IST die Datei — binär, deshalb kein JSON und
kein Base64; Multipart kann die API ohnehin nicht.
- [x] **UI**: neuer Block „Disc-Schlüssel für 4K-UHD" ÜBER dem
KEYDB-Block, mit Schlüssel-Anzahl, Upload und Schritt-für-Schritt-
Anleitung für den Windows-Umweg. KEYDB.cfg ist jetzt als Notnagel
beschriftet. Worker-Plakette zeigt die Schlüssel-Anzahl.
- [x] **Fehlertext** in `tasks.py` sagt den Windows-Weg an und nennt die
Anzahl bekannter Schlüssel dieses Workers.
- [x] **`caps.py`** meldet `schluessel` je Worker.
- [x] **Alle Falschaussagen korrigiert**: UI (3 Stellen), Anleitung (2),
README (3), KONZEPT §8 + §10, `makemkv_daten.py`-Modulkopf,
Worker-Dockerfile, `makemkv_key.py`.
**Bewiesen:** Nach Übernahme des Windows-Schlüsselspeichers öffnet
`makemkvcon` auf der VM die Akira-UHD — „Operation successfully
completed", `TCOUNT:5`, fünf Titel, identisch zum Windows-Ergebnis.
**Das ist der erste belegte UHD-Disc-Zugriff auf der Rippy-Maschine.**
**Offen aus dieser Runde:**
- [ ] Voller UHD-Rip inklusive Transcode-E2E (nur der Disc-Zugriff ist
belegt, nicht die komplette Kette bis zur fertigen Datei).
- [ ] Ob sich der Abruf unter Linux doch anstoßen lässt, ist ungeklärt —
der Code ist im Binary vorhanden. Bis dahin bleibt der Windows-Umweg.
---
## Etappe 19 (25.07.2026): Preset je Disc-Typ
**Quelle:** Rückfrage des Commanders beim ersten echten UHD-Rip („merkt
Rippy eigentlich, wenn es eine UHD-Disc ist, und wendet direkt das
4K-Preset an?"). Antwort war: nein. Die Kompression fragte den Disc-Typ
gar nicht — ein globales `transcodePreset` galt für alles, live eingestellt
`HQ 1080p30 Surround`. Der laufende 4K-Rip wäre danach auf 1080p
heruntergerechnet und der Rohschnitt gelöscht worden (`keepOriginal: False`).
**Gebaut:**
- [x] **`preset_fuer(disc_type, einstellungen)`** in `ripping.py` — pure
Funktion, drei Tests. Reihenfolge: Preset des Disc-Typs → allgemeines
`transcodePreset``DEFAULT_HB_PRESET`. Bestandsinstallationen
ändern ihr Verhalten NICHT, solange die neuen Felder ungespeichert sind.
- [x] **`transcode_files`** holt den Disc-Typ aus dem Job-Datensatz und
schreibt ihn mit ins Log („Disc-Typ 'uhd', Preset '…'").
- [x] **UI**: drei Auswahlfelder (DVD / Blu-ray / 4K-UHD) statt einem, mit
Erklärung, warum 4K auf ein 2160p-Preset gehört. Preset-Namen aus
`HandBrakeCLI --preset-list` im Worker-Image belegt, nicht geraten.
- [x] **Sofortmaßnahme am laufenden Job**: `keepOriginal` auf `True`, damit
der 4K-Rohschnitt die Kompression überlebt.
**Offen aus dieser Runde:**
- [ ] **Deploy steht aus** — er würde den laufenden Akira-Rip abbrechen.
Erst nach Abschluss des Jobs deployen, dann bei Bedarf „Neu
komprimieren" mit dem 4K-Preset.
---
## Rippy v2 — Etappen V2-0 bis V2-7 (Plan vom 28.08.2026)
**Vollständige Spezifikation: `KONZEPT-V2.md`.** Hier stehen nur die Etappen
und ihre Abnahmekriterien.
**Ziel:** drei Betriebsmodi statt eines — Docker (wie heute, aufgeräumt), eine
native Windows-App ohne Docker, eine Headless-Linux-Anwendung. Alle drei mit
demselben Webinterface, alle drei aus EINEM Kern.
**Grundregel für den ganzen Weg:** Jede Etappe endet mit grüner Ampel und einem
lauffähigen System. v1 läuft bis V2-5 produktiv weiter — auf der VM liegen echte
Medien.
### V2-0: Monorepo — ein Paket statt Zwillingen
- [ ] `src/rippy/` als gemeinsames Paket anlegen (api UND worker importieren daraus)
- [ ] Die byte-identischen Zwillinge zusammenführen: `detection.py`,
`makemkv_daten.py`, `notify.py` — je zweimal im Repo
- [ ] Tests wandern mit; `test_zwillinge_sind_byteweise_identisch` wird
gegenstandslos und weicht einem Test, der die EINE Quelle prüft
- [ ] Beide Dockerfiles kopieren `src/rippy`, `PYTHONPATH` gesetzt
- **Verhalten unverändert.** Kein Funktionsgewinn, reine Struktur.
- **Fertig, wenn:** Ampel grün, `docker compose up` verhält sich wie vorher,
kein Modul mehr doppelt im Repo.
### V2-1: Ports einziehen
- [ ] `Store`, `Queue`, `Bus`, `Drives` als Python-`Protocol`
- [ ] v1-Verhalten läuft über die Treiber Postgres / Celery / Redis / Linux
- [ ] Kein Funktionsgewinn — reine Verdrahtung
- **Fertig, wenn:** Ampel grün und ein Rip auf der VM durchläuft.
### V2-2: Standalone (SQLite + lokale Queue)
- [ ] SQLite-Treiber mit WAL, `busy_timeout`, ein Schreiber-Kontext
- [ ] Alembic statt handgeschriebener `ALTER TABLE … IF NOT EXISTS`
(das ist Postgres-only und bricht auf SQLite)
- [ ] LocalQueue: Auftrags-Tabelle + Lease + Prozesspool, kein Broker
- [ ] Lease ersetzt `zombies.py` — abgelaufene Lease = Auftrag ist frei
- [ ] `rippyd --profil standalone`
- **Fertig, wenn:** ein DVD-Rip komplett ohne Postgres, Redis und Docker läuft.
### V2-3: Echtzeit — Polling raus
- [ ] Bus-Treiber (asyncio in-process / Redis Pub/Sub)
- [ ] `GET /api/v2/events` als SSE-Strom, `snapshot` beim Verbinden,
lückenlose `seq` für Wiederaufnahme
- [ ] UI auf einen `useEventStream`-Haken; die neun `setInterval` fliegen raus
- [ ] `test_grenze_deckt_die_eigene_last_ab` auf die neuen Zahlen ziehen
- **Fertig, wenn:** Grundlast ≈ 0/min gemessen (heute ≈ 133/min bei einem Tab
plus Worker) UND ein Verbindungsabriss keine Liste leert.
### V2-4: Windows nativ
- [x] `drives/windows.py` — Win32 statt ioctl (`IOCTL_STORAGE_CHECK_VERIFY2`,
`IOCTL_STORAGE_MEDIA_REMOVAL`, `IOCTL_STORAGE_EJECT_MEDIA`,
MMC `GET CONFIGURATION` für den Disc-Typ)
- [ ] Disc-Einwurf per `WM_DEVICECHANGE` statt Polling — **offen**, läuft
vorerst über den Poll aus `drives/detection.py`
- [x] Dienst + Fenster als GETRENNTE Prozesse; **WebView2-Fenster**
(`fenster.py`, Entscheid 4 in `KONZEPT-V2.md` § 10)
- [x] Eintrag in „Programme und Features" und im Taskmanager als `Rippy.exe`
(ausdrücklicher Wunsch des Commanders)
- [x] Desktop-Symbol und Startmenü-Eintrag, im Setup abschaltbar
- [x] Werkzeug-Erkennung und -Beschaffung (`tools/katalog.py`,
`tools/beschaffen.py`) — Rippy findet, holt und aktualisiert
HandBrake/MakeMKV selbst
- [x] **Das Setup richtet die Werkzeuge wirklich ein** (`tools/einrichten.py`,
Entscheid 5) — HandBrakeCLI liegt im Paket (GPL-2), MakeMKV wird beim
Einrichten vom Hersteller geholt. Ein Setup, dem ein Pflichtwerkzeug
fehlt, meldet das im Klartext statt Erfolg.
- [x] Symbol mit allen Größen, die Windows holt (16/32/48/256) — vorher steckte
nur 256×256 in der `.ico`, und Desktop, Startmenü und Taskleiste zeigten
ein leeres Blatt
- [x] **Ein echtes Setup** (`einrichtung.py`, `setup_fenster.py`): acht
Voraussetzungs-Prüfungen, Zielordner UND Ablage zur Wahl, Port,
Autostart/Verknüpfungen/Werkzeuge als Schalter. Vorher installierte der
Doppelklick stillschweigend und öffnete das Fenster.
- [x] **Die Oberfläche kennt ihren Betrieb** (`betrieb.py`, `GET /betrieb`,
`useBetrieb.tsx`): keine Worker-Zähler, keine Container-Platte, kein
`docker compose ps` mehr im Windows-Client — und der Docker-Betrieb
behält alles.
- [ ] Standby blocken via `SetThreadExecutionState`, ohne `ES_DISPLAY_REQUIRED`
**offen**
- **Fertig, wenn:** auf einem frischen Win-11-Rechner gilt: Installer →
Disc rein → MKV raus. Und der UHD-Schlüssel kommt automatisch.
**Noch offen:** ein echter Rip auf Windows ist ungeprüft — das Laufwerk
hängt an der VM.
> **Abweichung vom Plan, bewusst und mit Folgen.** Statt Nuitka `--standalone`
> (one-dir) + Inno Setup wurde **PyInstaller onefile** genommen: ein Programm,
> drei Betriebsarten (`RippySetup.exe`, `--dienst`, `--deinstallieren`), kein
> zweites Werkzeug in der Kette.
>
> Der Preis stand oben schon im Plan — *„ein Onefile-Paket entpackt sich bei
> jedem Start neu nach `%TEMP%`"* — und er ist am 28.08.2026 fällig geworden:
> Ein Dienst lief eine Stunde, `/api/health` gab 200, `/` gab **404**. Vom
> Entpack-Verzeichnis des laufenden Prozesses waren 31 statt 44 Einträge übrig,
> `ui` und `api` fehlten. Die API meldete sich gesund, während die Oberfläche
> weg war.
>
> **Gegenmaßnahme:** Der Installer legt die Oberfläche als Kopie NEBEN das
> Programm (`windows_app.ui_auspacken`), und `daemon._ui_pfad()` nimmt diese
> Kopie vor dem Entpack-Verzeichnis. Zwei Tests halten das fest. Sollte sich
> derselbe Ausfall an den API-Modulen zeigen, ist one-dir die richtige Antwort
> — dann ist diese Abweichung zurückzunehmen.
### V2-5: Docker neu
- [ ] EIN Image, drei Profile (`standalone`, `api`, `node`)
- [ ] GPU-Durchreichung: `/dev/dri` für QSV/VAAPI, `runtime: nvidia` für NVENC
- [ ] **Host-Mounts statt Container-Mounts** (Entscheid 28.08.2026)
- [ ] Multi-Arch; ARM64 ist Encode-/API-Knoten (MakeMKV hat kein ARM64-Binary)
- **Fertig, wenn:** All-in-One und verteilt laufen und `SYS_ADMIN`,
`DAC_READ_SEARCH`, `apparmor:unconfined` weg sind.
### V2-6: CLI & Pakete
- [ ] `rippy status / drives / scan / rip / queue / logs --follow / doctor`
- [ ] `rippy doctor` = die Prüfphase aus `install.sh` als Befehl (erst alles
prüfen, dann berichten, nichts ändern)
- [ ] systemd-Unit mit `SupplementaryGroups=cdrom` und `DeviceAllow` für
block-sr UND char-sg (ohne sg findet MakeMKV kein Laufwerk)
- [ ] udev-Regel für echte Disc-Ereignisse; ioctl-Poll bleibt Rückfallebene
- [ ] `.deb` / AppImage
- **Fertig, wenn:** ein Headless-Server ohne Browser bedienbar ist.
### V2-7: Neue Features
- [ ] Multi-Drive Parallel-Ripping (Rip parallel, **Schlüssel-Phase
serialisiert** — vorher an zwei Laufwerken MESSEN, nicht annehmen)
- [ ] Zero-Click gegen Interaktiv, je Laufwerk und Disc-Typ
- [ ] Auto-Presets nach gemessener Hardware (Vorschlag, kein Zwang)
- [ ] Ton-/Untertitel-Regelwerk (Originalton, Wunschsprachen, erzwungene
Untertitel behalten, Kommentarspuren verwerfen, HD-Ton durchreichen)
- [ ] **Schlüsselkette in drei Stufen** (Entscheid 28.08.2026, `KONZEPT.md` § 10)
- [ ] Anime über AniList zusätzlich zu Jikan
- [ ] Medienserver-Refresh als Auftrag MIT Wiederholung (heute still scheiternd)
- [ ] FFmpeg-Direktpfad für reines Remuxen
- **Fertig, wenn:** je Feature ein Nachweis vorliegt.
---
## Ideen-Katalog (Rest) — bewusst offen
> **Stand 28.08.2026:** Punkt 3 (Kodi-Refresh) und Punkt 4 (Windows-Worker als
> Dienst) sind in den v2-Plan aufgegangen — Punkt 4 ist V2-4, Punkt 3 steckt in
> V2-7 („Medienserver-Refresh"). Punkt 2 (AI-Box als Transcode-Worker) wird von
> V2-5 abgedeckt, sobald der Host-Mount-Weg steht.
1. **Design 2.0** — an Gemini übergeben (24.07.2026). Vollständiges
Briefing: `docs/DESIGN-2.0-BRIEFING.md`. Arbeitsbranch: `design-2.0`
(deployt bewusst NICHT, nur `main` wird befördert). Kern: 428
`theme === 'dark'`-Ternaries → Tailwind-`dark:` + UI-Primitives,
Optik-Modernisierung, ohne Funktions-/Text-Änderungen. Der neue
Anleitungs-Tab gehört mit in den Feinschliff.
2. **AI-Box als VAAPI-Transcode-Worker**: Ports sind offen, Compose steht
(deploy/remote-transcode-worker.yml) — es fehlt nur der NFS/SMB-Export
der Rippy-Ablage an die AI-Box (Infra-Entscheid auf der VM).
3. **Kodi-Bibliotheks-Refresh** (JSON-RPC VideoLibrary.Scan) analog zu
Jellyfin/Emby.
4. **Windows-Worker als echter Dienst** (statt start-worker.bat/onlogon):
z. B. via NSSM oder PyInstaller-Paket — Komfort-Ausbau der jetzt
funktionierenden nativen Variante.
+3692 -1
View File
File diff suppressed because it is too large Load Diff
+135
View File
@@ -0,0 +1,135 @@
# Beweise — die Messungen zu KONZEPT-WINDOWS.md § 3
Diese zwei Skripte sind die Grundlage für die Entscheidung, Rippy v5 in
TypeScript/Node zu bauen. Sie beantworten die einzige Frage, an der das ganze
Konzept hängt:
> **Kann Node überhaupt alles, was Rippy am Laufwerk braucht?**
Wäre die Antwort nein gewesen, wäre das Konzept wertlos gewesen. Deshalb sind
sie zuerst gelaufen — vor der ersten Zeile Konzept.
`AGENTS.md` Regel D: *„Externe Schnittstellen NIE aus dem Kopf."*
---
## Nachstellen
```
npm install koffi
node laufwerk.js
```
Gemessen am 30.08.2026 mit Node v24.19.0, koffi 3.1.6, an einem
HL-DT-ST BD-RE BU40N (USB) mit eingelegter Blu-ray.
---
## `laufwerk.js` — Win32-Laufwerkszugriff
Ruft dieselben Steuercodes auf wie `src/rippy/drives/win_ioctl.py` im
Docker-Zweig. **Nur lesend** — kein Auswerfen, kein Verriegeln.
```
1. GetLogicalDrives + GetDriveTypeW -> optische Laufwerke: [ 'G' ]
2. CreateFileW \\.\G: (Zugriff 0) -> offen
CreateFileW \\.\G: (GENERIC_READ) -> offen
3. IOCTL_STORAGE_QUERY_PROPERTY -> Hersteller: HL-DT-ST | Modell: BD-RE BU40N
| Rev: 1.03 | Serial: 0025114C0149
4. IOCTL_STORAGE_CHECK_VERIFY2 -> Medium eingelegt
5. IOCTL_CDROM_DISK_TYPE -> Win32-Fehler 50
6. IOCTL_DISK_GET_LENGTH_INFO -> 33.759.690.752 Bytes (33,76 GB) => Blu-ray
```
**Punkt 5 ist kein Fehlschlag.** Fehler 50 ist `ERROR_NOT_SUPPORTED` — genau
das, was der Python-Treiber an diesem Laufwerk auch sieht (`SAVEPOINT.md`,
v4.0-rc11, Abschnitt „Das Laufwerk"). Node verhält sich identisch. Die Lehre
steht im alten Code und gilt weiter: **Die Disc-Einordnung darf sich nicht auf
`IOCTL_CDROM_DISK_TYPE` verlassen — die Größe ist der verlässliche Weg.**
Punkt 2 zeigt die Unterscheidung, die in rc11 teuer war: `Zugriff 0` fragt das
**Gerät**, `GENERIC_READ` fragt das **Medium**. Bei einer gestörten Disc
scheitert das zweite und das erste geht weiter — wer nur eins probiert, hält
ein antwortendes Laufwerk für tot.
---
## `leine.js` — die Prozess-Leine (Job Object)
Stellt den Befund aus `SAVEPOINT.md` v4.0-rc10 nach: Windows räumt
Kindprozesse **nicht** auf. Ein hart beendeter Rippy hinterlässt ein
`makemkvcon`, das das Laufwerk festhält, und jeder spätere Rip scheitert.
Das Skript setzt eine Arbeitsgruppe mit `JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE`,
startet ein langlebiges Kind und lässt sich dann hart abschießen —
`taskkill /F` **ohne** `/T`, also genau das, was bei einem Absturz und beim
Drüber-Installieren passiert.
```
1. CreateJobObjectW -> Arbeitsgruppe angelegt
2. SetInformationJobObject -> KILL_ON_JOB_CLOSE gesetzt
3. AssignProcessToJobObject -> dieser Prozess hängt in der Gruppe
4. Kindprozess gestartet, PID 16040
vor dem Abschuss: Eltern lebt: True Kind lebt: True
taskkill /F /PID 29488 -> ERFOLGREICH
danach: Eltern lebt: False Kind lebt: False
```
Nachstellen (PowerShell):
```powershell
$p = Start-Process node -ArgumentList "leine.js" -PassThru -RedirectStandardOutput out.txt
Start-Sleep 3
$kind = (Select-String -Path out.txt -Pattern 'KIND-PID=(\d+)').Matches[0].Groups[1].Value
taskkill /F /PID $p.Id
Start-Sleep 2
Get-Process -Id $kind -ErrorAction SilentlyContinue # muss LEER sein
```
---
## `sqlite-main.js` + `sqlite-kern.js` — node:sqlite in Electron
Beantwortet die Frage, die in der ersten Fassung des Konzepts als ⚠️ offen
stand: Electron baut sein Node mit eigenen Flags — ist `node:sqlite` dort
überhaupt vorhanden?
Gemessen am 30.08.2026 mit **Electron 44.0.0**, und zwar im
**utilityProcess** — dem Kontext, in dem Rippy v5 seine Datenbank betreiben
wird (`kern/speicher/db.ts`), nicht bloß im Node-Modus der Binary:
```
KERN-ANTWORT: {"ok":true,"wert":"geht","node":"24.18.1"}
Kern beendet mit 0
```
**Antwort: ja.** Die im Konzept vorgesehene Rückfallebene `better-sqlite3`
wird nicht gebraucht. (Zur Einordnung: In Node 24.19.0 pur war dieselbe
Messung zuvor ebenfalls grün.)
Nachstellen:
```
npm install electron@44 --no-save
node node_modules/electron/install.js
./node_modules/electron/dist/electron.exe sqlite-main.js
```
Die zweite Zeile ist kein Versehen — siehe nächster Abschnitt.
---
## npm 11 blockiert Install-Skripte — und das trifft Electron selbst
```
npm warn allow-scripts koffi@3.1.6 (install: node ./cnoke.cjs -P . --prebuild --release)
```
koffi lädt trotzdem — es bringt vorgebaute Binärdateien mit. **Electron
trifft die Sperre härter:** Sein Install-Skript lädt die eigentliche
Programmdatei herunter; wird es geblockt, liegt nach `npm install` ein
Paket **ohne `dist/electron.exe`** da, und nichts startet. Am 30.08.2026
beim sqlite-Beweis selbst hineingelaufen; `node node_modules/electron/install.js`
holt die Binary nach. Beides gehört in die Bau-Anleitung, sonst sucht eines
Tages jemand an der falschen Stelle.
+109
View File
@@ -0,0 +1,109 @@
// Beweis-Test: Kann Node/koffi dieselben Win32-Aufrufe wie Rippys Python-Treiber?
// NUR LESEND — kein Auswerfen, kein Verriegeln.
const koffi = require('koffi');
// ── CTL_CODE aus winioctl.h, eins zu eins wie in src/rippy/drives/win_ioctl.py
const ctl = (typ, fn, methode, zugriff) =>
((typ << 16) | (zugriff << 14) | (fn << 2) | methode) >>> 0;
const FILE_DEVICE_CD_ROM = 0x02, FILE_DEVICE_DISK = 0x07, FILE_DEVICE_MASS_STORAGE = 0x2d;
const IOCTL_STORAGE_CHECK_VERIFY2 = ctl(FILE_DEVICE_MASS_STORAGE, 0x0200, 0, 0);
const IOCTL_STORAGE_QUERY_PROPERTY = ctl(FILE_DEVICE_MASS_STORAGE, 0x0500, 0, 0);
const IOCTL_CDROM_DISK_TYPE = ctl(FILE_DEVICE_CD_ROM, 0x0010, 0, 0);
const IOCTL_DISK_GET_LENGTH_INFO = ctl(FILE_DEVICE_DISK, 0x0017, 0, 1);
const kernel32 = koffi.load('kernel32.dll');
const GetLogicalDrives = kernel32.func('uint32_t __stdcall GetLogicalDrives()');
const GetDriveTypeW = kernel32.func('uint32_t __stdcall GetDriveTypeW(str16 lpRootPathName)');
const CreateFileW = kernel32.func('void* __stdcall CreateFileW(str16 lpFileName, uint32_t dwDesiredAccess, uint32_t dwShareMode, void *lpSecurityAttributes, uint32_t dwCreationDisposition, uint32_t dwFlagsAndAttributes, void *hTemplateFile)');
const CloseHandle = kernel32.func('bool __stdcall CloseHandle(void *hObject)');
const GetLastError = kernel32.func('uint32_t __stdcall GetLastError()');
const DeviceIoControl = kernel32.func('bool __stdcall DeviceIoControl(void *hDevice, uint32_t dwIoControlCode, void *lpInBuffer, uint32_t nInBufferSize, _Out_ void *lpOutBuffer, uint32_t nOutBufferSize, _Out_ uint32_t *lpBytesReturned, void *lpOverlapped)');
const GENERIC_READ = 0x80000000, FILE_SHARE_READ = 1, FILE_SHARE_WRITE = 2, OPEN_EXISTING = 3;
const DRIVE_CDROM = 5;
// ── 1. Laufwerke finden (die Windows-Entsprechung von glob /dev/sr*)
const maske = GetLogicalDrives();
const optische = [];
for (let i = 0; i < 26; i++) {
if (!(maske & (1 << i))) continue;
const buchstabe = String.fromCharCode(65 + i);
if (GetDriveTypeW(buchstabe + ':\\') === DRIVE_CDROM) optische.push(buchstabe);
}
console.log('1. GetLogicalDrives + GetDriveTypeW -> optische Laufwerke:', optische);
if (!optische.length) { console.log(' Kein optisches Laufwerk — Test endet hier.'); process.exit(0); }
const lw = optische[0];
// ── 2. Gerät öffnen. Zugriff 0 = nur das GERÄT fragen, nicht das Medium.
// Genau die Unterscheidung aus SAVEPOINT rc11: Bei gestörtem Medium
// scheitert GENERIC_READ, Zugriff 0 geht weiter.
function oeffnen(zugriff) {
const h = CreateFileW('\\\\.\\' + lw + ':', zugriff,
FILE_SHARE_READ | FILE_SHARE_WRITE, null, OPEN_EXISTING, 0, null);
const adr = koffi.address(h);
// INVALID_HANDLE_VALUE ist -1, als vorzeichenlose 64-Bit-Zahl 0xFFFF...
if (adr === 0n || adr === 0xffffffffffffffffn) return { h: null, fehler: GetLastError() };
return { h, fehler: 0 };
}
const ohneMedium = oeffnen(0);
console.log(`2. CreateFileW \\\\.\\${lw}: (Zugriff 0) -> ` +
(ohneMedium.h ? 'offen' : 'Win32-Fehler ' + ohneMedium.fehler));
const mitLesen = oeffnen(GENERIC_READ);
console.log(` CreateFileW \\\\.\\${lw}: (GENERIC_READ) -> ` +
(mitLesen.h ? 'offen' : 'Win32-Fehler ' + mitLesen.fehler));
const h = ohneMedium.h;
if (!h) { console.log(' Gerät nicht ansprechbar — Test endet hier.'); process.exit(0); }
const rueck = Buffer.alloc(4);
// ── 3. Hersteller/Modell/Serial (STORAGE_DEVICE_DESCRIPTOR)
const anfrage = Buffer.alloc(12);
anfrage.writeUInt32LE(0, 0); // PropertyId = StorageDeviceProperty
anfrage.writeUInt32LE(0, 4); // QueryType = PropertyStandardQuery
const antwort = Buffer.alloc(1024);
if (DeviceIoControl(h, IOCTL_STORAGE_QUERY_PROPERTY, anfrage, 12, antwort, 1024, rueck, null)) {
const text = (off) => {
const start = antwort.readUInt32LE(off);
if (!start || start >= antwort.length) return '';
let ende = start; while (ende < antwort.length && antwort[ende] !== 0) ende++;
return antwort.toString('latin1', start, ende).trim();
};
console.log('3. IOCTL_STORAGE_QUERY_PROPERTY -> Hersteller:', text(12),
'| Modell:', text(16), '| Rev:', text(20), '| Serial:', text(24));
} else {
console.log('3. IOCTL_STORAGE_QUERY_PROPERTY -> Win32-Fehler', GetLastError());
}
// ── 4. Liegt ein Medium drin? (ERROR_NOT_READY = 21 heißt: leer)
const okVerify = DeviceIoControl(h, IOCTL_STORAGE_CHECK_VERIFY2, null, 0, null, 0, rueck, null);
console.log('4. IOCTL_STORAGE_CHECK_VERIFY2 -> ' +
(okVerify ? 'Medium eingelegt' : 'kein Medium (Win32-Fehler ' + GetLastError() + ')'));
// ── 5. Audio- oder Datenspur?
const typBuf = Buffer.alloc(1);
if (DeviceIoControl(h, IOCTL_CDROM_DISK_TYPE, null, 0, typBuf, 1, rueck, null)) {
const t = typBuf[0];
console.log('5. IOCTL_CDROM_DISK_TYPE -> ' +
(t === 1 ? 'Audio-CD' : t === 2 ? 'Daten-Disc' : 'Wert ' + t));
} else {
console.log('5. IOCTL_CDROM_DISK_TYPE -> Win32-Fehler', GetLastError());
}
// ── 6. Größe des Mediums (für die Unterscheidung DVD / BD / UHD)
const laenge = Buffer.alloc(8);
if (mitLesen.h && DeviceIoControl(mitLesen.h, IOCTL_DISK_GET_LENGTH_INFO, null, 0, laenge, 8, rueck, null)) {
const bytes = laenge.readBigUInt64LE(0);
const gb = Number(bytes) / 1e9;
console.log('6. IOCTL_DISK_GET_LENGTH_INFO -> ' + bytes + ' Bytes (' + gb.toFixed(2) + ' GB)' +
' => Einordnung: ' + (gb > 60 ? 'UHD' : gb > 9.5 ? 'Blu-ray' : gb > 1 ? 'DVD' : 'CD'));
} else {
console.log('6. IOCTL_DISK_GET_LENGTH_INFO -> Win32-Fehler', GetLastError());
}
CloseHandle(h);
if (mitLesen.h) CloseHandle(mitLesen.h);
console.log('\nAlle Handles geschlossen. Nichts ausgeworfen, nichts verriegelt.');
+50
View File
@@ -0,0 +1,50 @@
// Beweis-Test 2: Kann Node eine Windows-Arbeitsgruppe (Job Object) setzen,
// die Kindprozesse mitreisst, wenn der Elternprozess HART beendet wird?
// Das ist der Mechanismus aus SAVEPOINT v4.0-rc10 — ohne ihn ueberlebt
// makemkvcon Rippy und haelt das Laufwerk fest.
const koffi = require('koffi');
const { spawn } = require('child_process');
const kernel32 = koffi.load('kernel32.dll');
const CreateJobObjectW = kernel32.func('void* __stdcall CreateJobObjectW(void *lpJobAttributes, str16 lpName)');
const SetInformationJobObject = kernel32.func('bool __stdcall SetInformationJobObject(void *hJob, int JobObjectInformationClass, void *lpJobObjectInformation, uint32_t cbJobObjectInformationLength)');
const AssignProcessToJobObject = kernel32.func('bool __stdcall AssignProcessToJobObject(void *hJob, void *hProcess)');
const GetCurrentProcess = kernel32.func('void* __stdcall GetCurrentProcess()');
const GetLastError = kernel32.func('uint32_t __stdcall GetLastError()');
// JobObjectExtendedLimitInformation = 9 (winnt.h)
const JobObjectExtendedLimitInformation = 9;
// JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE = 0x2000 (winnt.h)
const JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE = 0x2000;
const job = CreateJobObjectW(null, null);
if (koffi.address(job) === 0n) {
console.log('CreateJobObjectW fehlgeschlagen, Win32-Fehler', GetLastError());
process.exit(1);
}
console.log('1. CreateJobObjectW -> Arbeitsgruppe angelegt');
// JOBOBJECT_EXTENDED_LIMIT_INFORMATION ist 144 Byte auf x64.
// LimitFlags liegt im eingebetteten BASIC_LIMIT_INFORMATION bei Offset 16.
const info = Buffer.alloc(144);
info.writeUInt32LE(JOB_OBJECT_LIMIT_KILL_ON_JOB_CLOSE, 16);
if (!SetInformationJobObject(job, JobObjectExtendedLimitInformation, info, 144)) {
console.log('SetInformationJobObject fehlgeschlagen, Win32-Fehler', GetLastError());
process.exit(1);
}
console.log('2. SetInformationJobObject -> KILL_ON_JOB_CLOSE gesetzt');
if (!AssignProcessToJobObject(job, GetCurrentProcess())) {
console.log('AssignProcessToJobObject fehlgeschlagen, Win32-Fehler', GetLastError());
process.exit(1);
}
console.log('3. AssignProcessToJobObject -> dieser Prozess haengt in der Gruppe');
// Ein langlebiges Kind starten — der Platzhalter fuer makemkvcon.
const kind = spawn('ping', ['-n', '300', '127.0.0.1'], { stdio: 'ignore' });
console.log('4. Kindprozess gestartet, PID ' + kind.pid);
console.log('ELTERN-PID=' + process.pid);
console.log('KIND-PID=' + kind.pid);
// Offen halten, bis uns jemand hart abschiesst.
setTimeout(() => { console.log('Zeit abgelaufen'); process.exit(0); }, 60000);
+12
View File
@@ -0,0 +1,12 @@
// Läuft als utilityProcess — der Kontext, in dem Rippy v5 seine Datenbank
// betreiben wird (kern/speicher/db.ts laut KONZEPT-WINDOWS.md § 4.2).
try {
const s = require('node:sqlite');
const db = new s.DatabaseSync(':memory:');
db.exec('CREATE TABLE t (a TEXT)');
db.prepare('INSERT INTO t VALUES (?)').run('geht');
const wert = db.prepare('SELECT a FROM t').get().a;
process.parentPort.postMessage({ ok: true, wert: wert, node: process.versions.node });
} catch (e) {
process.parentPort.postMessage({ ok: false, fehler: e.message });
}
+20
View File
@@ -0,0 +1,20 @@
// Beweis: node:sqlite funktioniert im utilityProcess von Electron 44.
// Gemessen 30.08.2026 — siehe README.md in diesem Ordner.
//
// Startet den Kern-Prozess (sqlite-kern.js) genau so, wie Rippy v5 seinen
// Kern starten wird (utilityProcess.fork), und wartet auf dessen Antwort.
const { app, utilityProcess } = require('electron');
const path = require('path');
app.whenReady().then(() => {
const kind = utilityProcess.fork(path.join(__dirname, 'sqlite-kern.js'));
kind.on('message', (antwort) => {
console.log('KERN-ANTWORT: ' + JSON.stringify(antwort));
app.exit(antwort.ok ? 0 : 1);
});
kind.on('exit', (code) => {
console.log('Kern beendet mit ' + code);
if (code !== 0) app.exit(1);
});
setTimeout(() => { console.log('TIMEOUT'); app.exit(2); }, 15000);
});
Binary file not shown.

After

Width:  |  Height:  |  Size: 282 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 42 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 224 KiB

+22
View File
@@ -0,0 +1,22 @@
"""Pytest-Setup für das ganze Repo: das gemeinsame Paket `rippy` findbar machen.
Die Ampel ruft `pytest -q` in der Repo-Wurzel auf (.gitea/workflows/ci.yml).
Ohne diesen Eintrag scheitert JEDER Import von `rippy.*` — das Paket liegt
unter `src/`, und `src/` steht in keinem Standardpfad.
Warum `src/` und nicht `rippy/` direkt in der Wurzel: Sonst würde `pytest`
beim Einsammeln in dasselbe Verzeichnis schauen, in dem auch `docker/` liegt,
und ein zufällig gleichnamiges Modul könnte gewinnen. Ein eigenes Quellen-
Verzeichnis macht die Grenze eindeutig.
Die beiden conftest.py unter docker/api und docker/worker bleiben bestehen —
sie machen die dortigen FLACHEN Modul-Importe möglich (`import ripping`,
`import db`). Beide Mechanismen greifen nebeneinander.
"""
import os
import sys
_QUELLEN = os.path.join(os.path.dirname(os.path.abspath(__file__)), "src")
if _QUELLEN not in sys.path:
sys.path.insert(0, _QUELLEN)
+102 -16
View File
@@ -1,26 +1,112 @@
#!/usr/bin/env bash
# NOTFALL-Deploy für Rippy (Normalweg = Grün-Gate: push → Ampel grün → CI
# befördert auf 'stable' → Arcane-GitSync deployt).
# Dieses Skript nur nutzen, wenn der Automat klemmt (Arcane down o. ä.).
# Deploy fuer Rippy — deployt den aktuellen 'main'-Stand auf die Ziel-VM.
# Single Source of Truth ist 'main' (kein stable-Branch); die Ampel prueft nur,
# befoerdert nichts. Vor dem Deploy selbst sicherstellen, dass die Ampel fuer den
# zu deployenden Commit GRUEN ist.
#
# Nutzt einen EIGENEN Klon (~/notfall-rippy, Branch stable) und fasst Arcanes
# Projektverzeichnis (~/projects/rippy) NIE an — 22.07. gelernt: ein git-Klon
# im Arcane-Verzeichnis kollidiert mit dessen Promote (read-only .git-Objekte).
# Die .env gehört Arcane und wird nur GELESEN (für compose-Interpolation).
# Generisch/portabel: Ziel-Host, Repo-URL und .env-Pfad kommen aus der Umgebung —
# KEINE festen Adressen im Repo. Fuer eine Erst-Installation auf einem eigenen Host
# reicht ohnehin der einfache Weg (siehe README):
# git clone <repo> && cd rippy && cp .env.example .env (Werte eintragen)
# docker compose up -d --build
#
# Dieses Skript ist nur die bequeme Remote-Variante: es SSHt zur VM, nutzt dort
# einen EIGENEN Klon (Default ~/notfall-rippy) und fasst ein evtl. vorhandenes
# Projektverzeichnis NIE an (git-Klon dort kollidiert mit dessen Sync). Die .env
# gehoert der VM und wird nur GELESEN (fuer compose-Interpolation).
#
# Konfiguration ueber Umgebungsvariablen:
# RIPPY_VM Ziel-Host fuer ssh, z.B. user@10.0.0.5 (PFLICHT)
# RIPPY_REPO_URL Git-Repo-URL (branch main) (PFLICHT)
# RIPPY_ENV_SRC Pfad zur .env auf der VM (Default: ~/rippy/.env)
# RIPPY_CLONE Arbeits-Klon auf der VM (Default: ~/notfall-rippy)
# Optionales Argument $1: nur einen Dienst neu bauen, z.B. ./deploy.sh api
set -euo pipefail
VM="arcane@192.168.178.162"
DIENST="${1:-}" # optional: nur einen Dienst neu bauen, z.B. ./deploy.sh api
VM="${RIPPY_VM:?RIPPY_VM setzen, z.B. RIPPY_VM=user@10.0.0.5}"
REPO_URL="${RIPPY_REPO_URL:?RIPPY_REPO_URL setzen (Git-URL des Rippy-Repos)}"
ENV_SRC="${RIPPY_ENV_SRC:-}" # leer -> Remote-Default ~/rippy/.env
CLONE="${RIPPY_CLONE:-}" # leer -> Remote-Default ~/notfall-rippy
DIENST="${1:-}"
ssh "$VM" 'bash -s' <<REMOTE
ssh "$VM" bash -s -- "$REPO_URL" "$ENV_SRC" "$CLONE" "$DIENST" <<'REMOTE'
set -euo pipefail
if [ ! -d ~/notfall-rippy/.git ]; then
git clone --branch stable https://git.tobisniceshomelab.ddnsfree.com/Hitonabi/rippy.git ~/notfall-rippy
REPO_URL="$1"
ENV_SRC="${2:-$HOME/rippy/.env}"
CLONE="${3:-$HOME/notfall-rippy}"
# ⚠️ ${4:-}, nicht "$4" (Befund 26.07.2026): Leere Argumente ueberleben den Weg
# durch ssh nicht — die Gegenseite bekommt die Befehlszeile als EINEN String und
# parst sie neu, wobei "" ersatzlos verschwindet. Wer also ohne RIPPY_ENV_SRC,
# RIPPY_CLONE und ohne Dienst-Argument deployte (der dokumentierte Normalfall!),
# bekam von 'set -u' nur ein "line 5: $4: unbound variable" und kein Deploy.
DIENST="${4:-}"
# ⚠️ NICHT DEPLOYEN, WÄHREND EIN JOB LÄUFT (Vorfall 26.07.2026, selbst verursacht)
#
# `docker compose up -d --build` baut den worker-Container neu — und tötet damit
# einen laufenden Rip. Genau das ist passiert: mitten in einem Blu-ray-Rip, bei
# 12 %, nach 5,1 GB. Die Warnung stand im SAVEPOINT und half nichts, weil sie
# niemand las und nichts sie prüfte. Jetzt prüft es das Skript.
#
# Übersteuern mit RIPPY_TROTZDEM=1 — dann ist es eine Entscheidung und kein
# Versehen.
if [ -z "${RIPPY_TROTZDEM:-}" ]; then
ANTWORT="$(curl -s -m 5 http://localhost:8000/health/arbeit 2>/dev/null || true)"
case "$ANTWORT" in
*'"arbeit":true'*|*'"arbeit": true'*)
echo "ABBRUCH: Auf dieser Maschine läuft gerade ein Job." >&2
echo " Ein Rebuild des worker-Containers würde ihn töten." >&2
echo "$ANTWORT" | tr ',' '\n' | grep -E '"(status|titel|progress)"' >&2 || true
echo " Warten, oder bewusst überstimmen: RIPPY_TROTZDEM=1 ./deploy.sh" >&2
exit 1
;;
esac
fi
cd ~/notfall-rippy
git fetch origin stable
git reset --hard origin/stable
cp ~/projects/rippy/.env .env 2>/dev/null || echo "WARNUNG: keine .env in Arcanes Projektverzeichnis"
if [ ! -d "$CLONE/.git" ]; then
git clone --branch main "$REPO_URL" "$CLONE"
fi
cd "$CLONE"
git fetch origin main
git reset --hard origin/main
# ⚠️ Eine fehlende .env-Quelle war bisher eine geschluckte Warnung — und damit
# eine Falle (Befund 26.07.2026). Auf der Ziel-VM lag die echte .env unter
# ~/projects/rippy/.env, der Default zeigte auf ~/rippy/.env. Das `cp` schlug
# also jedes Mal fehl, die Zeile scrollte im Build-Ausgabe-Rauschen vorbei, und
# gebaut wurde mit der Kopie im Klon: zwei Tage alt, mit einem inzwischen toten
# MAKEMKV_URL_BASE-Notbehelf und einem JWT_SECRET_KEY aus der Zeit vor dem
# Auth-Rueckbau. Ergebnis: jeder worker-Build brach ab, und die Ursache stand
# nirgends.
if [ -f "$ENV_SRC" ]; then
cp "$ENV_SRC" .env
echo "OK: .env aus $ENV_SRC uebernommen."
elif [ -f .env ]; then
echo "WARNUNG: $ENV_SRC gibt es nicht — es gilt die .env IM KLON ($CLONE/.env)." >&2
echo " Stand dieser Datei: $(date -r .env '+%d.%m.%Y %H:%M')" >&2
echo " Ist das nicht gewollt: RIPPY_ENV_SRC=<pfad> setzen." >&2
ls -1 "$HOME"/*/.env "$HOME"/*/*/.env 2>/dev/null | head -5 | sed 's/^/ Kandidat: /' >&2 || true
else
echo "ABBRUCH: Keine .env — weder unter $ENV_SRC noch im Klon." >&2
echo " Ohne sie baut compose mit leeren Werten (kein DB-Passwort," >&2
echo " keine API-Schluessel). RIPPY_ENV_SRC=<pfad> setzen." >&2
exit 1
fi
sed -i '/^RIPPY_VERSION=/d' .env
echo "RIPPY_VERSION=$(git rev-parse --short HEAD)" >> .env
# Geraete dieses Hosts ermitteln, BEVOR gestartet wird.
# Ohne diesen Schritt haengt der Start an einem `devices:`-Eintrag, den es
# vielleicht nicht mehr gibt — am 28.08.2026 legte genau das die ganze
# Installation stillt, weil das USB-Laufwerk abgezogen war (Herleitung im Kopf
# von docker-compose.yml). Das Skript schreibt die Override immer neu, auch
# wenn kein Laufwerk da ist.
if [ -x ./deploy/geraete-override.sh ]; then
./deploy/geraete-override.sh .
else
echo "WARNUNG: deploy/geraete-override.sh fehlt — starte ohne Geraete-Erkennung."
fi
docker compose -p rippy up -d --build $DIENST
docker compose -p rippy ps --format 'table {{.Name}}\t{{.Status}}'
REMOTE
+112
View File
@@ -0,0 +1,112 @@
#!/usr/bin/env bash
#
# Erzeugt docker-compose.override.yml mit den optischen Laufwerken DIESES Hosts.
#
# ## Warum es das gibt (Vorfall 28.08.2026)
#
# In docker-compose.yml stand:
#
# devices:
# - ${OPTICAL_SR:-/dev/sr0}:/dev/sr0
#
# Das ist eine STARTBEDINGUNG. Fehlt das Laufwerk, startet der Container nicht:
#
# Error response from daemon: error gathering device information while
# adding custom device "/dev/sr0": no such file or directory
#
# Genau das ist passiert, als das USB-Laufwerk von der VM abgezogen wurde: Ein
# ganz normaler Deploy legte api, worker UND ui still — obwohl keiner der drei
# ein Laufwerk zum Starten braucht. Rippy war unten, und die Meldung stand
# mitten im Build-Rauschen.
#
# Der Widerspruch war schon vorher da: `install.sh` sagt bei fehlendem Laufwerk
# ausdrücklich „die Installation läuft trotzdem durch; diese Maschine dient dann
# als reine KOMPRIMIER-Maschine" — die Compose-Datei sah das anders. Eine
# Maschine ohne Laufwerk ist ein vorgesehener Betriebsfall (der Windows-Worker
# und der GPU-Encoder sind genau das).
#
# Seither steht in docker-compose.yml KEIN devices-Block mehr. Was dieser Host
# wirklich hat, landet in docker-compose.override.yml — die zieht Compose von
# allein dazu (`docker compose up` braucht keinen extra Schalter), und sie ist
# gitignored, weil die Geräteknoten je Rechner anders heißen.
#
# Aufruf: ./deploy/geraete-override.sh [zielverzeichnis]
# (ohne Argument: das aktuelle Verzeichnis)
#
set -u
ZIEL="${1:-.}"
DATEI="$ZIEL/docker-compose.override.yml"
# MakeMKV spricht Laufwerke über die SCSI-Generic-Schicht an und braucht deshalb
# ZWEI Knoten: /dev/srN und den passenden /dev/sgM. Welche sg-Nummer dazugehört,
# ist je Host anders — sie wird über die SCSI-Adresse ermittelt statt geraten.
# Beide Knoten zeigen in /sys auf dasselbe Geräteverzeichnis (z. B. 3:0:0:0).
# (Dieselbe Herleitung wie in install.sh, Prüfung 2/5.)
SR=""
SG=""
LAUFWERK=""
for srpfad in /sys/block/sr*; do
[ -e "$srpfad" ] || continue
srname=$(basename "$srpfad")
adresse=$(basename "$(readlink -f "$srpfad/device" 2>/dev/null)" 2>/dev/null)
[ -n "$adresse" ] || continue
for sgpfad in /sys/class/scsi_generic/sg*; do
[ -e "$sgpfad" ] || continue
if [ "$(basename "$(readlink -f "$sgpfad/device" 2>/dev/null)" 2>/dev/null)" = "$adresse" ]; then
SR="/dev/$srname"
SG="/dev/$(basename "$sgpfad")"
LAUFWERK="$(cat "$srpfad/device/vendor" 2>/dev/null) $(cat "$srpfad/device/model" 2>/dev/null)"
break 2
fi
done
done
kopf() {
cat <<KOPF
# ERZEUGT von deploy/geraete-override.sh — nicht von Hand ändern.
# Diese Datei ist gitignored: Die Geräteknoten heißen auf jedem Rechner anders.
# Neu erzeugen nach jedem An- oder Abstecken eines Laufwerks:
# ./deploy/geraete-override.sh && docker compose up -d
KOPF
}
if [ -z "$SR" ]; then
# KEIN Laufwerk. Wichtig: trotzdem eine gültige Datei schreiben und die alte
# damit überschreiben. Bliebe eine alte Override mit /dev/sr0 liegen, wäre der
# Fehler beim nächsten Start genau derselbe — nur schwerer zu finden, weil die
# Datei gitignored ist und in keinem Diff auftaucht.
{
kopf
echo "#"
echo "# Auf diesem Host wurde KEIN optisches Laufwerk gefunden."
echo "# Rippy läuft damit als reine Komprimier-Maschine — das ist ein"
echo "# vorgesehener Betriebsfall, kein Fehler. Zum Rippen das Laufwerk"
echo "# anstecken (in einer VM: USB-Passthrough) und dieses Skript erneut"
echo "# aufrufen."
echo "services: {}"
} > "$DATEI"
echo "Kein optisches Laufwerk gefunden — $DATEI ohne Geräte geschrieben."
echo "Rippy startet und kann komprimieren; Rippen geht erst mit Laufwerk."
exit 0
fi
{
kopf
echo "#"
echo "# Gefunden: $(echo "$LAUFWERK" | tr -s ' ')"
echo "# $SR + $SG (über die SCSI-Adresse abgeglichen, nicht geraten)"
cat <<YAML
services:
api:
devices:
- $SR:/dev/sr0
worker:
devices:
- $SR:/dev/sr0
- $SG:/dev/sg1
YAML
} > "$DATEI"
echo "Laufwerk gefunden: $(echo "$LAUFWERK" | tr -s ' ')"
echo " $SR + $SG -> $DATEI"
+41 -12
View File
@@ -1,17 +1,36 @@
# Optionaler Remote-Transcode-Worker — für eine GPU-Maschine im Netz.
# (EXPERIMENTELL, 23.07.2026: VAAPI/NVENC-Presets folgen; aktuell nutzt der
# Worker dieselben HandBrake-CPU-Presets, bringt also v.a. stärkere CPUs.)
# Optionaler Remote-Transcode-Worker — für eine GPU-Maschine im Netz (Linux).
# Für Windows gibt es den nativen Weg: RippyWorkerSetup.exe (Einstellungen → Worker).
#
# ══ DAS ENTSCHEIDENDE: der Worker muss die Dateien SEHEN ══════════════════════
# Rippy schickt ihm Pfade wie /app/media/rippy/<job>/title_t00.mkv — Pfade
# INNERHALB des Rippy-Containers. Dieser Container muss dieselben Daten unter
# GENAU DEMSELBEN Pfad haben, sonst nimmt er die Aufgabe an und lehnt sie
# Millisekunden später ab („Keine Roh-MKVs gefunden" — genau so passiert am
# 26.07.2026, Job 95afdc89).
#
# Richtigstellung 26.07.2026: Hier stand vorher „mount -t nfs
# <rippy-host>:/srv/rippy /mnt/rippy". Das geht NICHT — auf der Rippy-Maschine
# läuft kein NFS- und kein Samba-Server, sie ist selbst nur Client der NAS.
# Der Weg, der funktioniert: DIESELBE Freigabe einhängen, die auch Rippy nutzt.
#
# Auf der GPU-Maschine:
# 1. Dieses Repo klonen (oder nur dieses File + Zugriff aufs Registry-Image)
# 2. Rohdaten-Freigabe der Rippy-Maschine mounten, z. B.:
# mount -t nfs <rippy-host>:/srv/rippy /mnt/rippy
# (die Rippy-VM muss /srv/rippy + das temp-Volume exportieren)
# 3. RIPPY_HOST unten setzen und starten:
# docker compose -f deploy/remote-transcode-worker.yml up -d --build
# 2. Die Freigabe einhängen, die Rippy als Arbeitsverzeichnis UND Ablage
# benutzt (Einstellungen → Ripping). Heißt sie in Rippy „rippy", liegt
# sie dort unter /app/media/rippy — also z. B.:
# mount -t cifs //NAS/rippy /mnt/rippy-freigabe -o guest,iocharset=utf8
# 3. Unten RIPPY_HOST setzen, den Freigabe-Pfad im volumes-Block anpassen
# und starten:
# RIPPY_HOST=<LAN-IP-der-Rippy-Maschine> docker compose \
# -f deploy/remote-transcode-worker.yml up -d --build
#
# Passt der Pfad im Container nicht (weil die Freigabe woanders hängt), gibt es
# als Ausweg RIPPY_PATH_MAP — dieselbe Übersetzung, die der Windows-Worker
# nutzt, Format: /app/media/rippy=/mnt/anderer-pfad (Paare per „;").
# Den fertigen Wert nennt GET /worker-setup/pfad-map.
#
# Der Worker meldet seine Encoder-Fähigkeiten automatisch — er taucht danach
# unter Einstellungen → Verarbeitung auf. Er bedient NUR die transcode-Queue;
# unter Einstellungen → Worker auf. Er bedient NUR die transcode-Queue;
# gerippt wird weiterhin dort, wo das Laufwerk hängt.
services:
@@ -25,10 +44,20 @@ services:
- DATABASE_URL=postgresql://rippy:rippy@${RIPPY_HOST}:5432/rippy
- RIP_OUTPUT_DIR=/app/media
- RAW_DIR=/app/temp/raw
# Anzeigename in Einstellungen → Worker — z. B. den Maschinennamen
# setzen: WORKER_NAME=gaming-pc docker compose -f … up -d
- WORKER_NAME=${WORKER_NAME:-transcode-worker}
# Serien-Episoden-Matching fragt die Rippy-API nach Laufzeiten
- API_URL=http://${RIPPY_HOST}:8000
# Nur nötig, wenn die Freigabe hier NICHT unter demselben Pfad liegt wie
# in Rippy. Fertigen Wert holen: curl http://${RIPPY_HOST}/api/worker-setup/pfad-map
- RIPPY_PATH_MAP=${RIPPY_PATH_MAP:-}
volumes:
# Freigabe der Rippy-Maschine (siehe Kopf-Kommentar)
- /mnt/rippy/media:/app/media
- /mnt/rippy/temp:/app/temp
# LINKS der Pfad auf DIESER Maschine, RECHTS der Pfad, den Rippy nennt.
# Rechts muss stehen, was in Rippy als Speicherziel heißt: ein Ziel
# namens „rippy" ist dort /app/media/rippy. Prüfen mit
# curl http://<rippy-host>/api/worker-setup/pfad-map
- /mnt/rippy-freigabe:/app/media/rippy
devices:
# GPU für Hardware-Encoding (AMD/Intel: /dev/dri; NVIDIA: nvidia-runtime)
- /dev/dri:/dev/dri
Binary file not shown.
+412
View File
@@ -0,0 +1,412 @@
import flet as ft
import os
import subprocess
import threading
import urllib.request
import json
import zipfile
def main(page: ft.Page):
page.title = "Rippy Encoding-Worker Installation"
page.window_width = 800
page.window_height = 650
page.bgcolor = "#0f172a"
page.theme_mode = ft.ThemeMode.DARK
page.scroll = ft.ScrollMode.AUTO
# Colors
c_panel = "#1e293b"
c_text = "#e2e8f0"
c_muted = "#94a3b8"
c_accent = "#6366f1"
c_success = "#10b981"
# State
std_ziel = r"C:\Program Files\Rippy Worker"
# UI Fields
txt_host = ft.TextField(
label="LAN-IP der Rippy-Maschine (Docker-Host)",
width=400,
bgcolor=c_panel,
color=c_text,
)
txt_name = ft.TextField(
label="Name dieses Workers (frei wählbar)",
width=250,
value=os.environ.get("COMPUTERNAME", "worker").lower(),
bgcolor=c_panel,
color=c_text,
)
txt_slots = ft.Dropdown(
label="Kerne (Gleichzeitig)",
width=150,
options=[ft.dropdown.Option(str(i)) for i in range(1, 9)],
value="2" if os.cpu_count() and os.cpu_count() >= 12 else "1",
bgcolor=c_panel,
color=c_text,
)
txt_pfad = ft.TextField(
label="Installieren nach",
value=std_ziel,
expand=True,
bgcolor=c_panel,
color=c_text,
)
txt_map = ft.TextField(
label="Netzwerk-Freigabe mit den Rohdaten",
expand=True,
bgcolor=c_panel,
color=c_text,
)
chk_auto = ft.Checkbox(
label="Beim Anmelden automatisch starten (Hintergrund)",
value=True,
fill_color=c_accent,
)
chk_desktop = ft.Checkbox(
label="Verknüpfung auf dem Desktop anlegen", value=True, fill_color=c_accent
)
log_view = ft.ListView(height=150, auto_scroll=True, spacing=2)
def log(msg: str):
log_view.controls.append(
ft.Text(msg, color=c_muted, font_family="Consolas", size=12)
)
try:
page.update()
except Exception:
pass
def check_map(e):
r_host = txt_host.value.strip()
if not r_host:
page.snack_bar = ft.SnackBar(
ft.Text("Bitte zuerst die LAN-IP eintragen!"), bgcolor="red"
)
page.snack_bar.open = True
page.update()
return
try:
log(f"Frage Rippy nach Freigabe ({r_host})...")
with urllib.request.urlopen(
f"http://{r_host}/api/worker-setup/pfad-map", timeout=5
) as r:
data = json.loads(r.read().decode())
if data.get("hinweis"):
log(data["hinweis"])
if data.get("mapping"):
txt_map.value = data["mapping"]
log(f"Erfolgreich geholt: {data['mapping']}")
page.update()
except Exception as ex:
log(f"Fehler: {ex}")
def do_install(e):
btn_install.disabled = True
page.update()
threading.Thread(target=run_installation, daemon=True).start()
def run_installation():
r_host = txt_host.value.strip()
w_name = txt_name.value.strip()
install_dir = txt_pfad.value.strip()
if not r_host:
log("FEHLER: Rippy LAN-IP fehlt!")
btn_install.disabled = False
page.update()
return
log(f"Zielverzeichnis: {install_dir}")
# Check Python
python_exe = None
for cmd in ["py -3", "python"]:
try:
res = subprocess.run(
f"{cmd} --version", shell=True, capture_output=True, text=True
)
if "Python 3." in res.stdout:
python_exe = cmd
break
except Exception:
pass
if not python_exe:
log("FEHLER: Python 3.10+ nicht gefunden.")
log("Bitte mit 'winget install Python.Python.3.12' installieren.")
btn_install.disabled = False
page.update()
return
log(f"Python gefunden: {python_exe}")
try:
os.makedirs(install_dir, exist_ok=True)
test_file = os.path.join(install_dir, ".test")
with open(test_file, "w") as f:
f.write("x")
os.remove(test_file)
except Exception:
log(f"FEHLER: Keine Schreibrechte in {install_dir}")
log("Bitte als Administrator starten oder Pfad aendern.")
btn_install.disabled = False
page.update()
return
# Download worker package
log(f"Lade Worker-Code von {r_host}...")
try:
zip_path = os.path.join(install_dir, "worker.zip")
urllib.request.urlretrieve(
f"http://{r_host}/api/worker-setup/paket", zip_path
)
with zipfile.ZipFile(zip_path, "r") as zip_ref:
zip_ref.extractall(install_dir)
os.remove(zip_path)
except Exception as ex:
log(f"FEHLER beim Download: {ex}")
btn_install.disabled = False
page.update()
return
# Setup venv — --clear loescht einen alten venv komplett, damit keine
# veralteten Pakete (z.B. flet 0.86 statt 0.23) ueberleben.
log("Lege Python-Umgebung an (venv)...")
subprocess.run(
f"{python_exe} -m venv --clear venv", cwd=install_dir, shell=True
)
log("Installiere Abhaengigkeiten (pip)...")
subprocess.run(
r"venv\Scripts\python.exe -m pip install --quiet --upgrade pip",
cwd=install_dir,
shell=True,
)
subprocess.run(
r"venv\Scripts\pip.exe install --quiet -r requirements.txt",
cwd=install_dir,
shell=True,
)
subprocess.run(
r"venv\Scripts\pip.exe install --quiet requests pillow",
cwd=install_dir,
shell=True,
)
# Download Handbrake
hb_path = os.path.join(install_dir, "HandBrakeCLI.exe")
if not os.path.exists(hb_path):
log("Lade HandBrakeCLI herunter...")
try:
hb_ver = "1.7.3" # Fallback if github fails
try:
with urllib.request.urlopen(
"https://api.github.com/repos/HandBrake/HandBrake/releases/latest",
timeout=5,
) as r:
hb_data = json.loads(r.read().decode())
if hb_data.get("tag_name"):
hb_ver = hb_data["tag_name"].lstrip("v")
except Exception:
pass
hb_zip = os.path.join(install_dir, "hb.zip")
urllib.request.urlretrieve(
f"https://github.com/HandBrake/HandBrake/releases/download/{hb_ver}/HandBrakeCLI-{hb_ver}-win-x86_64.zip",
hb_zip,
)
with zipfile.ZipFile(hb_zip, "r") as zip_ref:
zip_ref.extractall(install_dir)
os.remove(hb_zip)
except Exception as ex:
log(f"Warnung bei HandBrake-Download: {ex}")
log("Erstelle Start-Skripte...")
slots = txt_slots.value
pool_arg = (
"--pool=solo"
if int(slots) <= 1
else f"--pool=threads --concurrency={slots}"
)
map_zeile = (
f"set RIPPY_PATH_MAP={txt_map.value.strip()}\r\n"
if txt_map.value.strip()
else ""
)
gui_bat = f'@echo off\r\ncd /d "%~dp0"\r\nset REDIS_URL=redis://{r_host}:6379/0\r\nset DATABASE_URL=postgresql://rippy:rippy@{r_host}:5432/rippy\r\nset API_URL=http://{r_host}:8000\r\nset WORKER_NAME={w_name}\r\nset RIPPY_TRAY_HOST={r_host}\r\nset RIPPY_SLOTS={slots}\r\nset TZ=UTC\r\n{map_zeile}set PATH=%~dp0;%PATH%\r\nstart "" venv\\Scripts\\pythonw.exe gui.py'
with open(os.path.join(install_dir, "start-gui.bat"), "w") as f:
f.write(gui_bat)
work_bat = f'@echo off\r\ncd /d "%~dp0"\r\nset REDIS_URL=redis://{r_host}:6379/0\r\nset DATABASE_URL=postgresql://rippy:rippy@{r_host}:5432/rippy\r\nset API_URL=http://{r_host}:8000\r\nset WORKER_NAME={w_name}\r\nset RIPPY_SLOTS={slots}\r\nset TZ=UTC\r\n{map_zeile}set PATH=%~dp0;%PATH%\r\nvenv\\Scripts\\celery.exe -A celery_app worker --loglevel=info -Q transcode {pool_arg} -n {w_name}@%%h'
with open(os.path.join(install_dir, "start-worker.bat"), "w") as f:
f.write(work_bat)
# Uninstaller
uninstall_ps1 = f"""param([switch]$Force)
Add-Type -AssemblyName System.Windows.Forms
if (-not $Force) {{
$antwort = [System.Windows.Forms.MessageBox]::Show("Rippy-Worker '{w_name}' von diesem PC entfernen?", "Rippy Worker deinstallieren", 4, 32)
if ($antwort -ne "Yes") {{ exit }}
}}
Get-WmiObject Win32_Process | Where-Object {{
$_.ExecutablePath -like "$PSScriptRoot*" -or $_.CommandLine -like "*gui.py*" -or $_.CommandLine -like "*tray.py*"
}} | ForEach-Object {{ Stop-Process -Id $_.ProcessId -Force -ErrorAction SilentlyContinue }}
Start-Sleep 3
$desktopDir = if ($PSScriptRoot -match "(?i)Program Files") {{ [Environment]::GetFolderPath("CommonDesktopDirectory") }} else {{ [Environment]::GetFolderPath("Desktop") }}
Remove-Item -Force "$desktopDir\\Rippy Worker.lnk" -ErrorAction SilentlyContinue
schtasks /delete /tn "RippyWorker" /f *>$null
Start-Process cmd -ArgumentList "/c ping 127.0.0.1 -n 3 >nul & rmdir /s /q `"$PSScriptRoot`"" -WindowStyle Hidden
if (-not $Force) {{ [System.Windows.Forms.MessageBox]::Show("Rippy-Worker entfernt.", "Rippy Worker") }}
"""
with open(
os.path.join(install_dir, "uninstall.ps1"), "w", encoding="utf-8"
) as f:
f.write(uninstall_ps1)
# Autostart
if chk_auto.value:
log("Richte Autostart (Task Scheduler) ein...")
bat_path = os.path.join(install_dir, "start-gui.bat")
subprocess.run(
f'schtasks /create /tn "RippyWorker" /tr "\\"{bat_path}\\"" /sc ONLOGON /rl HIGHEST /f',
shell=True,
capture_output=True,
)
# Desktop Shortcut — ueber PowerShell/COM, weil win32com im
# PyInstaller-Bundle nicht enthalten ist.
if chk_desktop.value:
try:
public_desktop = os.path.join(
os.environ.get("PUBLIC", r"C:\Users\Public"), "Desktop"
)
user_desktop = os.path.join(os.path.expanduser("~"), "Desktop")
desktop = (
public_desktop
if "Program Files" in install_dir and os.path.isdir(public_desktop)
else user_desktop
)
lnk_path = os.path.join(desktop, "Rippy Worker.lnk")
bat_target = os.path.join(install_dir, "start-gui.bat")
ico_path = os.path.join(install_dir, "rippy.ico")
ps_cmd = (
f"$ws = New-Object -ComObject WScript.Shell; "
f'$sc = $ws.CreateShortcut("{lnk_path}"); '
f'$sc.TargetPath = "{bat_target}"; '
f'$sc.WorkingDirectory = "{install_dir}"; '
f'$sc.IconLocation = "{ico_path}"; '
f"$sc.WindowStyle = 7; "
f"$sc.Save()"
)
subprocess.run(
["powershell", "-NoProfile", "-Command", ps_cmd],
capture_output=True,
)
log("Desktop-Verknüpfung erstellt.")
except Exception as e:
log(f"Warnung: Shortcut konnte nicht erstellt werden: {e}")
log("FERTIG!")
btn_start.visible = True
btn_install.text = "Neu installieren"
btn_install.disabled = False
page.update()
def start_worker(e):
install_dir = txt_pfad.value.strip()
bat_path = os.path.join(install_dir, "start-gui.bat")
# os.startfile startet die .bat ueber die Shell-Verknuepfung —
# CREATE_NO_WINDOW wuerde sie stumm schlucken.
os.startfile(bat_path)
page.window_close()
btn_install = ft.ElevatedButton(
"Installieren",
on_click=do_install,
bgcolor=c_accent,
color=ft.colors.WHITE,
width=200,
height=40,
)
btn_start = ft.ElevatedButton(
"Worker starten",
on_click=start_worker,
bgcolor=c_success,
color=ft.colors.WHITE,
width=200,
height=40,
visible=False,
)
def get_dir(e: ft.FilePickerResultEvent):
if e.path:
txt_pfad.value = e.path
page.update()
dir_picker = ft.FilePicker(on_result=get_dir)
page.overlay.append(dir_picker)
page.add(
ft.Row(
[
ft.Icon(ft.icons.DISC_FULL, size=40, color=c_accent),
ft.Text(
"Rippy Encoding-Worker",
size=28,
weight=ft.FontWeight.BOLD,
color=c_text,
),
]
),
ft.Text(
"Diese Maschine übernimmt die Video-Kompression für Rippy. Gerippt wird weiter auf der Hauptmaschine.",
color=c_muted,
),
ft.Divider(color="#334155"),
ft.Row([txt_host], alignment=ft.MainAxisAlignment.START),
ft.Row([txt_name, txt_slots], alignment=ft.MainAxisAlignment.START),
ft.Row(
[
txt_pfad,
ft.ElevatedButton(
"Durchsuchen ...",
on_click=lambda _: dir_picker.get_directory_path(
"Installationsordner wählen"
),
bgcolor=c_panel,
color=c_text,
),
],
alignment=ft.MainAxisAlignment.START,
),
ft.Row(
[
txt_map,
ft.ElevatedButton(
"Freigabe holen", on_click=check_map, bgcolor=c_panel, color=c_text
),
],
alignment=ft.MainAxisAlignment.START,
),
chk_auto,
chk_desktop,
ft.Container(
content=log_view,
bgcolor="#020617",
padding=10,
border_radius=5,
border=ft.border.all(1, "#334155"),
),
ft.Row([btn_install, btn_start]),
)
if __name__ == "__main__":
ft.app(target=main)
Binary file not shown.

After

Width:  |  Height:  |  Size: 31 KiB

+85 -21
View File
@@ -3,7 +3,24 @@
# Geräte-Zugriff (22.07./23.07.-Lehre): Optische Laufwerke MÜSSEN als devices:
# eingebunden werden. Bind-Mounts unter volumes: geben dem Container zwar den
# Geräteknoten, aber KEINE Berechtigung im Device-Cgroup → jedes open() scheitert
# mit EPERM. Voraussetzung: Die VM sieht das Laufwerk (USB-Passthrough auf pve).
# mit EPERM.
#
# ⚠️ ABER NICHT HIER (Vorfall 28.08.2026): Ein `devices:`-Eintrag ist eine
# STARTBEDINGUNG. Als das USB-Laufwerk von der VM abgezogen wurde, legte ein
# ganz normaler Deploy api, worker UND ui still — obwohl keiner der drei zum
# Starten ein Laufwerk braucht:
#
# Error response from daemon: error gathering device information while
# adding custom device "/dev/sr0": no such file or directory
#
# Der Widerspruch war älter: install.sh sagt bei fehlendem Laufwerk
# ausdrücklich „läuft trotzdem durch, dann ist das eine reine
# KOMPRIMIER-Maschine" — diese Datei sah das anders.
#
# Deshalb stehen die Geräte jetzt in docker-compose.override.yml, erzeugt von
# `deploy/geraete-override.sh`. Compose zieht die Override von allein dazu;
# `docker compose up -d` bleibt derselbe Befehl. Nach jedem An- oder Abstecken
# eines Laufwerks das Skript erneut aufrufen.
services:
api:
@@ -11,13 +28,17 @@ services:
context: .
dockerfile: docker/api/Dockerfile
environment:
- DATABASE_URL=postgresql://rippy:rippy@postgres:5432/rippy
- DATABASE_URL=postgresql://rippy:${POSTGRES_PASSWORD:-rippy}@postgres:5432/rippy
- REDIS_URL=redis://redis:6379/0
- TMDB_API_KEY=${TMDB_API_KEY}
- THETVDB_API_KEY=${THETVDB_API_KEY}
- OMDB_API_KEY=${OMDB_API_KEY}
- JWT_SECRET_KEY=${JWT_SECRET_KEY}
- TMDB_API_KEY=${TMDB_API_KEY:-}
- THETVDB_API_KEY=${THETVDB_API_KEY:-}
- OMDB_API_KEY=${OMDB_API_KEY:-}
# Dasselbe Host-Verzeichnis wie beim Worker, nur an neutraler Stelle:
# die API liest den KEYDB-Status und die AACS-Dumps und nimmt eine
# hochgeladene KEYDB.cfg entgegen (Einstellungen → System).
- MAKEMKV_DATA_DIR=/app/makemkv-data
- LOG_LEVEL=INFO
- RIPPY_VERSION=${RIPPY_VERSION:-dev}
healthcheck:
test: ["CMD-SHELL", "python -c 'import urllib.request; urllib.request.urlopen(\"http://localhost:8000/health\")'"]
interval: 30s
@@ -29,8 +50,13 @@ services:
# SYS_ADMIN: die API hängt Netzwerk-Speicherziele (NFS/SMB) selbst ein
# (mounts.py) — dank rshared-Propagation unten sehen Host UND Worker
# jeden Mount sofort.
# DAC_READ_SEARCH: mount.cifs hebt diese Capability an (toggle_dac_
# capability) — sie fehlt in Dockers Default-Set, ohne sie stirbt JEDER
# SMB-Mount mit "Unable to apply new capability set" (Befund 24.07.,
# auf der VM reproduziert und mit dieser Capability bewiesen behoben).
cap_add:
- SYS_ADMIN
- DAC_READ_SEARCH
security_opt:
- apparmor:unconfined
volumes:
@@ -43,8 +69,9 @@ services:
bind:
propagation: rshared
- temp:/app/temp
devices:
- /dev/sr0:/dev/sr0
# MakeMKV-Datenverzeichnis (dasselbe wie im Worker, siehe dort).
- ${MAKEMKV_DATA_HOST:-/srv/rippy/makemkv}:/app/makemkv-data
# devices: siehe Kopf — kommen aus docker-compose.override.yml
networks:
- rippy-net
depends_on:
@@ -60,15 +87,39 @@ services:
context: .
dockerfile: docker/worker/Dockerfile
args:
# Übersteuerbar via .env — makemkv.com ist zeitweise down (Cloudflare
# 525); dann Wayback-Snapshot als MAKEMKV_URL_BASE eintragen.
MAKEMKV_URL_BASE: ${MAKEMKV_URL_BASE:-https://www.makemkv.com/download/old}
# Übersteuerbar via .env. /download = aktuelle Version,
# /download/old = ältere. Am 25.07.2026 nachgemessen: /download
# antwortet mit 200, /download/old mit 525 (Cloudflare), und ein
# web.archive.org-Schnappschuss mit 404 — deshalb steht hier der
# Standard, der wirklich liefert.
MAKEMKV_URL_BASE: ${MAKEMKV_URL_BASE:-https://www.makemkv.com/download}
# Zweite Quelle, die bei Fehlschlag der ersten automatisch probiert wird
# (leer = keine). Bewusst ohne Vorbelegung: eine Adresse, die nicht
# liefert, lässt die Konfiguration gesund aussehen und den Build später
# scheitern. Der zuverlässige Weg bleibt docker/worker/vendor/.
MAKEMKV_URL_FALLBACK: ${MAKEMKV_URL_FALLBACK:-}
# MakeMKV-Update OHNE Code-Änderung: neue Version in die .env,
# Tarballs nach docker/worker/vendor/ legen (oder Download klappt),
# dann docker compose build worker && docker compose up -d worker.
# Einstellungen → System meldet, wenn es eine neuere Version gibt.
MAKEMKV_VERSION: ${MAKEMKV_VERSION:-1.18.4}
environment:
- DATABASE_URL=postgresql://rippy:rippy@postgres:5432/rippy
- DATABASE_URL=postgresql://rippy:${POSTGRES_PASSWORD:-rippy}@postgres:5432/rippy
- REDIS_URL=redis://redis:6379/0
- RIP_OUTPUT_DIR=/app/media
- MAKEMKV_APP_KEY=${MAKEMKV_APP_KEY}
# MakeMKVs Datenverzeichnis im Container — fest verdrahtet in MakeMKV
# selbst (HOME/.MakeMKV, HOME ist /root). Steht hier, damit Worker-Code
# und Mount dieselbe Wahrheit benutzen.
- MAKEMKV_DATA_DIR=/root/.MakeMKV
# Anzeigename in Einstellungen → Worker (stabil über Rebuilds hinweg;
# via .env übersteuerbar, z. B. WORKER_NAME=wohnzimmer-vm)
- WORKER_NAME=${WORKER_NAME:-rippy-hauptworker}
# Für Serien-Episoden-Matching: der Worker fragt die API nach den
# Episoden-Laufzeiten der Staffel (TMDB).
- API_URL=http://api:8000
- LOG_LEVEL=INFO
- RIPPY_VERSION=${RIPPY_VERSION:-dev}
volumes:
- type: bind
source: /srv/rippy/media
@@ -76,14 +127,18 @@ services:
bind:
propagation: rslave
- temp:/app/temp
devices:
- /dev/sr0:/dev/sr0
# MakeMKV spricht Laufwerke über die SCSI-Generic-Schicht an — ohne den
# sg-Knoten findet es „keine usable optical drives" (Deploy-Befund 23.07.).
# In dieser VM: sg0 = Systemplatte, sg1 = das BD-Laufwerk. Achtung: nach
# einem USB-Reconnect zur Laufzeit kann die sg-Nummer wandern → Container
# neu starten.
- /dev/sg1:/dev/sg1
# MakeMKV-Datenverzeichnis PERSISTENT (Befund 25.07.2026, live gemessen):
# Hier liegen die KEYDB.cfg — heute die EINZIGE funktionierende
# Schlüsselquelle für 4K-UHD, weil MakeMKVs Online-Kanal nichts mehr
# liefert —, die AACS-Dumps fehlgeschlagener Discs und settings.conf.
# Ohne diesen Mount löschte JEDER `up -d --build` beides; die
# Fehlermeldung schickte den Nutzer zu einer Datei, die es nicht mehr gab.
- ${MAKEMKV_DATA_HOST:-/srv/rippy/makemkv}:/root/.MakeMKV
# devices: siehe Kopf dieser Datei — die optischen Knoten dieses Hosts
# stehen in docker-compose.override.yml (deploy/geraete-override.sh).
# MakeMKV braucht BEIDE: /dev/srN und den passenden /dev/sgM; welche
# sg-Nummer dazugehoert, ist je Host anders und wird dort ueber die
# SCSI-Adresse abgeglichen statt geraten.
networks:
- rippy-net
depends_on:
@@ -116,8 +171,14 @@ services:
image: postgres:16-alpine
environment:
- POSTGRES_USER=rippy
- POSTGRES_PASSWORD=rippy
- POSTGRES_PASSWORD=${POSTGRES_PASSWORD:-rippy}
- POSTGRES_DB=rippy
# Veröffentlicht (Befund 24.07.): Remote-Worker (GPU-Maschine, künftiger
# Windows-Worker) verbinden sich über <rippy-host>:5432/6379 — ohne
# ports: konnte sich NIE ein Remote-Worker anbinden. Heimnetz-Kompromiss,
# wie die Klartext-Credentials (README).
ports:
- "5432:5432"
volumes:
- postgres-data:/var/lib/postgresql/data
networks:
@@ -131,6 +192,9 @@ services:
redis:
image: redis:7-alpine
# Siehe postgres: Pflicht für Remote-Worker (Celery-Broker).
ports:
- "6379:6379"
volumes:
- redis-data:/data
networks:
+24
View File
@@ -17,4 +17,28 @@ RUN pip install --no-cache-dir -r requirements.txt
COPY docker/api/ .
# Gemeinsamer Kern (Etappe V2-0): liegt im Repo unter src/rippy, im Image
# neben den API-Modulen. /app ist Arbeitsverzeichnis und uvicorn-App-Dir,
# damit findet "import rippy" das Paket ohne PYTHONPATH.
COPY src/rippy ./rippy
# Worker-Selbstversorgung: die API liefert Installer + Worker-Code an
# native Worker aus (GET /worker-setup/windows bzw. /worker-setup/paket) —
# die Zielmaschine braucht weder git noch Docker.
COPY docker/worker/*.py docker/worker/requirements.txt worker_dist/
# Der Worker importiert seit V2-0 aus dem gemeinsamen Paket (tasks.py, caps.py).
# Ohne diese Zeile fehlte es im Zip und der Windows-Worker stürbe beim Start
# mit ModuleNotFoundError — worker_setup_paket packt genau diesen Ordner mit ein.
COPY src/rippy worker_dist/rippy
COPY deploy/worker-windows/installer.py worker_dist/
# Rippy-Icon: Der Installer legt damit eine Verknüpfung auf den Desktop
# (Commander-Wunsch 26.07.2026). Ohne die Datei auf der Zielmaschine trüge die
# Verknüpfung das Standard-Batch-Symbol — und niemand fände sie zwischen den
# anderen Icons wieder.
COPY deploy/worker-windows/rippy.ico worker_dist/
# Vorgebaute .exe (Rippy-Icon, kein Konsolenfenster) — auf Windows via
# deploy/worker-windows/build-exe.ps1 erzeugt (Windows-.exe geht nicht von
# Linux). Nur bei GUI-Aenderungen neu bauen, nicht bei Tool-Updates.
COPY deploy/worker-windows/RippyWorkerSetup.exe worker_dist/
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000", "--app-dir", "/app"]
-105
View File
@@ -1,105 +0,0 @@
"""JWT-Auth-Module für Rippy API."""
import time
from datetime import datetime, timedelta, timezone
from typing import Dict, Optional
import jwt
from passlib.context import CryptContext
from config import settings
# Passwort-Hashing-Kontext
pwd_context = CryptContext(schemes=["bcrypt"], deprecated="auto")
# Geheimer Schlüssel für JWT — MUSS konfiguriert sein (.env: JWT_SECRET_KEY).
# Review-Fund 22.07.: der frühere Zufalls-Fallback erzeugte PRO PROZESS einen
# neuen Schlüssel → jeder Neustart/zweite Worker invalidierte alle Tokens.
# Lieber laut scheitern als still kaputt sein.
if not settings.jwt_secret_key:
raise RuntimeError(
"JWT_SECRET_KEY ist nicht gesetzt (.env). Ohne festen Schlüssel wären "
"alle Tokens nach jedem Neustart ungültig — Start verweigert."
)
SECRET_KEY = settings.jwt_secret_key
ALGORITHM = "HS256"
# Token-Lifetimes
ACCESS_TOKEN_EXPIRE_MINUTES = 15
REFRESH_TOKEN_EXPIRE_DAYS = 7
def verify_password(plain_password: str, hashed_password: str) -> bool:
"""Verifiziere Passwort."""
return pwd_context.verify(plain_password, hashed_password)
def get_password_hash(password: str) -> str:
"""Hash Passwort."""
return pwd_context.hash(password)
def create_access_token(data: Dict, expires_delta: timedelta = None) -> str:
"""Erstelle Access Token (Default 15 min)."""
to_encode = data.copy()
delta = expires_delta or timedelta(minutes=ACCESS_TOKEN_EXPIRE_MINUTES)
expire = datetime.now(timezone.utc) + delta
to_encode.update({"exp": expire, "type": "access"})
return jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)
def create_refresh_token(data: Dict) -> str:
"""Erstelle Refresh Token (7 Tage)."""
to_encode = data.copy()
expire = datetime.now(timezone.utc) + timedelta(days=REFRESH_TOKEN_EXPIRE_DAYS)
to_encode.update({"exp": expire, "type": "refresh"})
return jwt.encode(to_encode, SECRET_KEY, algorithm=ALGORITHM)
def decode_token(token: str) -> Optional[Dict]:
"""Dekodiere Token (None bei abgelaufen/ungültig)."""
try:
return jwt.decode(token, SECRET_KEY, algorithms=[ALGORITHM])
except jwt.ExpiredSignatureError:
return None
except jwt.InvalidTokenError:
return None
def is_access_token(token: str) -> bool:
"""Prüfe ob Token ein gültiges Access Token ist."""
payload = decode_token(token)
return bool(payload and payload.get("type") == "access")
def is_refresh_token(token: str) -> bool:
"""Prüfe ob Token ein gültiges Refresh Token ist."""
payload = decode_token(token)
return bool(payload and payload.get("type") == "refresh")
# Token-Blacklist für Logout: Token → Ablauf-Zeitstempel (exp).
# Bewusste MVP-Grenze: in-memory = pro Prozess (siehe SAVEPOINT.md).
# Review-Fund 22.07.: das frühere cleanup löschte die GESAMTE Blacklist —
# Logout war ein Placebo. Jetzt fliegen nur abgelaufene Tokens raus
# (die sind eh ungültig, decode_token lehnt sie ab).
token_blacklist: Dict[str, float] = {}
def add_to_blacklist(token: str) -> None:
"""Füge gültigen Token zur Blacklist hinzu (bis zu seinem Ablauf)."""
payload = decode_token(token)
if payload:
token_blacklist[token] = float(payload.get("exp", time.time()))
def is_blacklisted(token: str) -> bool:
"""Prüfe ob Token auf der Blacklist steht."""
return token in token_blacklist
def cleanup_blacklist() -> None:
"""Entferne NUR abgelaufene Tokens von der Blacklist."""
now = time.time()
for token in [t for t, exp in token_blacklist.items() if exp <= now]:
del token_blacklist[token]
+94 -14
View File
@@ -1,42 +1,122 @@
"""Cache module."""
"""Zwischenspeicher für API-Antworten — mit Redis, wenn es eins gibt.
## Warum das nicht mehr scheitern darf (Befund 28.08.2026)
Hier stand ein nacktes `redis_client.get(key)`. Der Vorgabe-Host ist `redis`
— der Dienstname aus `docker-compose.yml`. Im Container stimmt das; auf einem
Windows-PC gibt es kein Redis, und jeder Aufruf endete mit:
redis.exceptions.ConnectionError: Error 11001 connecting to redis:6379
Das riss den Pre-Scan mit. Der Commander sah die Folge, nicht die Ursache:
Eine eingelegte Blu-ray blieb namenlos, und die Metadaten-Suche lief nie an.
**Ein Zwischenspeicher ist eine Beschleunigung, keine Voraussetzung.** Ist
keiner da, wird eben jedes Mal neu gefragt — TMDB und OMDb halten das aus.
Deshalb fängt jeder Zugriff hier den Verbindungsfehler ab und tut so, als
wäre der Eintrag nicht vorhanden. Das ist genau die Wahrheit: Er ist es
nicht.
## Warum trotzdem einmal gemeldet wird
Ein Zwischenspeicher, der still nie greift, ist eine unsichtbare
Verlangsamung — und auf der VM wäre ein weggefallenes Redis ein echter
Befund. Deshalb sagt `zustand()`, woran man ist, und die erste fehlgeschlagene
Verbindung schreibt eine Zeile. Danach Ruhe: Eine Meldung je Anfrage wäre
Lärm.
"""
from redis import Redis
from typing import Any, Optional
import json
import os
from typing import Any, Optional
from redis import Redis
from redis.exceptions import RedisError
redis_host = os.getenv("REDIS_HOST", "redis")
redis_port = int(os.getenv("REDIS_PORT", "6379"))
redis_client = Redis(host=redis_host, port=redis_port, decode_responses=True)
# Kurze Zeitgrenzen: Ein Zwischenspeicher, auf den man wartet, ist keiner.
# Ohne sie hing jeder Aufruf am Standard-Timeout der Bibliothek.
redis_client = Redis(host=redis_host, port=redis_port, decode_responses=True,
socket_connect_timeout=1.5, socket_timeout=1.5)
# Erst beim ersten Zugriff bekannt. None = noch nichts versucht.
_erreichbar: Optional[bool] = None
def _melde_einmal(fehler: Exception) -> None:
"""Beim ERSTEN Fehlschlag eine Zeile, danach Ruhe."""
global _erreichbar
if _erreichbar is False:
return
_erreichbar = False
print("Zwischenspeicher (%s:%s) nicht erreichbar — es wird ohne "
"gearbeitet: %s" % (redis_host, redis_port, fehler))
def zustand() -> dict:
"""Woran man ist. Für Diagnose und Selbstauskunft."""
return {"host": redis_host, "port": redis_port, "erreichbar": _erreichbar}
def init_cache() -> None:
"""Initialize cache connection."""
pass
"""Einmal anklopfen, damit der Zustand bekannt ist. Wirft nie."""
global _erreichbar
try:
redis_client.ping()
_erreichbar = True
except (RedisError, OSError) as e:
_melde_einmal(e)
def get(key: str) -> Optional[Any]:
"""Get value from cache."""
"""Wert aus dem Zwischenspeicher. None = nicht da ODER kein Speicher."""
global _erreichbar
try:
value = redis_client.get(key)
except (RedisError, OSError) as e:
_melde_einmal(e)
return None
_erreichbar = True
if value:
try:
return json.loads(value)
except (TypeError, ValueError):
# Ein kaputter Eintrag ist kein Grund, den Aufrufer scheitern zu
# lassen — er holt sich die Antwort dann eben frisch.
return None
return None
def set(key: str, value: Any, expire: Optional[int] = None) -> bool:
"""Set value in cache."""
"""Wert ablegen. False heißt: ging nicht — und das ist in Ordnung."""
global _erreichbar
try:
serialized = json.dumps(value)
if expire:
return redis_client.setex(key, expire, serialized)
return redis_client.set(key, serialized)
return bool(redis_client.setex(key, expire, serialized))
return bool(redis_client.set(key, serialized))
except (RedisError, OSError) as e:
_melde_einmal(e)
return False
except (TypeError, ValueError):
# Nicht serialisierbar. Das ist ein Fehler des Aufrufers, aber keiner,
# der eine Metadaten-Abfrage umwerfen darf.
return False
def delete(key: str) -> bool:
"""Delete value from cache."""
return redis_client.delete(key)
try:
return bool(redis_client.delete(key))
except (RedisError, OSError) as e:
_melde_einmal(e)
return False
def clear() -> bool:
"""Clear all cache."""
return redis_client.flushdb()
try:
return bool(redis_client.flushdb())
except (RedisError, OSError) as e:
_melde_einmal(e)
return False
+117 -7
View File
@@ -2,19 +2,129 @@
Bis 23.07. gab es überhaupt keinen Code-Pfad, der je einen Rip auslöste —
kein POST /jobs, kein udev-Daemon. Dieser Client schließt die Lücke.
## Warum Celery hier erst bei Bedarf entsteht (V2-4, 28.08.2026)
Hier stand `celery_client = Celery(...)` auf Modulebene. Damit brauchte JEDER
Import von `main.py` ein funktionierendes Celery — auch dann, wenn nie ein Rip
angestoßen wird. Im Windows-Paket ist Celery bewusst NICHT enthalten (der
Standalone-Betrieb hat keinen Broker), und die fertige EXE starb sofort beim
Start:
File "celery_client.py", ...
celery_client = Celery("rippy_api", broker=REDIS_URL, ...)
ModuleNotFoundError: No module named 'celery.fixups'
Dasselbe Muster wie beim Store, der seine Engine beim Import baute: Was erst
bei der ersten Benutzung gebraucht wird, soll auch erst dann entstehen.
**Was das für den Windows-Betrieb bedeutet — ehrlich gesagt:** Die Oberfläche,
die Laufwerks-Erkennung und alles Lesende laufen dort. Ein RIP anzustoßen geht
noch nicht, weil die Zustellung weiterhin über Celery läuft; die Umstellung auf
die LocalQueue steht in Etappe V2-5. Bis dahin sagt `start_rip()` das
ausdrücklich, statt mit einem Importfehler zu sterben oder still nichts zu tun.
"""
import os
from celery import Celery
REDIS_URL = os.getenv("REDIS_URL", "redis://localhost:6379/0")
celery_client = Celery("rippy_api", broker=REDIS_URL, backend=REDIS_URL)
_client = None
# Wer Auftraege zustellt. None = Celery (verteilter Betrieb).
# Der Standalone-Betrieb setzt hier seine eigene Zustellung ein — siehe
# `zusteller_setzen()`.
_zusteller = None
class KeinBroker(RuntimeError):
"""Es gibt hier kein Celery — mit Ansage statt mit Importfehler."""
def hole_client():
"""Der Celery-Client, beim ERSTEN Zugriff gebaut."""
global _client
if _client is None:
try:
from celery import Celery
except ImportError as e:
raise KeinBroker(
"Celery ist in dieser Installation nicht enthalten. Rippy läuft "
"hier im Standalone-Betrieb; das Anstoßen von Rips über einen "
"Broker ist damit nicht möglich (Umstellung auf die lokale "
"Auftrags-Queue: Etappe V2-5)."
) from e
_client = Celery("rippy_api", broker=REDIS_URL, backend=REDIS_URL)
return _client
def __getattr__(name):
"""`celery_client` von außen — baut den Client bei Bedarf.
Damit bleiben die bestehenden `from celery_client import celery_client`
unverändert gültig, ohne dass der Import schon einen Broker verlangt.
"""
if name == "celery_client":
return hole_client()
raise AttributeError(f"module {__name__!r} has no attribute {name!r}")
def zusteller_setzen(funktion) -> None:
"""Legt fest, WER Auftraege bekommt.
Ohne Aufruf geht alles an Celery — das ist der Docker-Betrieb, unveraendert.
Der Standalone-Betrieb (Windows-App, Headless-Linux) setzt hier seine
lokale Auftrags-Queue ein; dann laeuft die Arbeit im selben Prozess.
Die Unterschrift ist die von `abschicken`:
funktion(task_name, args, queue=None) -> irgendetwas
Das ist bewusst dieselbe Form, die Celery hat. So muss keine Aufrufstelle
wissen, in welchem Betrieb sie gerade laeuft.
"""
global _zusteller
_zusteller = funktion
def abschicken(task_name: str, args: list, queue: str = None):
"""Einen Auftrag zustellen — an Celery oder an die lokale Queue.
EINE Stelle fuer alle drei Auftragsarten (rip_disc, transcode_files,
scan_tracks). Vorher rief jede Aufrufstelle `send_task` selbst auf; damit
haette der Standalone-Betrieb an drei Stellen umgebogen werden muessen —
und beim naechsten Auftragstyp an einer vierten.
"""
if _zusteller is not None:
return _zusteller(task_name, args, queue)
kwargs = {"args": args}
if queue:
kwargs["queue"] = queue
return hole_client().send_task(task_name, **kwargs)
def transcode_queue(node: str = None):
"""Ziel-Queue für die Kompression: der GEWÄHLTE Worker (worker_direct)
wenn er gerade online ist, sonst die geteilte transcode-Queue.
So kann ein Job gezielt einen Encoder ansprechen — fällt der Worker aber
weg, bleibt die Kompression nicht in einer toten Queue hängen, sondern
landet bei irgendeinem freien Worker.
"""
if not node:
return "transcode"
try:
from celery.utils import worker_direct
antworten = hole_client().control.ping(timeout=1.0) or []
online = {k for antwort in antworten for k in antwort.keys()}
if node in online:
return worker_direct(node)
except Exception:
pass
return "transcode"
def start_rip(device_path: str, job_id: str, target_dir: str = None):
"""Schickt den Rip-Task an den Worker (Task-Name aus worker/tasks.py)."""
return celery_client.send_task(
"worker.tasks.rip_disc", args=[device_path, job_id, target_dir]
)
"""Schickt den Rip-Auftrag los (Task-Name aus worker/tasks.py)."""
return abschicken("worker.tasks.rip_disc", [device_path, job_id, target_dir])
+12
View File
@@ -28,7 +28,19 @@ def titel_aehnlichkeit(a: str, b: str) -> float:
class JikanClient:
# Unter dieser Ähnlichkeit gibt lookup() gar nichts zurück.
MINDEST_AEHNLICHKEIT = 0.55
# Ab dieser Ähnlichkeit gilt der Treffer als SICHER und beendet die
# Metadaten-Kette. Dazwischen ist er nur ein Vorschlag: erst wird OMDb
# gefragt, und nur wenn das nichts hat, kommt er zum Zug.
#
# Warum zwei Schwellen (26.07.2026, ausgerechnet mit titel_aehnlichkeit):
# Eine einzelne Zahl kann beide Aufgaben nicht leisten. 0,55 lässt kurze
# Kinofilm-Titel durch, die hier nichts zu suchen haben („Alien" gegen
# „Alien 9" = 0,83), ist aber gleichzeitig zu streng für den Fall, für den
# diese Quelle gebaut wurde („Evangelion 2.22" gegen „Evangelion: 2.0 You
# Can (Not) Advance" = 0,51). Messwerte in test_jikan_helpers.py.
SICHER_AEHNLICHKEIT = 0.9
def __init__(self):
self.session = requests.Session()
+7 -2
View File
@@ -33,8 +33,13 @@ def parse_year(year: str) -> Optional[int]:
class OMDbClient:
def __init__(self):
# DB-Einstellung (Settings-UI/Wizard) gewinnt gegen die Env-Variable
from db import get_settings
self.api_key = get_settings().get("omdbApiKey") or settings.omdb_api_key
# ⚠️ rippy.store, NICHT db (Befund 28.08.2026). docker/api/db.py
# gibt es seit V2-1 (dd1d0b7) nicht mehr — main.py schreibt seitdem
# "from rippy import store as db", dieses Modul hat es nie
# mitbekommen. Jede Abfrage starb beim Erzeugen des Clients, und
# _auto_prescan verschluckte es. Siehe clients/tmdb.py.
from rippy.store import get_settings
self.api_key = get_settings(bei_fehler_leer=True).get("omdbApiKey") or settings.omdb_api_key
self.session = requests.Session()
def suche(self, title: str) -> list:
+7 -2
View File
@@ -13,8 +13,13 @@ THETVDB_BASE_URL = "https://api.thetvdb.com"
class TheTVDBClient:
def __init__(self):
# DB-Einstellung (Settings-UI/Wizard) gewinnt gegen die Env-Variable
from db import get_settings
self.api_key = get_settings().get("tvdbApiKey") or settings.thetvdb_api_key
# ⚠️ rippy.store, NICHT db (Befund 28.08.2026). docker/api/db.py
# gibt es seit V2-1 (dd1d0b7) nicht mehr — main.py schreibt seitdem
# "from rippy import store as db", dieses Modul hat es nie
# mitbekommen. Jede Abfrage starb beim Erzeugen des Clients, und
# _auto_prescan verschluckte es. Siehe clients/tmdb.py.
from rippy.store import get_settings
self.api_key = get_settings(bei_fehler_leer=True).get("tvdbApiKey") or settings.thetvdb_api_key
self.base_url = THETVDB_BASE_URL
self.session = requests.Session()
self.session.headers.update({
+69 -7
View File
@@ -11,21 +11,47 @@ TMDB_BASE_URL = "https://api.themoviedb.org/3"
TMDB_IMAGE_BASE_URL = "https://image.tmdb.org/t/p"
def ist_v4_token(key: str) -> bool:
"""Pure Funktion (testbar): TMDB hat ZWEI Key-Arten — der v4 Read Access
Token ist ein langes JWT ('eyJ…', Bearer-Header), der klassische v3-Key
32 Hex-Zeichen (api_key-Query-Parameter). Befund 24.07.: der Client konnte
NUR v4 — mit dem üblichen v3-Key aus dem TMDB-Konto war jede Anfrage 401
und die Suche lieferte still nur OMDb-Treffer."""
return bool(key) and key.startswith("eyJ")
class TMDBClient:
def __init__(self):
# DB-Einstellung (Settings-UI/Wizard) gewinnt gegen die Env-Variable —
# vorher war das Settings-Feld reine Dekoration (Fix 23.07.).
from db import get_settings
self.api_key = get_settings().get("tmdbApiKey") or settings.tmdb_api_key
# ⚠️ rippy.store, NICHT db (Befund 28.08.2026).
#
# Hier stand "from db import get_settings". docker/api/db.py gibt es
# seit der Zusammenlegung in V2-1 (dd1d0b7) nicht mehr — main.py
# schreibt seitdem "from rippy import store as db", aber dieses Modul
# hat das nie mitbekommen. Die Folge: JEDE Metadaten-Abfrage starb
# schon beim Erzeugen des Clients mit ModuleNotFoundError, und
# _auto_prescan verschluckte das in seinem "except Exception". Discs
# blieben namenlos — auf Windows UND auf der VM.
#
# bei_fehler_leer=True: Ohne Datenbank gilt der Schlüssel aus der
# Umgebung. Ein Metadaten-Client ist kein Grund, warum nichts geht.
from rippy.store import get_settings
self.api_key = get_settings(bei_fehler_leer=True).get("tmdbApiKey") or settings.tmdb_api_key
self.session = requests.Session()
self.session.headers.update({
"Authorization": f"Bearer {self.api_key}",
"Content-Type": "application/json"
})
self.session.headers.update({"Content-Type": "application/json"})
# Beide Key-Arten unterstützen (developer.themoviedb.org: v3 als
# api_key-Parameter, v4-Token als Bearer-Header)
self._key_params = {}
if ist_v4_token(self.api_key):
self.session.headers.update({"Authorization": f"Bearer {self.api_key}"})
elif self.api_key:
self._key_params = {"api_key": self.api_key}
def _request(self, endpoint: str, params: Dict = None) -> Optional[Dict]:
"""Mache API-Request mit Caching."""
from cache.keys import generate_tmdb_key
# Cache-Key OHNE den api_key — der gehört nicht in den Cache
cache_key = generate_tmdb_key(endpoint, params)
cached = get(cache_key)
@@ -35,7 +61,7 @@ class TMDBClient:
try:
response = self.session.get(
f"{TMDB_BASE_URL}/{endpoint}",
params=params,
params={**(params or {}), **self._key_params},
timeout=10
)
response.raise_for_status()
@@ -82,6 +108,42 @@ class TMDBClient:
params = {"language": "de-DE"}
return self._request(f"tv/{tv_id}", params)
def get_tv_season(self, tv_id: int, season: int) -> Optional[Dict]:
"""Staffel-Details inkl. Episoden-Laufzeiten (Basis fürs
Episoden-Matching; developer.themoviedb.org/reference/tv-season-details)."""
return self._request(f"tv/{tv_id}/season/{season}", {"language": "de-DE"})
def find_by_imdb(self, imdb_id: str) -> Optional[Dict]:
"""IMDb-ID → deutscher TMDB-Eintrag (/find, external_source=imdb_id;
developer.themoviedb.org/reference/find-by-id).
Zweck: OMDb liefert nur englische Texte — über die IMDb-ID holt sich
Rippy Titel/Beschreibung/Poster auf Deutsch nach (Commander-Wunsch).
"""
result = self._request(
f"find/{imdb_id}",
{"external_source": "imdb_id", "language": "de-DE"},
)
if not result:
return None
for schluessel, typ, titel_feld, datum_feld in (
("movie_results", "movie", "title", "release_date"),
("tv_results", "tv", "name", "first_air_date"),
):
eintraege = result.get(schluessel) or []
if eintraege:
e = eintraege[0]
datum = e.get(datum_feld) or ""
return {
"type": typ,
"tmdb_id": e.get("id"),
"title": e.get(titel_feld) or "",
"overview": e.get("overview") or "",
"poster_path": e.get("poster_path") or "",
"year": int(datum[:4]) if datum[:4].isdigit() else None,
}
return None
def get_movie_images(self, movie_id: int) -> Dict[str, str]:
"""Hole Poster/Fanart URLs."""
params = {"language": "de-DE", "include_image_language": "de,en,null"}
+2 -6
View File
@@ -24,12 +24,8 @@ class Settings(BaseSettings):
# Logging
log_level: str = Field(default="INFO", pattern="^(DEBUG|INFO|WARNING|ERROR|CRITICAL)$", description="Log Level")
# JWT — PFLICHT (auth.py verweigert den Start ohne; kein Zufalls-Fallback mehr)
jwt_secret_key: Optional[str] = Field(default=None, description="JWT Secret Key (PFLICHT, siehe .env)")
# Admin-Login (MVP — vorher hartkodiert admin/rippy123 in main.py)
admin_username: str = Field(default="admin", description="Admin-Benutzername")
admin_password: str = Field(default="rippy123", description="Admin-Passwort (per .env ÄNDERN!)")
# JWT/Admin-Login entfernt (Commander-Entscheid 24.07.2026): Rippy ist
# Heimnetz-only, es gab nie einen Login-Flow im UI — siehe KONZEPT §10.
class Config:
env_file = ".env"
+6 -10
View File
@@ -14,12 +14,14 @@ def validate_config() -> Settings:
try:
settings = Settings()
# TMDB API Key ist Pflicht (gemäß KONZEPT.md)
# TMDB-Key ist EMPFOHLEN, nicht zwingend: main.py fängt diesen Fehler ab und
# gibt nur eine Warnung aus — die API startet auch ohne Key, und der Key lässt
# sich jederzeit im UI (Einstellungen → System) nachtragen.
if not settings.tmdb_api_key:
raise ConfigValidationError(
"TMDB_API_KEY ist erforderlich für Metadaten-Lookup.\n"
"Hole dir einen免费en Key auf https://www.themoviedb.org/\n"
"Setze ihn als Umgebungsvariable: TMDB_API_KEY=dein_key"
"TMDB_API_KEY ist nicht gesetzt (empfohlen für Metadaten-Lookup).\n"
"Kostenlosen Key auf https://www.themoviedb.org/ holen und als\n"
"Umgebungsvariable TMDB_API_KEY setzen — oder später im UI eintragen."
)
return settings
@@ -48,10 +50,4 @@ def get_config_with_fallback() -> tuple[Settings, list[str]]:
"MUSICBRAINZ_USER nicht gesetzt. Öffentlicher Zugriff wird verwendet."
)
# Optional: JWT Secret (wird generiert, wenn nicht gesetzt)
if not settings.jwt_secret_key:
warnings.append(
"JWT_SECRET_KEY nicht gesetzt. Auto-Generierung wird verwendet."
)
return settings, warnings
+1 -4
View File
@@ -1,9 +1,6 @@
"""Pytest-Setup für API-Tests: flache Modul-Imports + Test-Secret."""
"""Pytest-Setup für API-Tests: flache Modul-Imports."""
import os
import sys
sys.path.insert(0, os.path.dirname(__file__))
# auth.py verweigert den Start ohne JWT_SECRET_KEY (gewollt) — Tests bringen ihres mit.
os.environ.setdefault("JWT_SECRET_KEY", "test-geheimnis-nur-fuer-tests")
-245
View File
@@ -1,245 +0,0 @@
"""Job-, Log- und Settings-Persistenz in PostgreSQL (KONZEPT: Postgres für Job-Logs).
Die jobs/logs-Tabellendefinition existiert bewusst identisch im Worker
(docker/worker/db.py) — es gibt kein geteiltes Paket zwischen den Containern.
Wer die Struktur ändert, ändert BEIDE Dateien. create_all ist idempotent.
Bis 23.07. lag Postgres komplett brach: GET /jobs gab hart [] zurück, nichts
schrieb je eine Zeile — der Job-Verlauf im UI war ein Placebo.
"""
import json
import os
from datetime import datetime, timezone
from sqlalchemy import (
Column,
DateTime,
Integer,
MetaData,
String,
Table,
Text,
create_engine,
select,
)
DATABASE_URL = os.getenv(
"DATABASE_URL", "postgresql://rippy:rippy@localhost:5432/rippy"
)
engine = create_engine(DATABASE_URL, pool_pre_ping=True)
metadata = MetaData()
jobs = Table(
"jobs",
metadata,
Column("id", String(36), primary_key=True),
Column("disc_type", String(16)),
Column("device", String(64)),
Column("title", String(255)),
Column("status", String(16), nullable=False, server_default="pending"),
Column("progress", Integer, nullable=False, server_default="0"),
Column("output_path", Text),
Column("target_dir", String(255)),
Column("error", Text),
Column("meta", Text), # Disc-Metadaten (JSON: Jahr/Poster/Plot) für Detail-Popup + NFO
Column("created_at", DateTime(timezone=True)),
Column("finished_at", DateTime(timezone=True)),
)
logs = Table(
"logs",
metadata,
Column("id", Integer, primary_key=True, autoincrement=True),
Column("ts", DateTime(timezone=True)),
Column("level", String(16)),
Column("source", String(32)),
Column("message", Text),
)
settings_table = Table(
"settings",
metadata,
Column("key", String(64), primary_key=True),
Column("value", Text),
)
workers = Table(
"workers",
metadata,
Column("name", String(128), primary_key=True),
Column("encoders", Text),
Column("info", Text), # Werkzeug-Versionen (JSON: makemkv/handbrake/key-Quelle)
Column("last_seen", DateTime(timezone=True)),
)
storage_mounts = Table(
"storage_mounts",
metadata,
Column("name", String(64), primary_key=True),
Column("typ", String(8)), # nfs | cifs
Column("quelle", String(255)), # host:/export bzw. //host/share
Column("optionen", String(255)),
Column("username", String(128)),
Column("passwort", String(255)), # Klartext — Heimnetz-Kompromiss, siehe README
)
def list_workers() -> list:
import json
with engine.connect() as conn:
zeilen = conn.execute(select(workers)).mappings().all()
ergebnis = []
for z in zeilen:
eintrag = dict(z)
try:
eintrag["encoders"] = json.loads(eintrag.get("encoders") or "[]")
except ValueError:
eintrag["encoders"] = []
try:
eintrag["info"] = json.loads(eintrag.get("info") or "{}")
except ValueError:
eintrag["info"] = {}
if eintrag.get("last_seen"):
eintrag["last_seen"] = eintrag["last_seen"].isoformat()
ergebnis.append(eintrag)
return ergebnis
def list_mounts() -> list:
with engine.connect() as conn:
return [dict(z) for z in conn.execute(select(storage_mounts)).mappings().all()]
def save_mount(name: str, typ: str, quelle: str, optionen: str, username: str, passwort: str) -> None:
with engine.begin() as conn:
conn.execute(
storage_mounts.insert().values(
name=name, typ=typ, quelle=quelle,
optionen=optionen, username=username, passwort=passwort,
)
)
def delete_mount(name: str) -> None:
with engine.begin() as conn:
conn.execute(storage_mounts.delete().where(storage_mounts.c.name == name))
def utcnow() -> datetime:
return datetime.now(timezone.utc)
def init_db() -> None:
"""Legt fehlende Tabellen an (idempotent) und zieht Mini-Migrationen nach."""
metadata.create_all(engine)
# create_all ändert BESTEHENDE Tabellen nicht — neue Spalten hier nachziehen:
with engine.begin() as conn:
conn.exec_driver_sql(
"ALTER TABLE jobs ADD COLUMN IF NOT EXISTS target_dir VARCHAR(255)"
)
conn.exec_driver_sql(
"ALTER TABLE jobs ADD COLUMN IF NOT EXISTS meta TEXT"
)
conn.exec_driver_sql(
"ALTER TABLE workers ADD COLUMN IF NOT EXISTS info TEXT"
)
def insert_job(
job_id: str, device: str, disc_type: str = None, title: str = None,
target_dir: str = None, meta: str = None,
) -> None:
with engine.begin() as conn:
conn.execute(
jobs.insert().values(
id=job_id,
device=device,
disc_type=disc_type,
title=title,
target_dir=target_dir,
meta=meta,
status="pending",
progress=0,
created_at=utcnow(),
)
)
def update_job(job_id: str, **fields) -> None:
with engine.begin() as conn:
conn.execute(jobs.update().where(jobs.c.id == job_id).values(**fields))
def get_job(job_id: str) -> dict:
with engine.connect() as conn:
zeile = conn.execute(
select(jobs).where(jobs.c.id == job_id)
).mappings().first()
return dict(zeile) if zeile else None
def list_jobs(limit: int = 100) -> list:
with engine.connect() as conn:
zeilen = conn.execute(
select(jobs).order_by(jobs.c.created_at.desc()).limit(limit)
).mappings().all()
return [dict(z) for z in zeilen]
def has_active_job(device: str) -> bool:
"""True, wenn auf dem Gerät ein Job läuft oder wartet (Eject-Schutz)."""
with engine.connect() as conn:
zeile = conn.execute(
select(jobs.c.id)
.where(jobs.c.device == device)
.where(jobs.c.status.in_(("pending", "running")))
.limit(1)
).first()
return zeile is not None
def add_log(level: str, source: str, message: str) -> None:
with engine.begin() as conn:
conn.execute(
logs.insert().values(ts=utcnow(), level=level, source=source, message=message)
)
def list_logs(limit: int = 200) -> list:
with engine.connect() as conn:
zeilen = conn.execute(
select(logs).order_by(logs.c.id.desc()).limit(limit)
).mappings().all()
return [dict(z) for z in zeilen]
def get_settings(key: str = "ui") -> dict:
with engine.connect() as conn:
zeile = conn.execute(
select(settings_table.c.value).where(settings_table.c.key == key)
).first()
if not zeile or not zeile[0]:
return {}
try:
return json.loads(zeile[0])
except ValueError:
return {}
def save_settings(werte: dict, key: str = "ui") -> None:
payload = json.dumps(werte)
with engine.begin() as conn:
vorhanden = conn.execute(
select(settings_table.c.key).where(settings_table.c.key == key)
).first()
if vorhanden:
conn.execute(
settings_table.update()
.where(settings_table.c.key == key)
.values(value=payload)
)
else:
conn.execute(settings_table.insert().values(key=key, value=payload))
-91
View File
@@ -1,91 +0,0 @@
"""Disc-Erkennung über Kernel-ioctls — ohne `file`, ohne udev.
Warum neu (Review 23.07.): Die alte Erkennung rief `file -L /dev/sr0` auf.
`file` liest ohne `-s` aber NIE den Inhalt eines Block-Devices — die Ausgabe ist
immer nur "block special", die Erkennung lieferte also strukturell IMMER
"unknown". Der alte Test hatte sich die `file`-Ausgabe passend gemockt und
bewies damit nichts.
Die ioctl-Konstanten stammen aus der Kernel-UAPI (include/uapi/linux/cdrom.h
bzw. linux/fs.h für BLKGETSIZE64) und sind seit Jahrzehnten stabil.
"""
import os
import struct
from fcntl import ioctl
# include/uapi/linux/cdrom.h
CDROM_DRIVE_STATUS = 0x5326
CDROM_DISC_STATUS = 0x5327
CDS_NO_DISC = 1
CDS_TRAY_OPEN = 2
CDS_DRIVE_NOT_READY = 3
CDS_DISC_OK = 4
CDS_AUDIO = 100
CDS_DATA_1 = 101
CDS_DATA_2 = 102
CDS_XA_2_1 = 103
CDS_XA_2_2 = 104
CDS_MIXED = 105
# include/uapi/linux/fs.h: BLKGETSIZE64 = _IOR(0x12, 114, size_t) auf 64-bit
BLKGETSIZE64 = 0x80081272
# Eine DVD9 fasst ~8,5 GB; Blu-ray beginnt bei 25 GB (Single Layer).
# Alles ab 10 GB ist also sicher eine Blu-ray.
BLURAY_MIN_BYTES = 10 * 1024**3
def _open_nonblock(device_path: str) -> int:
"""O_NONBLOCK ist Pflicht: ohne blockiert open() bis eine Disc eingelegt ist."""
return os.open(device_path, os.O_RDONLY | os.O_NONBLOCK)
def drive_status(device_path: str) -> int:
"""CDROM_DRIVE_STATUS: 1=keine Disc, 2=Schublade offen, 3=nicht bereit, 4=Disc ok."""
fd = _open_nonblock(device_path)
try:
return ioctl(fd, CDROM_DRIVE_STATUS, 0)
finally:
os.close(fd)
def disc_status(device_path: str) -> int:
"""CDROM_DISC_STATUS: 100=Audio, 101-104=Daten, 105=Mixed."""
fd = _open_nonblock(device_path)
try:
return ioctl(fd, CDROM_DISC_STATUS, 0)
finally:
os.close(fd)
def disc_size_bytes(device_path: str) -> int:
"""Größe des eingelegten Mediums in Bytes (BLKGETSIZE64)."""
fd = _open_nonblock(device_path)
try:
buf = bytearray(8)
ioctl(fd, BLKGETSIZE64, buf)
return struct.unpack("Q", bytes(buf))[0]
finally:
os.close(fd)
def classify(disc_status_code: int, size_bytes: int) -> str:
"""Pure Zuordnung (testbar): Disc-Status + Größe → cd | dvd | bluray | unknown."""
if disc_status_code in (CDS_AUDIO, CDS_MIXED):
return "cd"
if disc_status_code in (CDS_DATA_1, CDS_DATA_2, CDS_XA_2_1, CDS_XA_2_2):
return "bluray" if size_bytes >= BLURAY_MIN_BYTES else "dvd"
return "unknown"
def detect_disc_type(device_path: str) -> str:
"""Erkennt den Typ der eingelegten Disc; 'no_disc' wenn keine drin ist."""
try:
if drive_status(device_path) != CDS_DISC_OK:
return "no_disc"
return classify(disc_status(device_path), disc_size_bytes(device_path))
except OSError:
return "unknown"
-76
View File
@@ -1,76 +0,0 @@
"""Laufwerks-Discovery über /sys und ioctls — ehrlich, ohne udev.
Warum kein udevadm mehr: Im Container läuft kein udevd, die udev-Datenbank ist
leer — `udevadm info` lieferte schlicht nichts (der alte Weg zeigte deshalb nie
ein Laufwerk an). /sys/class/block/<name>/device/{vendor,model} kommt dagegen
direkt vom Kernel und funktioniert überall.
"""
import glob
import os
from fcntl import ioctl
from detection import (
CDS_DISC_OK,
classify,
disc_size_bytes,
disc_status,
drive_status,
)
# include/uapi/linux/cdrom.h
CDROMEJECT = 0x5309
def eject(device_path: str) -> None:
"""Wirft die Disc aus (CDROMEJECT-ioctl). Wirft OSError bei Fehlern."""
fd = os.open(device_path, os.O_RDONLY | os.O_NONBLOCK)
try:
ioctl(fd, CDROMEJECT, 0)
finally:
os.close(fd)
def list_optical_devices() -> list:
"""Alle optischen Laufwerke, die der Container sieht (devices: in compose)."""
return sorted(glob.glob("/dev/sr[0-9]*"))
def read_sys_attr(device_name: str, attr: str) -> str:
pfad = f"/sys/class/block/{device_name}/device/{attr}"
try:
with open(pfad, encoding="ascii", errors="replace") as f:
return f.read().strip()
except OSError:
return ""
def device_info(device_path: str) -> dict:
"""Baut den Geräte-Eintrag fürs UI: Name aus /sys, Disc-Status per ioctl."""
name = os.path.basename(device_path)
vendor = read_sys_attr(name, "vendor")
model = read_sys_attr(name, "model")
try:
status_code = drive_status(device_path)
except OSError:
status_code = -1
disc_type = "unknown"
status = "empty"
if status_code == CDS_DISC_OK:
status = "ready"
try:
disc_type = classify(disc_status(device_path), disc_size_bytes(device_path))
except OSError:
disc_type = "unknown"
return {
"id": name,
"name": " ".join(teil for teil in (vendor, model) if teil) or f"Laufwerk {name}",
"type": disc_type,
"path": device_path,
"status": status,
"model": model,
"serial": read_sys_attr(name, "wwid"),
}
+173
View File
@@ -0,0 +1,173 @@
"""Restzeit-Schätzung für laufende Jobs — aus dem gemessenen Fortschritt.
Commander-Anforderung 26.07.2026: *„Der Server Status muss dringend überarbeitet
werden, das Dashboard soll ja quasi alles auf einen Blick zeigen"* — dazu eine
**ETA** im Dashboard und beim externen Worker.
## Warum hier und nicht im Browser
Der naheliegende Weg wäre, den Fortschritt im UI mitzuschreiben. Drei Gründe
dagegen: Ein Seitenwechsel setzt die Messreihe zurück; zwei offene Browser
zeigten verschiedene Zahlen; und die Kompression läuft womöglich auf einer
ANDEREN Maschine (genau dort wollte der Commander die ETA sehen). Die Reihe
gehört also dorthin, wo der Fortschritt ankommt.
## Warum nicht einfach „vergangene Zeit / Prozent"
Weil ein Job zwei völlig verschiedene Phasen hat: Der Rip dauert rund eine
Stunde, die Kompression Stunden bis Tage (auf der Rippy-VM gemessene 28-55 h je
4K-Film). Aus dem Gesamt-Mittel entstünde bei jedem Phasenwechsel eine
haarsträubende Zahl. Deshalb wird die Messreihe bei JEDEM Statuswechsel
verworfen und die Rate nur innerhalb der laufenden Phase bestimmt.
## Ehrlichkeit vor Zahl
Lieber „wird noch geschätzt" als eine erfundene Minute:
- Unter MINDEST_PUNKTE Messwerten gibt es keine Schätzung.
- Die Reihe muss MINDEST_SPANNE_SEKUNDEN abdecken UND MINDEST_FORTSCHRITT
Prozentpunkte gestiegen sein — bei 4K bewegt sich eine halbe Stunde lang
nichts, daraus ließe sich sonst „fertig in 3 Minuten" ableiten.
- Nur die letzten FENSTER Punkte zählen: HandBrake wird bei komplexen Szenen
langsamer, die frühen Werte lügen dann.
- Über OBERGRENZE_SEKUNDEN wird nicht mehr aufs Detail gerechnet, sondern
„mehr als 2 Tage" gesagt. Eine Zahl wie „51:23 h" wirkt genau, ist es aber
nicht.
"""
MINDEST_PUNKTE = 2
MINDEST_SPANNE_SEKUNDEN = 60
MINDEST_FORTSCHRITT = 1
FENSTER = 10
OBERGRENZE_SEKUNDEN = 48 * 3600
# Status, für die eine Restzeit überhaupt Sinn hat.
LAUFENDE_STATUS = ("running", "processing", "ripping", "transcoding")
def beobachtung_hinzufuegen(reihe, status: str, progress: int, jetzt: float) -> dict:
"""Neuen Messpunkt anfügen (pure Funktion) → die aktualisierte Reihe.
`reihe` ist {"status": str, "punkte": [[zeit, prozent], ...]} oder None.
Bei Statuswechsel beginnt die Reihe neu — siehe Modul-Doku (Rip und
Kompression haben nichts miteinander zu tun).
Ein unveränderter Fortschritt wird NICHT als neuer Punkt angefügt, aber der
letzte Punkt behält seine ursprüngliche Zeit. Das ist wichtig: Ein Stillstand
verlängert damit automatisch die gemessene Spanne und macht die Schätzung
langsamer — genau richtig, denn er heißt ja, dass es langsam vorangeht.
"""
alt = reihe or {}
punkte = list(alt.get("punkte") or []) if alt.get("status") == status else []
if not punkte or punkte[-1][1] != progress:
punkte.append([jetzt, progress])
return {"status": status, "punkte": punkte[-FENSTER:]}
def restzeit_sekunden(reihe, jetzt: float) -> int:
"""Geschätzte Restzeit in Sekunden — oder -1 für „noch keine Aussage".
-1 statt None, damit der Wert unverändert durch JSON und das
Antwort-Modell passt (dasselbe Muster wie get_progress_from_line im
Worker, wo -1 „keine Angabe" heißt).
"""
punkte = (reihe or {}).get("punkte") or []
if len(punkte) < MINDEST_PUNKTE:
return -1
erste_zeit, erster_prozent = punkte[0]
letzte_zeit, letzter_prozent = punkte[-1]
# Die Spanne bis JETZT, nicht bis zum letzten Punkt: sonst zeigt ein
# stehender Job dauerhaft die Rate von vor drei Stunden.
spanne = max(jetzt, letzte_zeit) - erste_zeit
gewachsen = letzter_prozent - erster_prozent
if spanne < MINDEST_SPANNE_SEKUNDEN or gewachsen < MINDEST_FORTSCHRITT:
return -1
rest_prozent = 100 - letzter_prozent
if rest_prozent <= 0:
return 0
pro_prozent = spanne / gewachsen
return int(rest_prozent * pro_prozent)
def formatiere_restzeit(sekunden: int) -> str:
"""Restzeit als Text fürs UI. Leer, wenn es keine Aussage gibt."""
if sekunden is None or sekunden < 0:
return ""
if sekunden > OBERGRENZE_SEKUNDEN:
return "mehr als 2 Tage"
if sekunden < 60:
return "unter einer Minute"
minuten = sekunden // 60
if minuten < 60:
return f"noch ca. {minuten} min"
stunden, rest_minuten = divmod(minuten, 60)
if stunden < 24:
return f"noch ca. {stunden} h {rest_minuten:02d} min"
tage, rest_stunden = divmod(stunden, 24)
return f"noch ca. {tage} Tag{'e' if tage > 1 else ''} {rest_stunden} h"
def schluessel(job_id: str) -> str:
return f"eta:{job_id}"
#: Messreihen im eigenen Prozess — der Rückfall, wenn es kein Redis gibt.
#:
#: ## Der Befund des Commanders (29.08.2026)
#:
#: > „Über den kompletten vorgang steht dort Restzeit wird gemessen' aber
#: > messung wird nicht abgeschlossen. Das heißt man hat kein ETA"
#:
#: Die Messreihe lag ausschließlich im Cache, und der Modul-Kopf sagte dazu:
#: „Der Cache (Redis) ist schon da". Im Container stimmt das. Auf einem
#: Windows-PC gibt es kein Redis — `cache_get` gab bei JEDEM Aufruf `None`
#: zurück, `beobachtung_hinzufuegen` legte also jedes Mal eine frische Reihe
#: mit EINEM Punkt an, und `restzeit_sekunden` braucht `MINDEST_PUNKTE = 2`.
#: Ergebnis: über den ganzen Rip hinweg „noch keine Aussage".
#:
#: Ein Wörterbuch im Prozess reicht hier vollkommen: Die Reihe ist ein paar
#: Zahlen, sie gilt nur für die Dauer eines Jobs, und im eigenständigen
#: Betrieb gibt es ohnehin nur diesen einen Prozess. Redis bleibt der bessere
#: Ort, wo es eins gibt — es überlebt einen API-Neustart.
_REIHEN: dict = {}
#: Wie lange eine Reihe im Prozess aufgehoben wird (wie `expire` im Cache).
REIHE_HALTBAR_SEKUNDEN = 86400
def _aufraeumen(jetzt: float) -> None:
"""Alte Reihen wegwerfen — sonst waechst das Woerterbuch unbegrenzt."""
for k, (stand, _) in list(_REIHEN.items()):
if jetzt - stand > REIHE_HALTBAR_SEKUNDEN:
_REIHEN.pop(k, None)
def aktualisiere_und_schaetze(job_id: str, status: str, progress: int,
jetzt: float, cache_get, cache_set) -> dict:
"""Messreihe fortschreiben und die Restzeit zurückgeben.
Gespeichert wird in BEIDEN Ablagen: im Cache, wo es einen gibt (er
überlebt einen API-Neustart), und im Prozess, damit die Schätzung auch
ohne Redis zustande kommt. Siehe `_REIHEN`.
"""
if status not in LAUFENDE_STATUS or progress <= 0:
return {"sekunden": -1, "text": ""}
k = schluessel(job_id)
try:
reihe = cache_get(k)
except Exception:
reihe = None
if not reihe:
# Kein Cache (oder leer) — dann der eigene Vorrat.
eintrag = _REIHEN.get(k)
reihe = eintrag[1] if eintrag else None
reihe = beobachtung_hinzufuegen(reihe, status, progress, jetzt)
try:
# Eine Reihe ohne Fortschritt ist nach einem Tag wertlos.
cache_set(k, reihe, expire=REIHE_HALTBAR_SEKUNDEN)
except Exception:
pass
_REIHEN[k] = (jetzt, reihe)
_aufraeumen(jetzt)
sekunden = restzeit_sekunden(reihe, jetzt)
return {"sekunden": sekunden, "text": formatiere_restzeit(sekunden)}
-110
View File
@@ -1,110 +0,0 @@
"""Jellyfin Image Downloader."""
import requests
from pathlib import Path
from typing import Dict, Optional
from clients.tmdb import TMDBClient
from clients.thetvdb import TheTVDBClient
class ImageDownloader:
def __init__(self):
self.tmdb = TMDBClient()
self.thetvdb = TheTVDBClient()
self.base_url = "https://image.tmdb.org/t/p"
def download_image(self, url: str, output_path: Path, width: int = 500) -> bool:
"""Lade Image herunter."""
try:
# TMDB URL anpassen
if url.startswith("https://image.tmdb.org"):
# Konvertiere zu gewünschter Größe
path = url.replace(f"{self.base_url}/", "")
url = f"{self.base_url}/w{width}/{path}"
response = requests.get(url, timeout=30)
response.raise_for_status()
output_path.parent.mkdir(parents=True, exist_ok=True)
with open(output_path, 'wb') as f:
f.write(response.content)
return True
except Exception as e:
print(f"Image download error: {e}")
return False
def download_poster(self, title: str, output_dir: Path, width: int = 500) -> Optional[Path]:
"""Lade Poster herunter."""
# TMDB Search
movies = self.tmdb.search_movie(title)
if movies:
movie = movies[0]
images = self.tmdb.get_movie_images(movie["id"])
if images.get("poster"):
output_path = output_dir / "poster.jpg"
if self.download_image(images["poster"], output_path, width):
return output_path
return None
def download_fanart(self, title: str, output_dir: Path, width: int = 1920) -> Optional[Path]:
"""Lade Fanart herunter."""
# TMDB Search
movies = self.tmdb.search_movie(title)
if movies:
movie = movies[0]
images = self.tmdb.get_movie_images(movie["id"])
if images.get("fanart"):
output_path = output_dir / "fanart.jpg"
if self.download_image(images["fanart"], output_path, width):
return output_path
return None
def download_series_images(self, title: str, output_dir: Path) -> Dict[str, Optional[Path]]:
"""Lade Serien-Poster und Fanart herunter."""
result = {
"poster": None,
"fanart": None
}
tv_shows = self.tmdb.search_tv(title)
if tv_shows:
tv = tv_shows[0]
images = self.tmdb.get_tv_images(tv["id"])
if images.get("poster"):
output_path = output_dir / "poster.jpg"
if self.download_image(images["poster"], output_path, 500):
result["poster"] = output_path
if images.get("fanart"):
output_path = output_dir / "fanart.jpg"
if self.download_image(images["fanart"], output_path, 1920):
result["fanart"] = output_path
return result
def download_music_images(self, artist: str, album: str, output_dir: Path) -> Dict[str, Optional[Path]]:
"""Lade Musik-Album-Cover herunter (via TMDB als Fallback)."""
result = {
"album": None
}
# TMDB Search für Soundtracks
query = f"{album} soundtrack"
movies = self.tmdb.search_movie(query)
if movies:
movie = movies[0]
images = self.tmdb.get_movie_images(movie["id"])
if images.get("poster"):
output_path = output_dir / "album.jpg"
if self.download_image(images["poster"], output_path, 500):
result["album"] = output_path
return result
+2603 -347
View File
File diff suppressed because it is too large Load Diff
+87
View File
@@ -0,0 +1,87 @@
"""Automatische Erneuerung des MakeMKV-Beta-Keys.
Der kostenlose MakeMKV-Beta-Key (Forum-Thread "MakeMKV is free while in beta",
t=1053) wechselt etwa monatlich und läuft zum Monatsende ab. Ohne gültigen Key
fällt Blu-ray/UHD-Ripping in den 30-Tage-Testmodus; DVD-Ripping bleibt frei.
Bisher musste der Key von Hand nachgetragen werden (UI: Einstellungen -> System).
Dieses Modul holt den aktuellen Key vom Forum und schreibt ihn in die Settings
(makemkvAppKey). Der Worker liest den Key VOR jedem Rip aus den Settings
(docker/worker/tasks.py) und schreibt settings.conf -> die Erneuerung wirkt ohne
Rebuild/Neustart, ab dem nächsten Rip.
Wichtig: Das ist die kostenlose, oeffentliche Beta-LIZENZ der Software selbst
NICHT das Entschluesseln oder Verteilen von Disc-Schluesseln. Diese Grenze gilt
unveraendert; Rippy liefert keine Disc-Schluessel mit und verteilt keine.
Richtigstellung 25.07.2026: Hier stand früher, MakeMKV ziehe den AACS-Schluessel
via LibreDrive ohnehin selbst aus dem Laufwerk. Das stimmt für Blu-ray, aber
NICHT für 4K-UHD dort braucht MakeMKV den Volume-Key der jeweiligen Pressung,
und den bekommt es weder aus dem Laufwerk noch (heute) aus dem Netz. Belege und
Messungen stehen im Modul-Kopf von makemkv_daten.py.
Quelle/Format dokumentiert (AGENTS Regel D nicht geraten):
- Forum-Thread: https://forum.makemkv.com/forum/viewtopic.php?t=1053
- Key-Format: "T-" + langer String aus [A-Za-z0-9_] (typ. ~66 Zeichen; die exakte
Laenge variiert je Key, darum kein fixes Limit, sondern mind. 50, greedy).
"""
import asyncio
import re
FORUM_URL = "https://forum.makemkv.com/forum/viewtopic.php?t=1053"
KEY_RE = re.compile(r"T-[A-Za-z0-9_]{50,}")
_HEADERS = {"User-Agent": "rippy-makemkv-key-refresh/1.0"}
def extract_key(html: str) -> str | None:
"""Zieht den Beta-Key ("T-...") aus dem Forum-HTML. Pure Funktion -> testbar."""
treffer = KEY_RE.search(html or "")
return treffer.group(0) if treffer else None
def fetch_current_key(timeout: int = 15) -> str | None:
"""Holt den aktuellen Beta-Key vom MakeMKV-Forum. None bei Fehler/kein Treffer."""
import requests # lazy: hält extract_key + den Test dependency-frei
antwort = requests.get(FORUM_URL, headers=_HEADERS, timeout=timeout)
antwort.raise_for_status()
return extract_key(antwort.text)
def _apply_key(key: str) -> bool:
"""Merge den Key in die Settings. save_settings überschreibt das GANZE JSON,
darum erst lesen, dann setzen. Rueckgabe True, wenn sich der Key geaendert hat."""
from rippy import store as db
einstellungen = db.get_settings()
if (einstellungen.get("makemkvAppKey") or "").strip() == key:
return False
einstellungen["makemkvAppKey"] = key
db.save_settings(einstellungen)
return True
async def refresh_once() -> bool:
"""Einmal holen + anwenden. Best-effort, loggt in die App-Logs. True = geaendert."""
from rippy import store as db
key = await asyncio.to_thread(fetch_current_key)
if not key:
db.add_log("warning", "makemkv-key",
"Aktueller Beta-Key nicht im Forum gefunden (Format geaendert?).")
return False
geaendert = await asyncio.to_thread(_apply_key, key)
if geaendert:
db.add_log("success", "makemkv-key",
f"MakeMKV-Beta-Key automatisch erneuert (…{key[-6:]}).")
return geaendert
async def refresh_loop(intervall_stunden: int = 24, start_verzoegerung_s: int = 60) -> None:
"""Periodische Erneuerung (Default: taeglich, damit ein Monatswechsel nie verpasst
wird). Fehler werden geloggt, aber nie geworfen -> die API läuft weiter."""
from rippy import store as db
await asyncio.sleep(start_verzoegerung_s)
while True:
try:
await refresh_once()
except Exception as exc:
db.add_log("warning", "makemkv-key", f"Key-Refresh fehlgeschlagen: {exc!r}")
await asyncio.sleep(max(3600, intervall_stunden * 3600))
+283 -6
View File
@@ -11,18 +11,30 @@ sondern über eine temporäre credentials-Datei).
"""
import os
import posixpath
from rippy.platform.winlauf import OHNE_FENSTER
import re
import subprocess
import tempfile
import db
from rippy import store as db
MEDIA_ROOT = "/app/media"
NAME_MUSTER = re.compile(r"^[a-z0-9][a-z0-9-]{1,30}$")
def _mountpoint(name: str) -> str:
return os.path.join(MEDIA_ROOT, name)
"""Mountpunkt eines Speicherziels — IMMER ein Container-Pfad.
posixpath statt os.path (Befund 26.07.2026): Innerhalb des api-Containers
ist das dasselbe, aber `pfad_map_vorschlag()` liefert diesen Pfad an einen
WINDOWS-Worker aus. Mit os.path.join entstand beim Test unter Windows
`/app/media\\rippy`, und `pfad_lokal()` fand dann kein Präfix das Mapping
wäre still wirkungslos geblieben. Dieselbe Falle wie bei `_zielbasis()` im
Worker (v3.14), diesmal vom Test gefunden statt live.
"""
return posixpath.join(MEDIA_ROOT, name)
def validiere_name(name: str) -> bool:
@@ -30,7 +42,87 @@ def validiere_name(name: str) -> bool:
def ist_gemountet(name: str) -> bool:
"""Ist unter /app/media/<name> etwas gemountet? Ein TOTER CIFS-Mount
(NAS weg) lässt os.path.ismount mit OSError fliegen das zählt weiter
als 'gemountet' (nur eben kaputt), damit die Reparatur greift."""
try:
return os.path.ismount(_mountpoint(name))
except OSError:
return True
def ist_erreichbar(name: str) -> bool:
"""Kann auf das Ziel WIRKLICH zugegriffen werden?
Ein toter CIFS-Mount (Host weg, stale) ist zwar 'gemountet', aber jeder
Zugriff scheitert. Der Zugriff wird HART auf 3 s begrenzt (`timeout 3 ls`)
ein direktes os.listdir blockierte sonst bis zum CIFS-Timeout (~10 s,
Befund 24.07.: die Speicherziele-Seite lud dadurch träge).
"""
ziel = _mountpoint(name)
try:
ergebnis = subprocess.run(
["timeout", "3", "ls", ziel], capture_output=True,
creationflags=OHNE_FENSTER, timeout=5
)
return ergebnis.returncode == 0
except (OSError, subprocess.TimeoutExpired):
return False
def pfad_lage(ziel: str) -> str:
"""Existiert dieses Verzeichnis? „da" | „weg" | „unklar" — mit Zeitgrenze.
Der Grund, warum es das gibt (Befund 26.07.2026, an Zeitstempeln gemessen):
Eine Wiederanbindung brauchte **3 Minuten 15 Sekunden**, und die Zeit ging
nicht in die Mount-Versuche, sondern in die allererste Zeile von `mounten()`:
os.makedirs(ziel, exist_ok=True)
`exist_ok` prüft mit `os.path.isdir()`, und ein `stat` auf einen TOTEN
CIFS-Mount blockiert im Kernel bis zum SMB-Timeout. Ausgerechnet der Aufruf,
der nur lege den Ordner an, falls er fehlt" bedeutet, hing also drei Minuten
bevor irgendeine der sorgfältig begrenzten Prüfungen überhaupt dran war.
Dritter Fund derselben Sorte an einem Tag: os-Aufruf auf einen Netzpfad ohne
Zeitgrenze.
Deshalb wird die Lage jetzt mit einem Kind-Prozess erfragt (`timeout 4 ls`),
der sich abbrechen lässt. unklar" heißt: existiert, antwortet aber nicht —
dann ist ein makedirs weder nötig noch möglich.
"""
try:
ergebnis = subprocess.run(
["timeout", "4", "ls", "-d", ziel], capture_output=True,
creationflags=OHNE_FENSTER, timeout=6
)
except (OSError, subprocess.TimeoutExpired):
return "unklar"
if ergebnis.returncode == 0:
return "da"
return "unklar" if ergebnis.returncode == 124 else "weg"
def wirklich_erreichbar(name: str, warten=None) -> bool:
"""Antwortet die Freigabe auch noch DREI SEKUNDEN später? (zweimal geprüft)
Warum zweimal (Befund 26.07.2026): Direkt nach einem frischen `mount`
antwortete die Freigabe reproduzierbar und Sekunden später lief jeder
Zugriff in die Zeitgrenze. Ursache ist ein Wettlauf beim Aufräumen:
`_stale_mounts_loesen` benutzt `umount -l`, und das ist LAZY es hängt den
Mount sofort aus der Sicht aus, der eigentliche Abbau passiert später. Fällt
dieser Abbau samt Propagation (rshared) hinter den neuen Mount, zeigt der
Pfad wieder auf die Leiche.
Eine einzige Probe kann das nicht sehen. Zwei mit Abstand schon.
"""
if warten is None:
import time
warten = time.sleep
if not ist_erreichbar(name):
return False
warten(3)
return ist_erreichbar(name)
def schreibtest(pfad: str) -> bool:
@@ -49,6 +141,42 @@ def schreibtest(pfad: str) -> bool:
return False
def _stale_mounts_loesen(ziel: str) -> int:
"""Loest ALLE (evtl. gestapelten/toten) Mounts an `ziel` per lazy umount.
Warum: mounten() fällt bei einem TOTEN Mount (os.path.ismount wirft OSError)
auf den echten `mount` durch der stapelt dann auf die Leiche. Vorfall 24.07.:
über viele Neustarts 12 Schichten, die tote oberste blockierte jeden Zugriff
(ls-Timeout, obwohl SMB-445 offen). Erst alle Schichten loesen macht das
Re-Mounten idempotent. `umount -l` (lazy) hängt nicht an einem toten CIFS.
Rueckgabe: Zahl der geloesten Schichten.
"""
geloest = 0
for _ in range(20): # harte Obergrenze gegen Endlosschleife
try:
ergebnis = subprocess.run(
["umount", "-l", ziel], capture_output=True, timeout=10
)
except (OSError, subprocess.TimeoutExpired):
break
if ergebnis.returncode != 0:
break # nichts (mehr) gemountet
geloest += 1
if geloest:
# ⚠️ Kurz durchatmen, BEVOR neu gemountet wird (Befund 26.07.2026).
# `umount -l` ist lazy: Es hängt sofort aus der Sicht aus, der eigentliche
# Abbau samt Propagation (rshared) passiert später. Wer direkt danach
# mountet, riskiert, dass dieser Abbau HINTER dem neuen Mount landet und
# der Pfad wieder auf die Leiche zeigt. Genau das hat die erste
# Reparatur regelmäßig scheitern lassen — und der zweite Versuch mit
# seinen 30 s Timeout war der Grund, warum eine Wiederanbindung rund
# 150 Sekunden brauchte. Anderthalb Sekunden Warten sparen die.
import time
time.sleep(1.5)
return geloest
def uebersetze_smb_fehler(fehler: str, mit_credentials: bool) -> str:
"""Pure Funktion (testbar): NT_STATUS-Kauderwelsch → handelbarer Klartext.
@@ -113,6 +241,65 @@ def liste_smb_freigaben(host: str, username: str = "", passwort: str = "") -> li
return freigaben
def unc_aus_quelle(typ: str, quelle: str) -> str:
"""`//host/freigabe` → `\\\\host\\freigabe` (pure Funktion, testbar).
Nur für CIFS/SMB. NFS gibt "" zurück: Windows kann NFS zwar einhängen
(optionale Funktion Client für NFS"), die Schreibweise ist aber eine
andere und der Export-Pfad lässt sich nicht zuverlässig übersetzen
raten verstößt gegen AGENTS Regel D.
"""
if typ != "cifs" or not quelle:
return ""
rest = quelle.strip()
if not rest.startswith("//"):
return ""
return "\\\\" + rest[2:].replace("/", "\\")
def pfad_map_vorschlag(eintraege: list) -> list:
"""Welcher Container-Pfad entspricht welcher Windows-Freigabe?
Das ist der fehlende Anschluss für `RIPPY_PATH_MAP` (Befund 26.07.2026):
Ein externer Worker bekommt von Rippy Pfade wie `/app/media/rippy/<job>`
das sind Pfade INNERHALB des Containers. Er sieht sie nur, wenn sie auf
eine Netzwerk-Freigabe übersetzt werden, und dieses Mapping wurde bis
dahin von niemandem gesetzt. Externes Encoden konnte also nie laufen.
Geraten werden muss dafür nichts: Rippy hat die Freigabe selbst
eingehängt und kennt ihre Quelle (z. B. `//NAS/rippy`). Der Mountpunkt ist
`/app/media/<name>`, und beides zusammen IST das Mapping.
"""
vorschlaege = []
for eintrag in eintraege or []:
name = (eintrag.get("name") or "").strip()
if not name:
continue
typ = (eintrag.get("typ") or "").strip()
unc = unc_aus_quelle(typ, eintrag.get("quelle") or "")
vorschlaege.append({
"name": name,
"typ": typ,
"quelle": eintrag.get("quelle") or "",
"container": _mountpoint(name),
"unc": unc,
"gemountet": ist_gemountet(name),
})
return vorschlaege
def pfad_map_zeile(vorschlaege: list) -> str:
"""Die Vorschläge als fertiger RIPPY_PATH_MAP-Wert (pure Funktion).
Format wie `worker/tasks.pfad_lokal()` es liest: Paare `container=ziel`,
getrennt durch `;`. Einträge ohne übersetzbaren UNC-Pfad (NFS) fallen
weg ein halbes Mapping wäre schlimmer als keines, weil `pfad_lokal`
beim ersten passenden Präfix aufhört.
"""
paare = [f"{v['container']}={v['unc']}" for v in vorschlaege or [] if v.get("unc")]
return ";".join(paare)
def mounten(name: str, typ: str, quelle: str, optionen: str = "",
username: str = "", passwort: str = "") -> bool:
"""Hängt ein NFS/CIFS-Ziel unter /app/media/<name> ein.
@@ -121,9 +308,44 @@ def mounten(name: str, typ: str, quelle: str, optionen: str = "",
Mount-Fehlern.
"""
ziel = _mountpoint(name)
# Den Ordner NUR anlegen, wenn er wirklich fehlt — und das mit Zeitgrenze
# klären (siehe pfad_lage): `os.makedirs(..., exist_ok=True)` hing auf einem
# toten CIFS-Mount drei Minuten im Kernel, weil `exist_ok` ein `stat` macht.
if pfad_lage(ziel) == "weg":
try:
os.makedirs(ziel, exist_ok=True)
except OSError:
pass # Rennen mit einem anderen Aufruf oder Rechte — mount sagt es
# ⚠️ ERREICHBARKEIT VOR ismount — nicht umgekehrt (Befund 26.07.2026).
#
# Vorher stand hier `if os.path.ismount(ziel): return schreibtest(ziel)`.
# Das hatte zwei Folgen, beide am selben Nachmittag gemessen:
#
# 1. Nach `docker compose up -d --build` war die CIFS-Freigabe TOT (4 von 4
# Zugriffen liefen in 10 s Timeout, /storage-mounts meldete
# `reachable: false`) — und blieb es. Der Mountpunkt existierte im neuen
# Container weiter (Bind-Mount vom Host), `ismount` sagte also „ist schon
# da" und das Wiederherstellen brach genau hier ab. Die Reparatur per
# POST /storage-mounts/rippy/repair stellte sie in einer Sekunde her —
# beim Start hätte dasselbe passieren müssen.
# 2. `schreibtest()` öffnet eine Datei OHNE Zeitgrenze. Auf einem toten CIFS
# blockiert das im Kernel (Thread-Zustand D), und `alle_remounten()`
# hängt beim API-Start dauerhaft in einem Hintergrund-Thread.
#
# `ist_erreichbar()` hat eine harte Grenze (`timeout 3 ls`). Antwortet die
# Freigabe, sind ismount und schreibtest danach gefahrlos. Antwortet sie
# nicht, fällt es unten durch: lösen, frisch mounten. Das ist genau der Weg,
# den `reparieren()` geht — nur eben automatisch.
if ist_erreichbar(name):
try:
if os.path.ismount(ziel):
return schreibtest(ziel)
except OSError:
pass # unten erst lösen, dann frisch mounten (kein Stapeln)
# Idempotent: etwaige (auch gestapelte/tote) Alt-Mounts erst lösen, damit der
# folgende mount NICHT auf eine Leiche stapelt (Vorfall 24.07.: 12 Schichten).
_stale_mounts_loesen(ziel)
creds_datei = None
try:
@@ -149,6 +371,19 @@ def mounten(name: str, typ: str, quelle: str, optionen: str = "",
else:
raise RuntimeError(f"Unbekannter Typ: {typ} (nfs oder cifs)")
# Zwei Versuche. Grund (26.07.2026, dreimal reproduziert): Beim API-Start
# meldete `mount` Erfolg — und die Freigabe antwortete danach trotzdem
# nicht (`timeout 6 ls` lief in die Grenze, eine einzige, korrekt
# aussehende Mount-Schicht in /proc/mounts). Derselbe Ablauf ein zweites
# Mal, per POST /storage-mounts/<name>/repair, stellte sie sofort her.
# Der erste SMB-Sitzungsaufbau kurz nach dem Container-Start geht also
# gelegentlich schief, ohne es zu melden.
#
# Deshalb wird das Ergebnis GEPRÜFT statt geglaubt: Antwortet die
# Freigabe nach dem Mount nicht, wird einmal gelöst und neu gemountet.
# Und wenn das auch nicht hilft, fliegt ein Fehler — dann steht im Log
# „FEHLER" statt „eingehängt", was schlicht die Wahrheit ist.
for versuch in (1, 2):
ergebnis = subprocess.run(cmd, capture_output=True, text=True, timeout=30)
if ergebnis.returncode != 0:
fehler = (ergebnis.stderr or ergebnis.stdout or "").strip()
@@ -160,7 +395,19 @@ def mounten(name: str, typ: str, quelle: str, optionen: str = "",
"NAS meist ablehnen."
)
raise RuntimeError(f"mount schlug fehl: {fehler[:300]}{hinweis}")
# Zweimal mit Abstand prüfen — eine einzige Probe direkt nach dem
# Mount sieht den Wettlauf mit dem lazy umount nicht (siehe
# wirklich_erreichbar).
if wirklich_erreichbar(name):
return schreibtest(ziel)
if versuch == 1:
_lazy_umount(ziel)
raise RuntimeError(
f"{quelle} wurde eingehängt, antwortet aber nicht dauerhaft (zwei "
"Versuche). Läuft die Freigabe? Bei einem NAS im Ruhezustand hilft "
"meist ein erneutes Einhängen über Einstellungen → Speicherziele → "
"Reparieren."
)
finally:
if creds_datei:
try:
@@ -169,22 +416,52 @@ def mounten(name: str, typ: str, quelle: str, optionen: str = "",
pass
def _lazy_umount(ziel: str) -> None:
"""`umount -l`: hängt auch einen TOTEN/beschäftigten Mount ab (detach now,
cleanup later). Ohne das ließ sich ein Mount zu einem weggefallenen NAS
gar nicht mehr entfernen (Befund 24.07.)."""
subprocess.run(["umount", "-l", ziel], capture_output=True, text=True, timeout=30)
def aushaengen(name: str) -> None:
"""Freigabe abhängen und den Mountpunkt aufräumen.
Ohne `os.path.ismount`/`os.rmdir` als erste Schritte: Beide `stat`en den
Pfad, und auf einem toten CIFS-Mount blockiert das im Kernel (siehe
pfad_lage). Ein `umount` auf einen Pfad ohne Mount kostet dagegen nichts.
"""
ziel = _mountpoint(name)
if os.path.ismount(ziel):
ergebnis = subprocess.run(
["umount", ziel], capture_output=True, text=True, timeout=30
)
if ergebnis.returncode != 0:
raise RuntimeError(
f"umount schlug fehl: {(ergebnis.stderr or '').strip()[:300]}"
)
# Toter/beschäftigter Mount → lazy detach (klappt immer)
_lazy_umount(ziel)
# Erst wenn der Pfad wieder antwortet, darf rmdir ihn anfassen.
if pfad_lage(ziel) == "da":
try:
os.rmdir(ziel)
except OSError:
pass # nicht leer oder weg — egal
def reparieren(name: str, typ: str, quelle: str, optionen: str = "",
username: str = "", passwort: str = "") -> bool:
"""Toten/veralteten Mount frisch neu verbinden: lazy abhängen, neu mounten.
Nötig, wenn ein NAS-Mount stale geworden ist (Rebuild, NAS-Schlaf) das
normale mounten() würde am ist schon Mountpoint" hängenbleiben.
`os.path.ismount` stand hier vorher als Vorbedingung auf einem toten
CIFS-Mount blockiert dieses `stat` im Kernel (siehe pfad_lage). Gefragt wird
es gar nicht mehr: `umount -l` auf einen Pfad, an dem nichts hängt, kostet
nichts und meldet nur einen Rückgabewert, den hier niemand braucht.
"""
ziel = _mountpoint(name)
_lazy_umount(ziel)
return mounten(name, typ, quelle, optionen, username, passwort)
def alle_remounten() -> list:
"""Beim API-Start: alle gespeicherten Mounts wiederherstellen."""
meldungen = []
-169
View File
@@ -1,169 +0,0 @@
"""NFO-Generator für Jellyfin (Kodi/NFO-Schema)."""
from pathlib import Path
from typing import List
from xml.dom.minidom import getDOMImplementation
class NFOGenerator:
def __init__(self):
self.dom_impl = getDOMImplementation()
def _create_element(self, doc, name: str, text: str = None) -> None:
"""Hilfsfunktion für Element-Erstellung."""
element = doc.createElement(name)
if text:
element.appendChild(doc.createTextNode(str(text)))
return element
def generate_movie_nfo(self, title: str, year: int,
overview: str = "", rating: float = 0.0,
runtime: int = 0, genres: List[str] = None,
director: str = "", writer: str = "",
actors: List[str] = None, studio: str = "",
premiered: str = "", mpaa: str = "") -> str:
"""Generiere movie.nfo für Filme."""
doc = self.dom_impl.createDocument(None, "movie", None)
root = doc.documentElement
root.appendChild(self._create_element(doc, "title", title))
root.appendChild(self._create_element(doc, "year", year))
root.appendChild(self._create_element(doc, "plot", overview))
root.appendChild(self._create_element(doc, "rating", rating))
root.appendChild(self._create_element(doc, "runtime", runtime))
if genres:
for genre in genres:
root.appendChild(self._create_element(doc, "genre", genre))
if director:
root.appendChild(self._create_element(doc, "director", director))
if writer:
root.appendChild(self._create_element(doc, "writer", writer))
if actors:
for actor in actors:
actor_node = doc.createElement("actor")
actor_node.appendChild(self._create_element(doc, "name", actor))
root.appendChild(actor_node)
if studio:
root.appendChild(self._create_element(doc, "studio", studio))
if premiered:
root.appendChild(self._create_element(doc, "premiered", premiered))
if mpaa:
root.appendChild(self._create_element(doc, "mpaa", mpaa))
# Attribution
root.appendChild(self._create_element(doc, "details", "Source: TMDB"))
return doc.toprettyxml(indent=" ")
def generate_series_nfo(self, title: str, year: int,
overview: str = "", rating: float = 0.0,
genres: List[str] = None, studio: str = "",
premiered: str = "") -> str:
"""Generiere series.nfo für Serien."""
doc = self.dom_impl.createDocument(None, "tvshow", None)
root = doc.documentElement
root.appendChild(self._create_element(doc, "title", title))
root.appendChild(self._create_element(doc, "year", year))
root.appendChild(self._create_element(doc, "plot", overview))
root.appendChild(self._create_element(doc, "rating", rating))
if genres:
for genre in genres:
root.appendChild(self._create_element(doc, "genre", genre))
if studio:
root.appendChild(self._create_element(doc, "studio", studio))
if premiered:
root.appendChild(self._create_element(doc, "premiered", premiered))
# Attribution
root.appendChild(self._create_element(doc, "details", "Source: TMDB"))
return doc.toprettyxml(indent=" ")
def generate_episode_nfo(self, title: str, season: int, episode: int,
overview: str = "", rating: float = 0.0,
director: str = "", premiered: str = "",
writers: List[str] = None) -> str:
"""Generiere episode.nfo für Episoden."""
doc = self.dom_impl.createDocument(None, "episodedetails", None)
root = doc.documentElement
root.appendChild(self._create_element(doc, "title", title))
root.appendChild(self._create_element(doc, "season", season))
root.appendChild(self._create_element(doc, "episode", episode))
root.appendChild(self._create_element(doc, "plot", overview))
root.appendChild(self._create_element(doc, "rating", rating))
if director:
root.appendChild(self._create_element(doc, "director", director))
if premiered:
root.appendChild(self._create_element(doc, "premiered", premiered))
if writers:
for writer in writers:
root.appendChild(self._create_element(doc, "credits", writer))
return doc.toprettyxml(indent=" ")
def generate_album_nfo(self, title: str, artist: str, year: int,
genres: List[str] = None, rating: float = 0.0,
review: str = "") -> str:
"""Generiere album.nfo für Musikalben."""
doc = self.dom_impl.createDocument(None, "musicalbum", None)
root = doc.documentElement
root.appendChild(self._create_element(doc, "title", title))
root.appendChild(self._create_element(doc, "artist", artist))
root.appendChild(self._create_element(doc, "year", year))
root.appendChild(self._create_element(doc, "rating", rating))
root.appendChild(self._create_element(doc, "review", review))
if genres:
for genre in genres:
root.appendChild(self._create_element(doc, "genre", genre))
# Attribution
root.appendChild(self._create_element(doc, "details", "Source: MusicBrainz"))
return doc.toprettyxml(indent=" ")
def save_nfo(self, content: str, output_path: Path) -> bool:
"""Speichere NFO-Datei."""
try:
output_path.parent.mkdir(parents=True, exist_ok=True)
with open(output_path, 'w', encoding='utf-8') as f:
f.write(content)
return True
except Exception as e:
print(f"NFO save error: {e}")
return False
# Beispieldaten
if __name__ == "__main__":
nfo_gen = NFOGenerator()
# movie.nfo
movie_nfo = nfo_gen.generate_movie_nfo(
title="Inception",
year=2010,
overview="A thief who steals corporate secrets through the use of dream-sharing technology is given the inverse task of planting an idea into the mind of a C.E.O.",
rating=8.8,
runtime=148,
genres=["Action", "Sci-Fi", "Thriller"],
director="Christopher Nolan",
actors=["Leonardo DiCaprio", "Joseph Gordon-Levitt", "Ellen Page"]
)
print(movie_nfo)
+80
View File
@@ -0,0 +1,80 @@
"""In welcher Phase ist ein Job gestorben — und was hilft danach wirklich?
Commander-Befund 26.07.2026: Hier gibt es den Button neu' aber WAS wird dann
gemacht? Komprimierung? Neu Gerippt? Das muss ja je nach fehlgeschlagenem Job
eine Option anbieten."
Die Frage war berechtigt und der Knopf war falsch: Er hieß nur Neu" und rief
immer `POST /jobs/{id}/retry-transcode` also immer die KOMPRESSION. Für einen
abgebrochenen Transcode ist das goldrichtig (die Roh-MKV liegt vollständig da,
man spart eine Stunde Rippen). Für einen abgebrochenen RIP ist es Unsinn: Am
26.07.2026 lagen 5,1 GB von rund 40 GB da, und Neu" hätte daraus brav einen
Film komprimiert, der bei 12 % aufhört.
## Warum es dafür eine MARKE braucht
Sobald `status = "failed"` steht, ist der vorherige Zustand fort die Spalte
hat nur einen Wert. `zombies.war_im_rip()` im Worker kann die Phase noch sehen,
weil sie dort im Moment des Aufräumens vorliegt; die API sieht später nur noch
failed". Deshalb schreibt der Worker die Phase in die Job-Metadaten:
* Rip-Start `rip_fertig = false`
* Rip fertig (Übergabe an die Kompression) `rip_fertig = true`
* Start eines Transcodes `rip_fertig = true` (heilt Bestandsjobs mit)
## Drei Antworten, nicht zwei
Die Marke FEHLT bei jedem Job, der vor dieser Änderung lief. Diese Jobs
rip" zu nennen wäre geraten — und würde dem Commander an einem
Bestandsjob mit 79,6 GB intakter Rohdaten das Neu komprimieren" wegnehmen,
das dort genau richtig ist. Wer die Phase nicht kennt, sagt das: `unklar`
lässt das UI beide Wege anbieten, jeden mit einem ehrlichen Satz.
"""
import json
# Schlüssel in den Job-Metadaten. Muss identisch in worker/tasks.py stehen —
# es gibt kein geteiltes Paket zwischen den Containern.
RIP_FERTIG = "rip_fertig"
# Die drei möglichen Antworten.
NEU_KOMPRIMIEREN = "transcode"
NEU_RIPPEN = "rip"
UNKLAR = "unklar"
NICHTS = ""
def meta_von(meta_json) -> dict:
"""Metadaten lesen, ohne an kaputtem JSON zu scheitern.
Oeffentlich, seit auch `main.py` sie braucht: Dort muss die Wahl des
Rip-Dialogs (`work_dir`) aus denselben Metadaten gelesen werden.
"""
if isinstance(meta_json, dict):
return meta_json
if not meta_json:
return {}
try:
gelesen = json.loads(meta_json)
except (ValueError, TypeError):
return {}
return gelesen if isinstance(gelesen, dict) else {}
def retry_art(job) -> str:
"""Was soll der Knopf an DIESEM Job anbieten?
* `NICHTS` der Job ist nicht fehlgeschlagen, es gibt nichts zu
wiederholen.
* `NEU_KOMPRIMIEREN` der Rip war fertig, nur die Kompression starb.
* `NEU_RIPPEN` der Rip selbst starb; alles Rohe ist ein Bruchstück.
* `UNKLAR` kein Vermerk (Bestandsjob), beide Wege anbieten.
"""
if (job.get("status") or "") != "failed":
return NICHTS
marke = meta_von(job.get("meta")).get(RIP_FERTIG)
if marke is True:
return NEU_KOMPRIMIEREN
if marke is False:
return NEU_RIPPEN
return UNKLAR
+229 -48
View File
@@ -6,11 +6,11 @@ lieferte seitdem immer „Unknown Disc". Dies ist die echte Logik, bereinigt.
"""
import os
import shutil
import subprocess
from typing import Dict, List, Optional
import detection
from rippy import drives as _laufwerks_schicht
from rippy.platform.winlauf import OHNE_FENSTER
from clients.tmdb import TMDBClient
from clients.jikan import JikanClient
from clients.musicbrainz import MusicBrainzClient
@@ -19,6 +19,18 @@ from clients.thetvdb import TheTVDBClient
from cache import get, set as cache_set
from cache.keys import generate_prescan_key
# Der Treiber DIESER Maschine statt fest der Linux-Fassung — sonst waere
# dieses Modul (und ueber es main.py) unter Windows nicht ladbar. Beide
# Treiber bieten disc_size_bytes() und detect_disc_type() an; darauf achtet
# test_treiberwahl.py.
detection = _laufwerks_schicht.treiber()
# Wie viele Treffer eine Suche hoechstens liefern darf, damit sie als
# SPEZIFISCH gilt. Gemessen am 28.08.2026: Der volle Disc-Titel
# „Evangelion 2.22" ergab bei TMDB 1 Treffer (den richtigen), die gekuerzte
# Variante „Evangelion" ergab 20 (beliebige). Drei ist grosszuegig genug fuer
# Neuauflagen und Regie-Fassungen desselben Films.
WENIGE_TREFFER = 3
def normalize_disc_label(label: str) -> str:
"""Disc-Labels wie 'PULP_FICTION_DE''Pulp Fiction De' (pure Funktion).
@@ -75,50 +87,95 @@ def parse_udf_dstring(data: bytes) -> str:
return ""
def read_disc_title_via_mount(device_path: str) -> Optional[str]:
"""Liest den KLARTEXT-Titel einer Blu-ray aus BDMV/META/DL/bdmt_*.xml.
def disc_wurzel(device_path: str):
r"""Ein lesbarer Einstieg in die Disc — Windows braucht dafuer kein Mounten.
Das Volume-Label ist oft kryptisch (BD_EVG_D2) der echte Titel
(Evangelion: 2.22 ") steht in den Disc-Metadaten. Die API darf
read-only mounten (CAP_SYS_ADMIN ist für die Speicherziele ohnehin da).
Gibt None zurück, wenn kein BD-Metadatensatz existiert (z. B. DVD).
Gibt `(wurzel, aufraeumen)` zurueck. `aufraeumen` ist eine Funktion, die
nach dem Lesen aufgerufen wird; unter Windows tut sie nichts.
## Warum das getrennt ist (28.08.2026)
Der Weg hier war fest `mount -t udf` also Linux. Unter Windows haengt
Windows die Disc selbst ein: `\.\G:` entspricht `G:\`, und dort liegen
die Dateien einfach da. Ohne diese Unterscheidung fand Rippy unter
Windows NIE den Klartext-Titel und blieb beim Volume-Label haengen
(gemessen an einer echten Disc: `BD_EVG_D2` statt `Evangelion 2.22`) --
und mit so einem Label findet keine Metadaten-API etwas.
"""
import re as _re
if os.name == "nt":
# \.\G: -> G:\ (der Buchstabe ist alles, was wir brauchen)
buchstabe = device_path.rstrip(":").rsplit("\\", 1)[-1].rstrip(":")
wurzel = buchstabe + ":" + "\\"
return (wurzel, lambda: None) if os.path.isdir(wurzel) else (None, lambda: None)
mountpoint = "/mnt/rippy-disc"
os.makedirs(mountpoint, exist_ok=True)
gemountet = False
try:
ergebnis = subprocess.run(
["mount", "-t", "udf", "-o", "ro", device_path, mountpoint],
capture_output=True, text=True, timeout=30,
creationflags=OHNE_FENSTER,
)
if ergebnis.returncode != 0:
return None
gemountet = True
return None, lambda: None
meta_dir = os.path.join(mountpoint, "BDMV", "META", "DL")
def abhaengen():
subprocess.run(["umount", mountpoint], capture_output=True, timeout=15,
creationflags=OHNE_FENSTER)
return mountpoint, abhaengen
def titel_aus_bdmt(wurzel: str) -> Optional[str]:
"""Der Klartext-Titel aus BDMV/META/DL/bdmt_*.xml. (ohne Mounten)
Getrennt von der Beschaffung der Wurzel, damit er ohne Disc pruefbar ist:
ein Ordner mit einer bdmt-Datei reicht.
"""
import re as _re
meta_dir = os.path.join(wurzel, "BDMV", "META", "DL")
if not os.path.isdir(meta_dir):
return None
try:
kandidaten = sorted(os.listdir(meta_dir))
# bdmt_eng.xml bevorzugen, sonst erste bdmt-Datei (bdmt_ger.xml, …)
except OSError:
return None
# bdmt_eng.xml bevorzugen, sonst die erste bdmt-Datei (bdmt_deu.xml, ...)
bdmt = next((k for k in kandidaten if k == "bdmt_eng.xml"), None) or next(
(k for k in kandidaten if k.startswith("bdmt_") and k.endswith(".xml")), None
)
if not bdmt:
return None
try:
with open(os.path.join(meta_dir, bdmt), "rb") as f:
inhalt = f.read(65536).decode("utf-8", errors="replace")
# <di:name>Titel</di:name> — bewusst per Regex statt XML-Parser
except OSError:
return None
# <di:name>Titel</di:name> - bewusst per Regex statt XML-Parser
# (Namespaces variieren je Authoring-Werkzeug)
treffer = _re.search(r"<di:name>([^<]{2,120})</di:name>", inhalt)
if treffer:
return treffer.group(1).strip()
return None
return treffer.group(1).strip() if treffer else None
def read_disc_title_via_mount(device_path: str) -> Optional[str]:
"""Liest den KLARTEXT-Titel einer Blu-ray aus BDMV/META/DL/bdmt_*.xml.
Das Volume-Label ist oft kryptisch (`BD_EVG_D2`) - der echte Titel
(Evangelion 2.22") steht in den Disc-Metadaten. Unter Linux wird dafuer
read-only gemountet, unter Windows haengt Windows die Disc selbst ein.
Gibt None zurueck, wenn kein BD-Metadatensatz existiert (z. B. DVD).
"""
wurzel, aufraeumen = None, lambda: None
try:
wurzel, aufraeumen = disc_wurzel(device_path)
return titel_aus_bdmt(wurzel) if wurzel else None
except Exception:
return None
finally:
if gemountet:
subprocess.run(["umount", mountpoint], capture_output=True, timeout=15)
try:
aufraeumen()
except Exception:
pass
def titel_kandidaten(titel: str) -> List[str]:
@@ -203,7 +260,8 @@ class PreScanResult:
year: int = None,
confidence: float = 0.0,
metadata: Dict = None,
tracks: List[Dict] = None
tracks: List[Dict] = None,
fingerprint: str = ""
):
self.disc_type = disc_type
self.title = title
@@ -211,6 +269,9 @@ class PreScanResult:
self.confidence = confidence
self.metadata = metadata or {}
self.tracks = tracks or []
# Fingerabdruck (Label|Größe) wandert mit ins Ergebnis — Basis der
# Duplikat-Warnung („diese Disc wurde schon gerippt")
self.fingerprint = fingerprint
def to_dict(self) -> Dict:
return {
@@ -219,7 +280,8 @@ class PreScanResult:
"year": self.year,
"confidence": self.confidence,
"metadata": self.metadata,
"tracks": self.tracks
"tracks": self.tracks,
"fingerprint": self.fingerprint
}
@@ -253,7 +315,7 @@ class PreScan:
installiert, die Erkennung fiel still immer auf "DVD" zurück.
"""
typ = detection.detect_disc_type(device_path)
return {"cd": "CD", "dvd": "DVD", "bluray": "Blu-ray"}.get(typ, "DVD")
return {"cd": "CD", "dvd": "DVD", "bluray": "Blu-ray", "uhd": "4K UHD"}.get(typ, "DVD")
def _read_toc(self, device_path: str, disc_type: str) -> Dict:
"""Lese TOC (Table of Contents)."""
@@ -269,7 +331,8 @@ class PreScan:
["cdparanoia", "-Q", device_path],
capture_output=True,
text=True,
timeout=10
timeout=10,
creationflags=OHNE_FENSTER,
)
for line in result.stdout.split('\n'):
if 'track' in line.lower():
@@ -293,22 +356,37 @@ class PreScan:
if label:
toc["title"] = normalize_disc_label(label)
# Titel-Quelle 2 (optional, falls makemkvcon doch da ist):
if shutil.which("makemkvcon"):
result = subprocess.run(
["makemkvcon", "-r", "--noscan", "--minlength=300", "info", f"dev:{device_path}"],
capture_output=True,
text=True,
timeout=120
)
for line in result.stdout.split('\n'):
if line.startswith('TINFO:'):
parts = line.split(',')
if len(parts) >= 5:
toc["tracks"].append({
"title": parts[4].strip().strip('"') if len(parts) > 4 else "Title",
"duration": int(parts[2]) if len(parts) > 2 else 0
})
# Titel-Quelle 3 (makemkvcon) gibt es hier NICHT mehr.
#
# ## Warum sie weg ist (Befund 30.08.2026)
#
# Der Commander: „das erkennen der disk dauert sehr sehr
# lange. Das ging mal viel schneller."
#
# Hier stand ein `makemkvcon -r --noscan --minlength=300
# info` mit 120 s Zeitgrenze — bei jeder eingelegten Disc,
# vor jeder Anzeige. Auf einer Blu-ray dauert dieser Aufruf
# 20 bis 120 Sekunden; solange steht „Disc wird gelesen".
#
# Dass es frueher schnell war, hat einen unschoenen Grund:
# Der Zweig lief unter Windows NIE. Er suchte makemkvcon mit
# `shutil.which`, und das findet unter Windows nichts
# (Programme liegen nicht im PATH). `be3fac5` hat das am
# 28.08.2026 richtig repariert — und damit erst die Kosten
# sichtbar gemacht, die hier immer schon standen.
#
# Der Aufwand war umsonst: Das Ergebnis landete allein in
# `toc["tracks"]`, und **die liest niemand**. Der Rip-Dialog
# holt seine Titelliste ueber `POST /devices/{id}/scan-tracks`
# und `GET /devices/{id}/tracks` — also dann, wenn sie
# gebraucht wird, statt bei jedem Einlegen auf Verdacht.
# Der Weg fuer eine Disc, die man gar nicht rippen will,
# sind so zwei Minuten Warten fuer nichts.
#
# Der Titel kommt aus Quelle 1 und 2 darueber; die sind
# billig. Wer den Aufruf je wieder braucht, braucht dazu
# `makemkv_aufruf.quelle`, `makemkv_aufruf.text_von` und
# `tools.katalog` — die Importe sind mit ihm gegangen.
except Exception as e:
print(f"Pre-Scan TOC Error: {e}")
return toc
@@ -361,7 +439,8 @@ class PreScan:
disc_type="CD",
title=album,
tracks=toc["tracks"],
confidence=confidence
confidence=confidence,
fingerprint=toc.get("fingerprint", "")
)
cache_set(cache_key, result.to_dict())
return result
@@ -384,11 +463,13 @@ class PreScan:
# probieren — Disc-Titel sind selten API-freundlich formatiert.
kandidaten = titel_kandidaten(title) or [title]
movies = []
movies_kandidat = "" # WELCHE Variante hat sie geliefert?
for kandidat in kandidaten:
treffer = self.tmdb.search_movie(kandidat)
if treffer and not movies:
movies = treffer # bester Rohtreffer für den Vorschlags-Fallback
movies_kandidat = kandidat
for movie in treffer:
if movie.get("title", "").lower() == kandidat.lower():
confidence = 0.95
@@ -403,7 +484,8 @@ class PreScan:
"poster_path": movie_details.get("poster_path", ""),
"backdrop_path": movie_details.get("backdrop_path", ""),
"runtime": movie_details.get("runtime", 0),
"genres": [g["name"] for g in movie_details.get("genres", [])]
"genres": [g["name"] for g in movie_details.get("genres", [])],
"source": "tmdb",
}
matched = True
break
@@ -426,22 +508,100 @@ class PreScan:
"overview": tv_details.get("overview", ""),
"poster_path": tv_details.get("poster_path", ""),
"backdrop_path": tv_details.get("backdrop_path", ""),
"genres": [g["name"] for g in tv_details.get("genres", [])]
"genres": [g["name"] for g in tv_details.get("genres", [])],
"source": "tmdb",
}
matched = True
break
if matched:
break
# ── Ein spezifischer Treffer zählt, auch ohne exakten Titel ─────────
#
# ## Der Befund des Commanders (28.08.2026)
#
# > „Was ist mit dem Cover auf Windows Rippy? In der Web Version haben
# > wir ein cover."
#
# Es gab keins, weil es gar keinen Treffer gab — und der Grund war
# nicht Windows, sondern die Bedingung oben: `movie["title"].lower()
# == kandidat.lower()`. An seiner Disc gemessen:
#
# 'Evangelion 2.22' 1 Treffer Evangelion: 2.0 You Can (Not) Advance
# 'Evangelion' 20 Treffer irgendein Evangelion
#
# Der EINZIGE Treffer auf den vollen Disc-Titel war der richtige Film,
# mit Poster — und wurde verworfen, weil der Titel nicht wörtlich
# gleich war. Danach gewann eine schlechtere Quelle oder gar keine.
#
# ## Warum die Trefferzahl das bessere Kriterium ist als Ähnlichkeit
#
# Die Ähnlichkeit hilft hier nicht: „Evangelion 2.22" gegen
# „Evangelion: 2.0 You Can (Not) Advance" ergibt 0,51 — das steht als
# Messung schon im Jikan-Absatz unten und fällt durch jedes sinnvolle
# Gatter. Die SPEZIFITÄT der Anfrage sagt mehr: Wer auf den vollen,
# ungekürzten Disc-Titel eine Handvoll Treffer bekommt, hat gefragt
# wie jemand, der weiß, was er sucht. Wer 20 bekommt, hat geraten.
#
# Deshalb: nur der UNGEKÜRZTE Titel (kandidaten[0]) und nur wenige
# Treffer. Confidence 0,8 — sicherer als ein Vorschlag (0,6), aber
# ehrlich unter einem wörtlichen Treffer (0,95).
if not matched and movies and movies_kandidat == kandidaten[0] \
and len(movies) <= WENIGE_TREFFER:
details = self.tmdb.get_movie_details(movies[0]["id"])
if details:
confidence = 0.8
metadata = {
"type": "movie",
"id": movies[0]["id"],
"title": details.get("title", title),
"year": int(details.get("release_date", "0")[:4]) if details.get("release_date") else None,
"overview": details.get("overview", ""),
"poster_path": details.get("poster_path", ""),
"backdrop_path": details.get("backdrop_path", ""),
"runtime": details.get("runtime", 0),
"genres": [g["name"] for g in details.get("genres", [])],
"source": "tmdb",
}
matched = True
# Fallback 1: Jikan/MyAnimeList (kostenlos, KEIN Key) — für Anime die
# präziseste Quelle; wählt per Titel-Ähnlichkeit, nicht Treffer #1
# präziseste Quelle; wählt per Titel-Ähnlichkeit, nicht Treffer #1.
#
# NEU 26.07.2026 — „exakt schlägt unscharf", unabhängig von der
# Reihenfolge. Vorher galt der erste Jikan-Treffer über dem Gate 0,55
# sofort als sicherer Fund (confidence 0,85) und OMDb kam nie dran.
# Das ist zu großzügig, und zwar messbar (offline gerechnet mit
# titel_aehnlichkeit, echte MyAnimeList-Titel):
#
# „Alien" vs. „Alien 9" → 0,83 TRIFFT
# „Inception" vs. „Deception" → 0,78 TRIFFT
# „Hero" vs. „Heroman" → 0,73 TRIFFT
# „The Dark Knight" vs. „Dark Knight Rises" → 0,69 TRIFFT
#
# Ein Kinofilm, den TMDB verpasst, bekam damit Anime-Metadaten — und
# OMDb, das ihn kennt, wurde nie gefragt. Bemerkenswert dabei, und das
# widerlegt die Vermutung im SAVEPOINT v3.16, das Gate sei einfach zu
# niedrig: Für den Fall, für den Jikan überhaupt eingebaut wurde, ist
# es sogar zu HOCH — „Evangelion 2.22" vs. „Evangelion: 2.0 You Can
# (Not) Advance" ergibt 0,51 und fällt durch. Eine einzelne Zahl kann
# beides nicht leisten.
#
# Deshalb: Nur ein praktisch exakter Titel gilt sofort. Ein unscharfer
# Treffer wird GEMERKT, dann OMDb gefragt — und erst wenn OMDb nichts
# hat, kommt er als VORSCHLAG (niedrige Confidence) zum Zug.
jikan_unscharf = None
if not matched:
for kandidat in kandidaten:
jikan_treffer = self.jikan.lookup(kandidat)
if jikan_treffer:
if not jikan_treffer:
continue
if jikan_treffer.get("match_score", 0) >= JikanClient.SICHER_AEHNLICHKEIT:
confidence = 0.85
metadata = jikan_treffer
matched = True
else:
jikan_unscharf = jikan_treffer
break
# Fallback 2: OMDb (eigene Datenbasis — findet oft, was TMDB nicht
@@ -456,6 +616,15 @@ class PreScan:
matched = True
break
# Fallback 2b: der unscharfe Jikan-Treffer — besser als nichts, aber
# ehrlich als Vorschlag ausgewiesen (0,6 = dieselbe Stufe wie ein
# TMDB-Vorschlag ohne exakten Treffer; das UI zeigt die Prozentzahl an
# und der Nutzer kann korrigieren).
if not matched and jikan_unscharf:
confidence = 0.6
metadata = jikan_unscharf
matched = True
# Fallback 2: bester TMDB-Vorschlag ohne exakten Treffer — als
# VORSCHLAG gekennzeichnet (niedrige Confidence, Nutzer korrigiert)
if not matched and movies:
@@ -471,7 +640,8 @@ class PreScan:
"poster_path": vorschlag.get("poster_path", ""),
"backdrop_path": vorschlag.get("backdrop_path", ""),
"runtime": vorschlag.get("runtime", 0),
"genres": [g["name"] for g in vorschlag.get("genres", [])]
"genres": [g["name"] for g in vorschlag.get("genres", [])],
"source": "tmdb",
}
matched = True
@@ -483,6 +653,16 @@ class PreScan:
"year": None
}
# Deutsche Texte für OMDb-Treffer nachladen (Commander-Wunsch 24.07.):
# OMDb kann nur Englisch — über die IMDb-ID liefert TMDB /find den
# deutschen Titel, die Beschreibung und oft ein besseres Poster.
if matched and metadata.get("source") == "omdb" and str(metadata.get("id", "")).startswith("tt"):
deutsch = self.tmdb.find_by_imdb(metadata["id"])
if deutsch:
for feld in ("title", "overview", "poster_path", "year", "type"):
if deutsch.get(feld):
metadata[feld] = deutsch[feld]
# Bei Treffer den sauberen API-Titel anzeigen statt des Disc-Titels
if matched and metadata.get("title"):
title = metadata["title"]
@@ -493,7 +673,8 @@ class PreScan:
year=metadata.get("year"),
confidence=confidence,
metadata=metadata,
tracks=toc.get("tracks", [])
tracks=toc.get("tracks", []),
fingerprint=toc.get("fingerprint", "")
)
# Nur ECHTE Treffer cachen: ein gecachtes "unknown" würde sonst auch
# nach Key-Eintrag/Fix ewig wieder serviert (Redis ist persistent).
+245
View File
@@ -0,0 +1,245 @@
"""Welches HandBrake-Preset passt zu welcher Disc — und was ist das BESTE.
Commander-Anforderung (26.07.2026): *Bei den Presets soll IMMER das Beste
ausgewählt werden"* und *„wenn der Worker AV1 oder noch besseres kann, immer
diesem empfehlen"*.
## Warum das hier liegt und nicht im UI
Die Preset-Namen standen bis dahin fest verdrahtet im UI (drei Listen in
Settings.tsx, eine vierte im Wizard). Zwei Probleme: die Namen unterscheiden
sich zwischen HandBrake-Versionen, und ein erfundener Name lässt die Kompression
scheitern das Projekt hat genau das zweimal teuer bezahlt (AGENTS Regel D).
Jetzt meldet jeder Worker seine echte Liste (`worker/caps.py`,
`HandBrakeCLI --preset-list`), und die Auswahl entsteht hier: als reine
Funktionen, die die CI-Ampel prüft. Das UI zeigt nur noch an.
## Es wird nicht bewertet, sondern gestaffelt
Kein Punktesystem. Für jede Lage gibt es eine feste Reihenfolge von Namen, und
genommen wird der erste, den der Worker WIRKLICH kennt. Jeder Name unten ist am
26.07.2026 aus `--preset-list` des Worker-Images abgenommen (HandBrake 1.6.1).
Ein Punktesystem hätte über Namen geurteilt, die es vielleicht nicht gibt.
## Zwei Quellen, zwei Fragen
- `--preset-list` sagt, welche Presets es GIBT. Die Kategorie `Hardware/` steht
dort auch auf Maschinen ohne Hardware-Encoder.
- `--help` sagt, welche Encoder LAUFEN.
Deshalb wird ein Hardware-Preset nur empfohlen, wenn ein Worker die passende
Familie wirklich meldet. (Richtigstellung zum SAVEPOINT v3.16: dort galt es als
unmöglich, die Hardware-Preset-Namen auf der VM zu ermitteln die Messung sagt
das Gegenteil, siehe caps.parse_preset_liste.)
"""
# Reservewert: „diesen Disc-Typ NICHT komprimieren". Gleichlautend in
# worker/ripping.PRESET_KEINE und ui/src/lib/encoder.ts — es gibt kein
# geteiltes Paket zwischen den drei Seiten.
PRESET_KEINE = "keine"
# Auflösungs-Token je Disc-Typ, so wie HandBrake sie in die Preset-Namen
# schreibt. Damit bietet die 4K-Auswahl keine 1080p-Presets als Normalfall an —
# genau dieser Griff hat in v3.12 eine 4K-UHD auf 1080p heruntergerechnet.
AUFLOESUNG_JE_TYP = {
"uhd": ("2160p",),
"bluray": ("1080p",),
"dvd": ("576p", "480p"),
}
# Hardware-Familie im ENCODER-Namen (aus `--help`) → Kürzel im PRESET-Namen.
# Gemessen: die Presets heißen „H.265 VCN 2160p 4K", der Encoder dazu aber
# `vce_h265`. Ohne diese Zuordnung bekäme eine AMD-Karte kein AMD-Preset.
# Reihenfolge = Vorzug, wenn eine Maschine mehrere Familien meldet.
HW_PRESET_KUERZEL = (
("qsv", "QSV"), # Intel QuickSync — in 1.6.1 die einzige mit AV1-Preset
("nvenc", "NVENC"), # NVIDIA
("vce", "VCN"), # AMD (Encoder heißt vce, Preset heißt VCN)
)
# Absichtlich NICHT dabei:
# - `vaapi`: HandBrake 1.6.1 liefert kein VAAPI-Preset mit (Kategorie
# `Hardware/` kennt nur QSV/NVENC/VCN/MF). Ein VAAPI-Worker fällt daher auf
# Software zurück, statt einen Namen zu bekommen, den es nicht gibt.
# - `MF` (Media Foundation): die Presets existieren, aber ob diese Maschine sie
# nutzen kann, ist aus der Encoder-Liste nicht ablesbar. Empfohlen wird MF
# deshalb nie; in der Auswahlliste steht es trotzdem.
# Vektorbefehls-Stufen, mit denen Software-Encoding brauchbar schnell ist.
# Gleichlautend in ui/src/lib/encoder.ts (SIMD_SCHNELL).
SIMD_SCHNELL = ("avx512f", "avx2")
# Rückfall, wenn KEIN Worker eine Preset-Liste meldet (alter Worker-Stand, oder
# gar kein Worker online). Alle vier Namen sind im Worker-Image gegengeprüft.
RUECKFALL_PRESETS = (
"H.265 MKV 2160p60 4K",
"H.265 MKV 1080p30",
"H.265 MKV 576p25",
"H.265 MKV 480p30",
"HQ 2160p60 4K HEVC Surround",
"HQ 1080p30 Surround",
"HQ 576p25 Surround",
"Super HQ 2160p60 4K HEVC Surround",
"Super HQ 1080p30 Surround",
)
def verfuegbare_presets(workers) -> list:
"""Alle Preset-Namen, die die gemeldeten Worker kennen (Vereinigung).
Vereinigung und nicht Schnittmenge: Die Kompression kann gezielt an EINEN
Worker geroutet werden (worker_direct), es muss also nicht jeder alles
können. Ob der gewählte Worker das Preset kennt, entscheidet er selbst
und meldet es als Klartext-Fehler.
"""
gefunden = []
for w in workers or []:
for name in ((w.get("info") or {}).get("presets") or []):
if name and name not in gefunden:
gefunden.append(name)
return gefunden or list(RUECKFALL_PRESETS)
def hardware_kuerzel(workers) -> list:
"""Preset-Kürzel der Hardware-Encoder, die WIRKLICH gemeldet sind."""
vorhanden = set()
for w in workers or []:
for encoder in (w.get("encoders") or []):
vorhanden.add(str(encoder).lower())
kuerzel = []
for familie, kurz in HW_PRESET_KUERZEL:
if any(e == familie or e.startswith(familie + "-") for e in vorhanden):
kuerzel.append(kurz)
return kuerzel
def simd_schnell(workers) -> bool:
"""Kann mindestens ein Worker Software-Encoding brauchbar schnell?
Bei unbekannter Stufe wird NICHT geraten (ein Windows-Worker ohne die
Erkennung aus v3.16 meldet `unbekannt`) dann zählt er hier nicht mit,
bremst aber auch niemanden aus.
"""
for w in workers or []:
if ((w.get("info") or {}).get("cpu_simd") or "") in SIMD_SCHNELL:
return True
return False
def _kandidaten(disc_type: str, kuerzel: list, schnell: bool) -> list:
"""Namens-Staffel für diese Lage — bester Kandidat zuerst.
Die Software-Zweige sind bewusst dieselben, die der Wizard seit v3.15
vorschlägt (dort schon geprüft): schwache CPU 4K verlustfrei behalten und
H.264 für den Rest, starke CPU H.265 durchgehend. Neu ist nur, dass
Hardware-Presets davor kommen.
"""
liste = []
# 1. Hardware zuerst — sie ist um Größenordnungen schneller. Auf der
# Rippy-VM brauchte Software-4K gemessene 28-55 Stunden pro Film.
for kurz in kuerzel:
if disc_type == "uhd":
liste += [f"AV1 {kurz} 2160p 4K", f"H.265 {kurz} 2160p 4K"]
elif disc_type == "bluray":
liste += [f"H.265 {kurz} 1080p"]
# Für DVD-Auflösungen liefert HandBrake 1.6.1 keine Hardware-Presets —
# eine DVD ist auch in Software in Minuten fertig.
# 2. Software.
if disc_type == "uhd":
liste += ["H.265 MKV 2160p60 4K"] if schnell else [PRESET_KEINE]
elif disc_type == "bluray":
liste += ["H.265 MKV 1080p30"] if schnell else ["HQ 1080p30 Surround"]
elif disc_type == "dvd":
liste += ["H.265 MKV 576p25"] if schnell else ["HQ 576p25 Surround"]
return liste
def _grund(preset: str, disc_type: str, kuerzel: list, schnell: bool) -> str:
"""Ein Satz, WARUM das die Empfehlung ist — der Commander liest das."""
if preset == PRESET_KEINE:
return (
"Keiner der gemeldeten Worker hat AVX2 oder einen Hardware-Encoder. "
"4K in Software dauert auf so einer Maschine gemessene 28-55 Stunden "
"pro Film — die verlustfreie Datei zu behalten ist hier die ehrliche "
"Wahl (kostet 20-100 GB)."
)
if any(f" {k} " in f" {preset} " for k in kuerzel):
return (
f"Nutzt den gemeldeten Hardware-Encoder ({', '.join(kuerzel)}) — "
"um Größenordnungen schneller als die CPU. Software-x265 wäre bei "
"gleicher Dateigröße etwas sauberer, dauert aber Stunden bis Tage."
)
if schnell:
return (
"H.265 in Software: kleinste Dateien bei sehr guter Qualität. Ein "
"Worker mit AVX2 ist dafür schnell genug (gemessen)."
)
return (
"H.264 statt H.265: ohne AVX2 ist H.265 sehr langsam. Die Datei wird "
"etwas größer, der Encode dafür um ein Mehrfaches schneller."
)
def empfehlung(disc_type: str, workers) -> dict:
"""Bestes Preset für diesen Disc-Typ — nur Namen, die es wirklich gibt.
Rückgabe: {"preset": str, "grund": str, "gefunden": bool}. `gefunden` ist
False, wenn keiner der bekannten Namen in der Liste des Workers steht (z. B.
eine HandBrake-Version mit anderer Benennung) dann muss der Nutzer selbst
wählen, und das UI sagt es ihm, statt still etwas Falsches einzustellen.
"""
vorhanden = verfuegbare_presets(workers)
kuerzel = hardware_kuerzel(workers)
schnell = simd_schnell(workers)
for kandidat in _kandidaten(disc_type, kuerzel, schnell):
if kandidat == PRESET_KEINE or kandidat in vorhanden:
return {
"preset": kandidat,
"grund": _grund(kandidat, disc_type, kuerzel, schnell),
"gefunden": True,
}
return {
"preset": "",
"grund": (
"Dieses HandBrake kennt keines der Presets, die Rippy vorschlagen "
"kann — die Namen unterscheiden sich zwischen HandBrake-Versionen. "
"Bitte unten selbst eines aus der Liste des Workers wählen."
),
"gefunden": False,
}
def auswahl(disc_type: str, workers) -> list:
"""Die Presets, die für diesen Disc-Typ zur Wahl stehen — sortiert.
Gefiltert auf die passende Auflösung: Bei 4K sollen keine 1080p-Presets als
Normalfall in der Liste stehen, sonst passiert wieder, was in v3.12 passiert
ist (4K-Rip auf 1080p heruntergerechnet, weil ein globales Preset galt).
Das bewusste Verkleinern bleibt möglich es steht am Ende, mit Hinweis.
"""
vorhanden = verfuegbare_presets(workers)
tokens = AUFLOESUNG_JE_TYP.get(disc_type, ())
passend = [p for p in vorhanden if any(t in p for t in tokens)]
liste = [{"name": p, "verkleinert": False} for p in sorted(passend)]
if disc_type == "uhd":
# Bewusstes Verkleinern auf 1080p — eigene Gruppe, damit niemand aus
# Versehen dort landet.
kleiner = [p for p in vorhanden if "1080p" in p]
liste += [{"name": p, "verkleinert": True} for p in sorted(kleiner)]
return liste
def uebersicht(workers) -> dict:
"""Alles, was das UI für die Preset-Auswahl braucht — in einem Aufruf."""
typen = ("uhd", "bluray", "dvd")
return {
"quelle": "worker" if verfuegbare_presets(workers) != list(RUECKFALL_PRESETS)
else "rueckfall",
"hardware": hardware_kuerzel(workers),
"simd_schnell": simd_schnell(workers),
"typen": {
t: {"empfehlung": empfehlung(t, workers), "auswahl": auswahl(t, workers)}
for t in typen
},
}
+93 -43
View File
@@ -1,17 +1,105 @@
"""Rate-Limiting-Modul für Rippy API."""
"""Rate-Limiting-Modul für Rippy API (pro Client-IP).
Der API-Key-Store, der hier früher lebte, ist mit dem Auth-Rückbau
(Commander-Entscheid 24.07.2026) entfernt Heimnetz-only, siehe KONZEPT §10.
## Was diese Bremse ist — und was nicht
Sie soll ein Amok-Skript stoppen (Endlosschleife, tausend Anfragen pro Sekunde).
Sie ist KEIN Schutz gegen Angreifer; dafür wäre Rippy die falsche Stelle.
Daraus folgt die Zahl unten: Sie muss deutlich über dem liegen, was Rippy im
Normalbetrieb selbst verursacht. Am 26.07.2026 tat sie das nicht und die
Folgen waren dem Commander als wird oft neu geladen" aufgefallen.
"""
import ipaddress
import time
import secrets
from collections import defaultdict
from typing import Dict, Optional
from typing import Dict
# Default Rate Limit
MAX_REQUESTS_PER_MINUTE = 100
# Wie viele Anfragen pro Minute und Client durchgehen.
#
# ⚠️ Bis zum 26.07.2026 stand hier 100 — WENIGER, als das eigene Dashboard
# braucht. Nachgerechnet an den tatsächlichen Taktgebern im UI:
#
# Dashboard (Dashboard.tsx) 5 Endpunkte alle 4 s → 75/min
# Log-Kasten (LiveLogSection.tsx) 2 Endpunkte alle 5 s → 24/min
# Laufwerke (DeviceDiscovery.tsx) 1 Endpunkt alle 5 s → 12/min
# Windows-Tray (tray.py) /jobs alle 5 s → 12/min je Worker
# ─────────
# EIN offener Tab plus ein Worker 123/min
#
# Das Limit war also im Normalbetrieb um ein Viertel überschritten: Etwa jede
# vierte Anfrage bekam 429, und weil das UI einen Fehlschlag damals als „es gibt
# keine Jobs" verbuchte, leerte sich die Liste im Sekundentakt. Zwei offene Tabs
# hätten es verdoppelt.
#
# 600/min = 10 Anfragen pro Sekunde: Platz für mehrere Tabs und Worker, während
# eine Endlosschleife (Hunderte pro Sekunde) weiterhin sofort gebremst wird.
MAX_REQUESTS_PER_MINUTE = 600
# In-Memory Rate Limit Store (in Produktion mit Redis)
rate_limit_store: Dict[str, list] = defaultdict(list)
def _ist_privat(adresse: str) -> bool:
"""Steckt hinter dieser Adresse das eigene Netz (bzw. ein Container)?"""
try:
ip = ipaddress.ip_address(adresse)
except ValueError:
return False
return ip.is_private or ip.is_loopback
def client_kennung(peer: str, weitergegeben: str = None) -> str:
"""Welcher Eimer gilt für diese Anfrage? (pure Funktion, testbar)
`peer` ist der direkte Absender, `weitergegeben` der Inhalt von
`X-Real-IP` (setzt der nginx im UI-Container, siehe ui/nginx.conf).
Warum überhaupt: Der Browser spricht nie direkt mit der API, sondern über
den nginx für die API sah deshalb JEDE Anfahrt aus dem UI gleich aus. Ein
zweiter Tab und der Windows-Tray teilten sich den Eimer mit dem Dashboard,
obwohl es drei unabhängige Clients sind.
Der Kopfzeile wird nur geglaubt, wenn der direkte Absender aus dem privaten
Netz kommt also unser eigener Proxy. Das ist keine Härtung gegen
Angreifer (Rippy ist Heimnetz-only, KONZEPT §10), sondern verhindert, dass
eine beliebige Kopfzeile die Bremse aushebelt.
"""
peer = (peer or "").strip()
kandidat = (weitergegeben or "").split(",")[0].strip()
if kandidat and _ist_privat(peer) and _ist_privat(kandidat):
return kandidat
return peer or "unbekannt"
# Wann wurde für einen Client zuletzt eine Rate-Limit-Meldung geschrieben?
_letzte_meldung: Dict[str, float] = {}
# Abstand zwischen zwei Meldungen pro Client.
MELDE_ABSTAND_SEKUNDEN = 60
def darf_melden(client_id: str, jetzt: float = None) -> bool:
"""Soll dieser abgewiesene Aufruf ins Log? Höchstens einmal pro Minute.
Ein 429 war bisher völlig unsichtbar das UI verbuchte ihn als nichts
da", und niemand erfuhr, dass die Bremse greift. Jede Abweisung zu
protokollieren wäre aber die Ecke ins Gegenteil: Genau der Fall, für den die
Bremse gebaut ist (ein Skript in einer Endlosschleife), würde damit das
Log-Fenster zumüllen. Also: eine Meldung pro Client und Minute.
"""
if jetzt is None:
jetzt = time.time()
vorher = _letzte_meldung.get(client_id, 0.0)
if jetzt - vorher < MELDE_ABSTAND_SEKUNDEN:
return False
_letzte_meldung[client_id] = jetzt
return True
def check_rate_limit(client_id: str, max_requests: int = MAX_REQUESTS_PER_MINUTE, window_seconds: int = 60) -> bool:
"""Prüfe ob Client rate-limited ist."""
current_time = time.time()
@@ -48,41 +136,3 @@ def get_rate_limit_remaining(client_id: str, max_requests: int = MAX_REQUESTS_PE
def reset_rate_limit(client_id: str) -> None:
"""Setze Rate Limit für Client zurück."""
rate_limit_store[client_id] = []
# API-Key Store (in Produktion mit Datenbank)
api_keys: Dict[str, Dict] = {
"example_key": {
"key": "example_key",
"name": "Beispiel API Key",
"created_at": time.time(),
"rate_limit": 100
}
}
def validate_api_key(api_key: str) -> Optional[Dict]:
"""Validiere API Key."""
if api_key in api_keys:
return api_keys[api_key]
return None
def create_api_key(name: str) -> Dict:
"""Erstelle neuer API Key."""
key = secrets.token_urlsafe(32)
api_keys[key] = {
"key": key,
"name": name,
"created_at": time.time(),
"rate_limit": MAX_REQUESTS_PER_MINUTE
}
return api_keys[key]
def delete_api_key(key: str) -> bool:
"""Lösche API Key."""
if key in api_keys:
del api_keys[key]
return True
return False
+3 -8
View File
@@ -7,12 +7,7 @@ redis==5.0.4
requests==2.32.3
pydantic==2.9.0
pydantic-settings==2.5.2
passlib==1.7.4
# bcrypt MUSS gepinnt bleiben: passlib 1.7.4 liest bcrypt.__about__ (in
# bcrypt >= 4.1 entfernt) — der Backend-Selbsttest crasht dann mit
# "password cannot be longer than 72 bytes" und JEDES Hashing schlägt fehl.
# Genau das hielt die Ampel ab dem 23.07. rot (stable blieb 10 Commits zurück).
bcrypt==4.0.1
PyJWT==2.9.0
python-multipart==0.0.9
# passlib/bcrypt/PyJWT/python-multipart entfernt (Auth-Rückbau 24.07.2026,
# Commander-Entscheid: Heimnetz-only, siehe KONZEPT §10) — damit ist auch
# die passlib↔bcrypt-Versionsfalle Geschichte, die die Ampel rot hielt.
aiofiles==24.1.0
+340
View File
@@ -0,0 +1,340 @@
"""Wo liegen die Roh-MKVs eines Jobs? — Suchen statt annehmen.
## Der Fund, der dieses Modul nötig gemacht hat (26.07.2026, live gemessen)
Job `95afdc89` stand auf `failed`, und im Ablageziel lagen **79,6 GB** intakter
Rohschnitt (`/app/media/rippy/95afdc89-/title_t00.mkv`). Der SAVEPOINT v3.16
schrieb dazu: Neu komprimieren' genügt, kein Neu-Rip". Die Gegenprobe an der
laufenden Instanz sagt: **`can_retry` war `false`** den Knopf gab es gar nicht.
Ursache: `_kann_neu_komprimieren` suchte an genau zwei Orten im
Container-Standard `/app/temp/raw/<id>` und unter dem AKTUELLEN Wert der
Einstellung `workDir`. Der Rip war aber mit einer Wahl *für diesen einen Rip*
auf die NAS gelegt worden (das gibt es seit v3.15 im Rip-Dialog), und die
Einstellung selbst stand auf leer. Damit zeigte nichts mehr auf die Datei:
workDir (Einstellung) = "" geprüft wurde nur /app/temp/raw
tatsächlicher Ort = /app/media/rippy/<id>
Ergebnis 75 GB unsichtbar, Neu-Rip scheinbar unvermeidlich
Das ist derselbe Fehler, der dieses Projekt schon mehrfach gekostet hat: aus
einem Zustandswert (der heutigen Einstellung) auf einen Mechanismus (wohin
damals gerippt wurde) geschlossen, statt nachzusehen.
## Warum gesucht und nicht gespeichert wird
Den Ort in die Job-Zeile zu schreiben wäre sauberer aber die jobs-Tabelle
bräuchte eine neue Spalte, und `create_all` legt nur fehlende TABELLEN an, keine
fehlenden Spalten. Eine Migration für einen Suchraum von einer Handvoll
Verzeichnissen ist das falsche Werkzeug, und Bestandsjobs (genau der Fall hier)
hätten den Wert ohnehin nicht.
Der Suchraum ist nämlich klein und geschlossen: `_arbeitsverzeichnis()` im Worker
lässt ausschließlich den Container-Standard oder einen Pfad UNTER `/app/media`
zu. Es genügt also, `/app/temp/raw/<id>` und `<jedes Speicherziel>/<id>`
anzusehen die oberste Ebene von `/app/media`, ohne Rekursion.
Verwechslungsgefahr gibt es dabei nicht: Roh-Verzeichnisse heißen exakt wie die
Job-ID (vollständige UUID), fertige Ablagen heißen `Titel (Jahr) [kurz-id]`.
"""
import os
import subprocess
from rippy import pfade as _pfade
# Container-Standard für Roh-Rips (RAW_DIR im Worker). Bleibt als Rueckfall
# stehen — die WURZELN dieses Betriebs liefert `wurzeln()`.
RAW_STANDARD = "/app/temp/raw"
MEDIA_ROOT = "/app/media"
def _ui_einstellungen() -> dict:
"""Was in der Oberflaeche eingestellt ist — leer, wenn die Datenbank
gerade nicht antwortet.
Bewusst gekapselt und abgesichert: `wurzeln()` wird auch aus der
Jobliste heraus aufgerufen, die alle vier Sekunden laeuft. Sie darf an
einer klemmenden Datenbank nicht scheitern dann gilt eben die
Vorgabe, wie bisher.
"""
try:
from rippy import store as db
return db.get_settings(bei_fehler_leer=True) or {}
except Exception: # noqa: BLE001
return {}
def wurzeln(werte=None) -> tuple:
"""`(roh_standard, medien_wurzel, frei)` fuer DIESEN Betrieb.
## Warum das nicht fest sein darf (Befund 29.08.2026)
Dieses Modul findet die Rohdaten eines Jobs wieder fuer den
Wiederholen-Dialog (auf der Platte liegen X GB Rohdaten") und fuer
Rohdaten mitloeschen". Es suchte fest unter `/app/temp/raw` und
`/app/media`.
Auf einem Windows-PC gibt es beides nicht. Also fand es NIE etwas: Der
Dialog meldete keine Rohdaten", das Aufraeumen loeschte nichts, und die
Bruchstuecke eines abgebrochenen Rips blieben unbemerkt liegen bei einer
4K-UHD bis zu 100 GB.
"""
from rippy import betrieb, config
if werte is None:
try:
werte = config.laden()
except Exception: # noqa: BLE001
werte = {}
# Dieselbe Bruecke wie in /system/info: Die Oberflaeche legt
# ihre Orte in der Datenbank ab, nicht in der Datei. Ohne sie
# suchte die Rohdaten-Suche unter der Vorgabe statt unter dem,
# was eingestellt ist (Befund 30.08.2026).
werte = betrieb.mit_einstellungen(werte, _ui_einstellungen())
return (betrieb.arbeits_vorgabe(werte) or RAW_STANDARD,
betrieb.medien_wurzel(werte) or MEDIA_ROOT,
betrieb.frei_blaettern(werte))
# Harte Obergrenze für EINE Verzeichnis-Prüfung. Siehe verzeichnis_da().
PRUEF_TIMEOUT_SEKUNDEN = 4
def kandidaten(job_id: str, work_dir: str, media_unterordner,
orte_wurzeln=None) -> list:
"""Alle Orte, an denen die Roh-MKVs dieses Jobs liegen KÖNNTEN (pure).
`media_unterordner` sind die Namen der obersten Ebene unter /app/media
(Ablageziele inkl. eingehängter Freigaben) die Liste kommt vom Aufrufer,
damit diese Funktion ohne Dateisystem testbar bleibt.
Reihenfolge: Container-Standard, dann die eingestellte Wahl, dann alle
Ablageziele. Doppelte fliegen raus, die Reihenfolge bleibt stabil.
posixpath, nicht os.path: Das sind Container-Pfade. os.path.join baut unter
Windows Backslashes daraus, und dann greift keine Prüfung mehr dieselbe
Falle wie bei `_zielbasis()` (v3.14) und `_mountpoint()` (26.07.2026).
"""
if not job_id:
return []
roh, medien, frei = orte_wurzeln or (RAW_STANDARD, MEDIA_ROOT, False)
from rippy import pfade
orte = [pfade.verbinden(roh, job_id)]
# Zum VERGLEICHEN ohne Schluss-Trenner, zum VERBINDEN mit.
#
# ⚠️ Befund 30.08.2026, am Rechner des Commanders nachgerechnet:
# Hier stand `wahl = (work_dir or "").strip().rstrip("/\\")`, und mit
# dieser einen abgestreiften Zeichenkette wurde dann auch VERBUNDEN.
# Sein Arbeitsordner ist `F:\` — ein Laufwerks-Stammverzeichnis:
#
# "F:\\".rstrip("/\\") -> "F:"
# verbinden("F:", job_id) -> "F:1aa41fef-…" isdir: False
# verbinden("F:\\", job_id) -> "F:\1aa41fef-…" isdir: True
#
# `F:` ohne Trenner heisst unter Windows „der aktuelle Ordner auf
# Laufwerk F", nicht die Wurzel — die Falle steht woertlich im Kopf von
# `pfade.verbinden`, und diese Zeile ist hineingetreten. Folge: 16,5 GB
# Rohschnitt unsichtbar, und der Wiederholen-Dialog bot nur „Neu
# rippen" an — Stunden am beschaedigten Datentraeger fuer nichts.
wahl = (work_dir or "").strip()
vergleich = wahl.rstrip("/\\")
grenze = (medien or "").rstrip("/\\")
# Nativ zaehlt jede Wahl — dort liegt der Arbeitsordner oft auf einem
# ganz anderen Laufwerk und damit unter gar keiner Wurzel.
if vergleich and (frei or vergleich == grenze
or vergleich.startswith(grenze + "/")):
orte.append(pfade.verbinden(wahl, job_id))
for name in media_unterordner or []:
if name:
orte.append(pfade.verbinden(pfade.verbinden(medien, name), job_id))
gesehen, eindeutig = set(), []
for ort in orte:
if ort not in gesehen:
gesehen.add(ort)
eindeutig.append(ort)
return eindeutig
def nativ_nachsehen() -> bool:
"""Darf direkt nachgesehen werden, statt einen Prozess dafuer zu starten?
Eigene Funktion, damit beide Zweige ueberall pruefbar sind dieselbe
Regel wie bei `betrieb.im_container`. Die Begruendung steht in
`pruefen`.
"""
return os.name == "nt"
def pruefen(pfad: str, laufen=None) -> str:
"""Gibt es dieses Verzeichnis? „da" | „weg" | „unklar" — mit HARTER Zeitgrenze.
Drei Antworten statt zwei, weil ich konnte nicht nachsehen" etwas anderes
ist als es ist nicht da". Gemessen am 26.07.2026: Nach einem
Container-Neustart stallt der ERSTE Zugriff auf die CIFS-Freigabe mehrere
Sekunden (die SMB-Sitzung wird neu aufgebaut), danach antwortet sie in
0,01 s zehn von zehn Versuchen. Ohne die Unterscheidung verschwindet in
diesem Fenster der Knopf Neu komprimieren", und der Nutzer schließt daraus,
seine 74 GB seien weg. Genau diese Sorte Fehlschluss hat das Projekt schon
zweimal bezahlt.
Begründung der Technik siehe verzeichnis_da.
"""
if not pfad:
return "weg"
if laufen is None and nativ_nachsehen():
# ## Warum Windows hier NICHT den Umweg ueber einen Prozess geht
#
# ⚠️ Befund 30.08.2026, an der laufenden Instanz beobachtet:
#
# 14:54:40 timeout.exe timeout 4 ls -d C:\\...\\d7ee6c06-...
# 14:54:40 WindowsTerminal.exe
#
# Der Commander: „nun oeffnen sich diverse fenster im hintergrund,
# gehen ganz kurz auf und dann wieder zu."
#
# `timeout` und `ls` sind Linux-Befehle. Unter Windows GIBT es eine
# `timeout.exe` — sie wartet nur Sekunden ab und kennt weder `ls`
# noch `-d`. Sie braucht aber eine Konsole, und die reisst Windows
# dann auf. Dreifach falsch also: ein Fenster bei jedem Durchlauf,
# ein Prozess fuer nichts, und ein Rueckgabewert ungleich 0 — also
# die Antwort „weg" fuer JEDES Verzeichnis. Rohdaten waren damit
# unter Windows grundsaetzlich unsichtbar.
#
# Der Grund fuer den Umweg gilt hier nicht: Der Kernel-Hang im
# Zustand D (siehe `verzeichnis_da`) ist eine Linux-Eigenheit. Ein
# totes Netzlaufwerk laesst `os.path.isdir` unter Windows mit einem
# Fehler zurueckkommen, nicht unabbrechbar haengen.
try:
return "da" if os.path.isdir(pfad) else "weg"
except OSError:
return "unklar"
starten = laufen or subprocess.run
try:
ergebnis = starten(
["timeout", str(PRUEF_TIMEOUT_SEKUNDEN), "ls", "-d", pfad],
capture_output=True,
timeout=PRUEF_TIMEOUT_SEKUNDEN + 2,
)
except (OSError, subprocess.TimeoutExpired):
return "unklar"
if ergebnis.returncode == 0:
return "da"
# 124 ist der Rückgabewert von `timeout`, wenn es das Kind abgeschossen hat
# (dokumentiert in coreutils). Das heißt: nicht angesehen, nicht „weg".
return "unklar" if ergebnis.returncode == 124 else "weg"
def verzeichnis_da(pfad: str, laufen=None) -> bool:
"""Gibt es dieses Verzeichnis? — mit HARTER Zeitgrenze.
## Warum nicht os.path.isdir
Weil es an einem Netz-Mount unbegrenzt hängen kann, und zwar im Kernel
(Prozess-Zustand D, uninterruptible sleep"). Genau das ist am 26.07.2026
passiert: Die Hintergrund-Schleife startete ihren ersten Durchlauf, während
Rippy die CIFS-Freigabe nach einem Container-Neustart neu einhängte. Ihr
`os.path.isdir` blieb stecken, `asyncio.to_thread` kam nie zurück, die
Schleife erreichte ihr `sleep` nie und war damit für immer tot. Sichtbar
war nur, dass `can_retry` dauerhaft `false` blieb; zwei Threads standen im
Zustand D.
Ein Timeout um den Aufruf hätte nichts geholfen: Ein im Kernel hängender
Thread lässt sich aus Python nicht abbrechen, jeder Versuch hätte einen
weiteren Thread verbrannt, bis der Pool leer ist.
Ein Kind-PROZESS lässt sich abbrechen. Deshalb `timeout N ls -d <pfad>`
dasselbe Werkzeug, das `mounts.ist_erreichbar` seit dem 24.07.2026 für
genau dieses Problem benutzt (dort für den toten NAS-Mount). Läuft es in
die Zeitgrenze, gilt das Verzeichnis als nicht da": Ein Ort, den man nicht
innerhalb von Sekunden ansehen kann, ist für einen Rip ohnehin unbrauchbar.
`laufen` ist einspritzbar, damit das ohne echte Prozesse testbar bleibt.
Für den Fall konnte nicht nachsehen" gibt es `pruefen()` mit drei
Antworten. Hier gilt nur da" als ja — wer eine Ja/Nein-Antwort braucht,
soll im Zweifel Nein bekommen.
"""
return pruefen(pfad, laufen) == "da"
def suche(job_id: str, work_dir: str, listdir, isdir,
orte_wurzeln=None) -> list:
"""Die Orte, an denen wirklich etwas liegt.
`listdir` und `isdir` werden übergeben statt importiert so ist die Suche
ohne Dateisystem prüfbar. Für `isdir` gehört `verzeichnis_da` eingesetzt und
NICHT os.path.isdir: Die Kandidaten liegen unter /app/media, und dort kann
ein Netz-Mount unbegrenzt hängen (Begründung bei verzeichnis_da).
`listdir` darf os.listdir bleiben: Gelistet wird nur /app/media selbst, und
das ist ein lokales Verzeichnis die Freigaben sind Unterordner davon.
"""
orte_wurzeln = orte_wurzeln or wurzeln()
try:
unterordner = sorted(listdir(orte_wurzeln[1]))
except OSError:
unterordner = []
gefunden = []
for ort in kandidaten(job_id, work_dir, unterordner, orte_wurzeln):
try:
if isdir(ort):
gefunden.append(ort)
except OSError:
# Toter Mount → als „nicht da" werten. Ein Fehlschlag hier darf die
# Job-Liste nicht mitnehmen (Befund 24.07. bei /storage-targets).
continue
return gefunden
def suche_mit_status(job_id: str, work_dir: str, listdir, pruefer=None,
orte_wurzeln=None) -> dict:
"""Wie suche(), aber sagt auch, ob etwas UNGEPRÜFT geblieben ist.
Rückgabe: {"pfade": [...], "unklar": bool}. `unklar` heißt: Mindestens ein
Ort hat nicht geantwortet ein leeres `pfade` ist dann kein Beweis für
nichts da". Der Aufrufer soll in diesem Fall seine letzte bekannte Antwort
behalten, statt Abwesenheit zu behaupten (siehe pruefen()).
"""
pruefe = pruefer or pruefen
orte_wurzeln = orte_wurzeln or wurzeln()
try:
unterordner = sorted(listdir(orte_wurzeln[1]))
except OSError:
unterordner = []
gefunden, unklar = [], False
for ort in kandidaten(job_id, work_dir, unterordner, orte_wurzeln):
antwort = pruefe(ort)
if antwort == "da":
gefunden.append(ort)
elif antwort == "unklar":
unklar = True
return {"pfade": gefunden, "unklar": unklar}
def groesse(pfade: list, listdir, isfile, getsize) -> tuple:
"""(Bytes, Dateizahl) der Roh-Dateien — flach, nicht rekursiv.
Flach genügt: MakeMKV legt die Titel als `title_tNN.mkv` direkt in das
Job-Verzeichnis, Unterordner entstehen dort nicht.
"""
bytes_gesamt, dateien = 0, 0
for pfad in pfade or []:
try:
namen = listdir(pfad)
except OSError:
continue
for name in namen:
# `pfade.verbinden` statt posixpath: Auf Windows ist `pfad`
# ein echter Windows-Pfad, und `posixpath.join` baute daraus
# `C:\Roh/datei.mkv` — gemischte Trenner, die im UI falsch
# aussehen und jeden Vergleich brechen (Befund 29.08.2026).
voll = _pfade.verbinden(pfad, name)
try:
if isfile(voll):
bytes_gesamt += getsize(voll)
dateien += 1
except OSError:
continue
return bytes_gesamt, dateien
+911 -9
View File
@@ -2,26 +2,54 @@
Warum: Kein anderer Test importiert main.py ein Tippfehler dort fiele sonst
erst beim Container-Start auf (und die Ampel bliebe fälschlich grün).
Läuft nur unter Linux (detection.py nutzt fcntl/ioctl), also genau dort,
wo auch die Ampel läuft.
## Warum das hier nicht mehr uebersprungen wird (28.08.2026)
Bis V2-4 stand hier ein `pytest.skip` fuer Windows: `main.py` importierte
`rippy.drives.linux` direkt, und das braucht `fcntl`. Seit die Treiberwahl
ueber den Port `rippy.ports.Drives` laeuft, laedt `main.py` auf BEIDEN
Plattformen nachgemessen: 57 Routen, sauberer Import.
Das Ueberspringen war damit nicht mehr Vorsicht, sondern eine Luecke: Diese
siebzehn Tests liefen nur auf der Ampel. Und ein Test, der nur auf einer
Plattform greift, ist eine halbe Zusage genau daran ist die Ampel am
28.08.2026 fuenf Laeufe lang unbemerkt rot gewesen.
"""
import sys
import pytest
if sys.platform == "win32": # pragma: no cover
pytest.skip("detection.py braucht fcntl (Linux)", allow_module_level=True)
import pytest # noqa: F401 (einzelne Tests brauchen ihn fuer skipif)
def test_main_importierbar_und_routen_verdrahtet():
from main import app
routen = {route.path for route in app.routes}
for pfad in ("/health", "/jobs", "/devices", "/logs", "/settings", "/prescan"):
for pfad in (
"/health", "/jobs", "/devices", "/logs", "/settings",
# KEYDB.cfg + AACS-Dumps: der Platz für die selbst mitgebrachte
# Schlüsseldatei (Befund 25.07.2026 — MakeMKV holt UHD-Schlüssel nicht
# mehr online nach). Ohne diese Routen ist die Seite im UI tot.
"/system/keydb", "/system/aacs-dumps", "/system/aacs-dumps/{dateiname}",
# Der Hauptweg für 4K-UHD (25.07.2026): makemkvcon holt Disc-Schluessel
# unter Linux nie selbst, sie kommen von Hand über diesen Endpunkt.
"/system/keystore",
# Ohne die weiss das UI nicht, worauf es laeuft — und zeigt dann auf
# einem Windows-PC "Pruefen: docker compose ps" (Befund 28.08.2026).
"/betrieb",
):
assert pfad in routen, f"Route {pfad} fehlt"
def test_dateiname_validierung_blockt_pfad_tricks():
"""Download-Endpoint: nur nackte Dateinamen — kein .., kein Slash, kein Dotfile."""
from main import _sicherer_dateiname
assert _sicherer_dateiname("film.mkv") is True
assert _sicherer_dateiname("../../etc/passwd") is False
assert _sicherer_dateiname("a/b.mkv") is False
assert _sicherer_dateiname("a\\b.mkv") is False
assert _sicherer_dateiname(".versteckt") is False
assert _sicherer_dateiname("") is False
def test_worker_task_name_passt_zum_celery_client():
"""API schickt an 'worker.tasks.rip_disc' — der Name ist Vertrag mit dem Worker."""
import inspect
@@ -30,3 +58,877 @@ def test_worker_task_name_passt_zum_celery_client():
quelle = inspect.getsource(celery_client.start_rip)
assert '"worker.tasks.rip_disc"' in quelle
def test_remount_blockiert_den_api_start_nicht():
"""Regression (Vorfall 24.07.): ein haengender Netz-Mount (CIFS-Schreibtest kann
im Kernel haengen, wait_for_response) darf den API-Start NICHT blockieren. remount
muss als Hintergrund-Task laufen (create_task), nicht direkt awaited werden."""
import inspect
import main
quelle = inspect.getsource(main.startup_event)
assert "create_task(asyncio.to_thread(remount))" in quelle, \
"remount muss als Hintergrund-Task laufen (nicht blockierend)"
assert "await asyncio.to_thread(remount)" not in quelle, \
"remount darf nicht mehr direkt awaited werden (blockiert sonst den Start)"
def test_unter_wurzel_faellt_nicht_auf_praefix_namen_herein():
"""Befund 25.07.2026: In main.py prüften neun Stellen mit nacktem
startswith(MEDIA_ROOT) darunter /browse und /browse/mkdir, wo der Pfad
vom Nutzer kommt. /app/media-boese/x" beginnt mit „/app/media", liegt
aber außerhalb. Zwilling von tasks.unter_wurzel im Worker."""
from main import unter_wurzel
assert unter_wurzel("/app/media", "/app/media") is True
assert unter_wurzel("/app/media/movies", "/app/media") is True
assert unter_wurzel("/app/media-boese/x", "/app/media") is False
assert unter_wurzel("/app/mediaX", "/app/media") is False
assert unter_wurzel("/etc/passwd", "/app/media") is False
assert unter_wurzel("", "/app/media") is False
assert unter_wurzel("/app/media", "") is False
assert unter_wurzel("/app/media/movies", "/app/media/") is True
def test_ping_vorrat_verhindert_die_wartesekunde(monkeypatch):
"""Gemessen 25.07.2026: /capabilities brauchte 1,010 s - jedes Mal. Der
Celery-Ping sammelt Antworten bis zum Timeout und kann nicht früher
aufhoeren. Fuenf UI-Stellen holen /capabilities, also zahlte jede Seite
eine Sekunde, während alle anderen Endpunkte unter 25 ms lagen.
Der Vorrat muss deshalb abgelesen und NICHT neu gepingt werden, solange er
frisch ist - und bei altem Vorrat lieber einmal langsam als falsch.
"""
import time as _t
import main
pings = []
monkeypatch.setattr(main, "_ping_jetzt", lambda: pings.append(1) or ["celery@neu"])
# Frischer Vorrat -> ablesen, kein Ping
monkeypatch.setitem(main._PING, "knoten", ["celery@alt"])
monkeypatch.setitem(main._PING, "stand", _t.monotonic())
assert main._ping_knoten() == ["celery@alt"]
assert pings == [], "bei frischem Vorrat darf NICHT gepingt werden"
# Zu alter Vorrat -> einmal synchron pingen
monkeypatch.setitem(main._PING, "stand", _t.monotonic() - main.PING_ALTER_MAX_SEKUNDEN - 1)
assert main._ping_knoten() == ["celery@neu"]
assert len(pings) == 1
# Kalter Start (nie gepingt) -> ebenfalls pingen, nicht "alles offline" melden
monkeypatch.setitem(main._PING, "stand", -1e9)
main._ping_knoten()
assert len(pings) == 2
def test_ping_takt_ist_kuerzer_als_die_haltbarkeit():
"""Sonst läuft der Vorrat zwischen zwei Hintergrund-Laeufen ab und der
Endpunkt pingt doch wieder synchron."""
import main
assert main.PING_INTERVALL_SEKUNDEN < main.PING_ALTER_MAX_SEKUNDEN
def test_tote_routen_sind_und_bleiben_weg():
"""Entfernt am 25.07.2026, jede ein Überrest eines ersetzten Entwurfs und
ohne einen einzigen Aufrufer (mechanisch gegengeprueft: alle api.*-Aufrufe
des UI gegen alle Routen).
Der Test hält sie draussen. /stream/jobs ist der Grund für diese
Absicherung: er war schon einmal ein Placebo, wurde dann "repariert" statt
entfernt - und war danach eine Endlosschleife je Verbindung ohne jeden
Verbraucher. Wer echtes Push will, braucht BEIDE Seiten (Server UND ein
EventSource im UI).
"""
from main import app
routen = {route.path for route in app.routes}
for pfad in ("/prescan", "/jellyfin/format", "/stream/jobs",
"/worker-setup/windows-gui"):
assert pfad not in routen, (
f"{pfad} ist wieder da — entweder mit Verbraucher (dann diesen Test "
"anpassen) oder versehentlich (dann wieder raus)"
)
def test_worker_setup_routen_die_gebraucht_werden_sind_da():
"""Die Installer holen sich Code und .exe hierueber — /worker-setup/paket
ruft install.ps1 UND install-gui.ps1 auf, /windows-exe der UI-Knopf."""
from main import app
routen = {route.path for route in app.routes}
for pfad in ("/worker-setup/paket", "/worker-setup/windows",
"/worker-setup/windows-exe"):
assert pfad in routen, f"Route {pfad} fehlt — Worker-Installation kaputt"
# --- Mount-Wache: heilt, was nach jedem Rebuild kaputt ist -------------------
#
# Hier statt in test_mounts_helpers.py, weil diese Tests `main` brauchen und
# main.py haengt an fcntl (Linux). Dieses Modul ueberspringt sich unter Windows
# selbst — es laeuft also genau da, wo auch die Ampel laeuft.
def test_wache_ruehrt_nichts_an_solange_ein_job_laeuft(monkeypatch):
"""Neu verbinden heisst `umount -l`. Mitten in einem Rip oder Encode waere
das ein Datenverlust - die Wache muss dann stillstehen."""
import main
monkeypatch.setattr(main.db, "list_mounts", lambda: [
{"name": "rippy", "typ": "cifs", "quelle": "//nas/rippy"}])
monkeypatch.setattr(main.db, "hat_arbeit", lambda: True)
monkeypatch.setattr(main.mount_verwaltung, "ist_erreichbar",
lambda name: (_ for _ in ()).throw(AssertionError("nicht anfassen!")))
main._mounts_nachsehen() # darf einfach nichts tun
def test_wache_verbindet_eine_stumme_freigabe_neu(monkeypatch):
import main
repariert, gelogged = [], []
monkeypatch.setattr(main.db, "list_mounts", lambda: [
{"name": "rippy", "typ": "cifs", "quelle": "//nas/rippy"}])
monkeypatch.setattr(main.db, "hat_arbeit", lambda: False)
monkeypatch.setattr(main.db, "add_log",
lambda lvl, src, msg: gelogged.append((lvl, msg)))
monkeypatch.setattr(main.mount_verwaltung, "ist_erreichbar", lambda name: False)
monkeypatch.setattr(main.mount_verwaltung, "reparieren",
lambda *a, **k: repariert.append(a[0]))
main._MOUNT_STAND.clear()
main._mounts_nachsehen()
assert repariert == ["rippy"]
assert any("neu verbunden" in m for _, m in gelogged)
def test_wache_meckert_nicht_jede_minute(monkeypatch):
"""Ist das NAS ausgeschaltet, waere ein Log je Minute ein Wasserfall.
Gemeldet wird nur der UEBERGANG."""
import main
gelogged = []
monkeypatch.setattr(main.db, "list_mounts", lambda: [
{"name": "rippy", "typ": "cifs", "quelle": "//nas/rippy"}])
monkeypatch.setattr(main.db, "hat_arbeit", lambda: False)
monkeypatch.setattr(main.db, "add_log",
lambda lvl, src, msg: gelogged.append(msg))
monkeypatch.setattr(main.mount_verwaltung, "ist_erreichbar", lambda name: False)
def reparieren_scheitert(*a, **k):
raise RuntimeError("NAS aus")
monkeypatch.setattr(main.mount_verwaltung, "reparieren", reparieren_scheitert)
main._MOUNT_STAND.clear()
for _ in range(5):
main._mounts_nachsehen()
# "antwortet nicht" genau EINMAL (der Uebergang), die Fehlschlaege sind
# jeweils eigene Meldungen - aber kein wiederholtes "antwortet nicht".
assert len([m for m in gelogged if "antwortet nicht" in m]) == 1
def test_wache_meldet_wenn_es_wieder_geht(monkeypatch):
import main
gelogged = []
zustand = {"da": False}
monkeypatch.setattr(main.db, "list_mounts", lambda: [
{"name": "rippy", "typ": "cifs", "quelle": "//nas/rippy"}])
monkeypatch.setattr(main.db, "hat_arbeit", lambda: False)
monkeypatch.setattr(main.db, "add_log",
lambda lvl, src, msg: gelogged.append(msg))
monkeypatch.setattr(main.mount_verwaltung, "ist_erreichbar",
lambda name: zustand["da"])
monkeypatch.setattr(main.mount_verwaltung, "reparieren",
lambda *a, **k: None)
main._MOUNT_STAND.clear()
main._MOUNT_STAND["rippy"] = False
zustand["da"] = True
main._mounts_nachsehen()
assert any("antwortet wieder" in m for m in gelogged)
# --- Live-Ereignisse (SSE), Etappe V2-3 --------------------------------------
def test_events_route_ist_verdrahtet():
"""Ohne diese Route fällt das UI stumm auf seinen letzten Stand zurück —
und weil ein Abriss KEINE Aussage ist, sähe der Nutzer einfach nichts
Neues, ohne Fehlermeldung. Deshalb hier festgenagelt."""
from main import app
assert "/events" in {route.path for route in app.routes}
def test_sse_rahmen_hat_das_format_das_der_browser_erwartet():
"""`id:` ist nicht Kosmetik — der Browser schickt genau diesen Wert beim
Wiederverbinden als Last-Event-ID zurück. Fehlt er, gibt es keine
lückenlose Wiederaufnahme, und jeder WLAN-Wechsel reisst ein Loch."""
from main import _sse_rahmen
rahmen = _sse_rahmen({"seq": 42, "typ": "job.progress", "daten": {"prozent": 7}})
zeilen = rahmen.split("\n")
assert zeilen[0] == "id: 42"
assert zeilen[1] == "event: job.progress"
assert zeilen[2].startswith("data: {")
# Zwei Leerzeilen am Ende: eine schliesst das Ereignis, die zweite ist der
# Trenner. Ohne den doppelten Umbruch haelt der Browser das Ereignis fuer
# unvollstaendig und liefert es NIE aus.
assert rahmen.endswith("\n\n")
def test_sse_rahmen_uebersteht_umlaute():
"""Job-Titel und Log-Zeilen sind deutsch. Mit ensure_ascii=True kaeme
"Gr\u00f6\u00dfe" beim Nutzer an."""
from main import _sse_rahmen
rahmen = _sse_rahmen({"seq": 1, "typ": "log.line", "daten": {"text": "Größe"}})
assert "Größe" in rahmen
def test_snapshot_meldet_unlesbare_laufwerke_als_none(monkeypatch):
"""„konnte nicht nachsehen" ist etwas anderes als „es gibt keine".
Genau diese Vermischung hat in v1 die Job-Liste im Sekundentakt geleert
(fuenfmal `catch(() => [])` im UI). Ein Snapshot mit devices=[] wuerde dem
UI sagen du hast kein Laufwerk"; None sagt „ich weiss es gerade nicht",
und das UI behaelt seinen Stand.
OHNE DATENBANK: Die Ampel hat keine Postgres der erste Anlauf dieses
Tests lief deshalb rot (Lauf 170). Der Store wird hier ersetzt, denn
geprueft wird die Snapshot-LOGIK, nicht die Datenbank.
"""
import asyncio
import main
monkeypatch.setattr(main.db, "list_jobs", lambda limit=50: [])
monkeypatch.setattr(main.db, "list_workers", lambda: [])
monkeypatch.setattr(main.db, "list_logs", lambda limit=50: [])
def kaputt():
raise OSError("Laufwerk haengt")
monkeypatch.setattr(main.device_discovery, "list_optical_devices", kaputt)
zustand = asyncio.run(main._snapshot())
assert zustand["devices"] is None, "Ein unlesbares Laufwerk darf nicht als [] durchgehen"
assert zustand["jobs"] == []
def test_snapshot_liefert_das_ganze_bild(monkeypatch):
"""Ein Client, der sich verbindet, bekommt das GANZE Bild — sonst muesste
er den Rest raten und faellt auf Polling zurueck.
## Warum der Server-Zustand dazugehoert (Befund 28.08.2026)
Er fehlte im Schnappschuss, und der Waechter schickt ihn nur alle 15
Sekunden. Ein frisch geladenes Dashboard stand deshalb bis zu einer
Viertelminute auf Platz fuer Rippy: unbekannt" — und das sieht aus wie
eine Auskunft, obwohl es keine ist. Genau das hat der Commander im
Windows-Fenster gesehen.
"""
import asyncio
import main
monkeypatch.setattr(main.db, "list_jobs", lambda limit=50: [])
monkeypatch.setattr(main.db, "list_workers", lambda: [{"name": "pc"}])
monkeypatch.setattr(main.db, "list_logs", lambda limit=50: [])
monkeypatch.setattr(main.device_discovery, "list_optical_devices", lambda: [])
# Ohne DB liefe system_info() in eine Ausnahme, und die Ampel hat keine
# Datenbank (Lauf 170). Geprueft wird hier die FORM des Schnappschusses.
#
# `*a, **k`, nicht `lambda: {}` (Befund 30.08.2026): Die echte
# Funktion heisst `get_settings(key="ui", bei_fehler_leer=False)`.
# Der zu enge Doppelgaenger warf `TypeError`, sobald ein Aufrufer
# einen der Parameter benutzte — `system_info` fiel damit aus dem
# Schnappschuss, und dieser Test zeigte auf den Code statt auf sich
# selbst. Ein Doppelgaenger muss die Schnittstelle abbilden, die er
# ersetzt, nicht nur den einen Aufruf, den es gerade gibt.
monkeypatch.setattr(main.db, "get_settings", lambda *a, **k: {})
zustand = asyncio.run(main._snapshot())
assert {"jobs", "workers", "logs", "devices"} <= set(zustand)
assert "info" in zustand, (
"Ohne den Server-Zustand steht das Dashboard nach jedem Neuladen "
"bis zu 15 Sekunden auf 'unbekannt'."
)
assert zustand["devices"] == [] # wirklich leer, nicht „unbekannt"
assert zustand["workers"] == [{"name": "pc"}]
def test_ein_kaputter_server_zustand_kippt_den_schnappschuss_nicht(monkeypatch):
"""Der Schnappschuss ist die Grundlage fuer ALLES im UI. Lieber ohne
Platzangabe (das UI behaelt seinen Stand) als gar kein Schnappschuss."""
import asyncio
import main
monkeypatch.setattr(main.db, "list_jobs", lambda limit=50: [])
monkeypatch.setattr(main.db, "list_workers", lambda: [])
monkeypatch.setattr(main.db, "list_logs", lambda limit=50: [])
monkeypatch.setattr(main.device_discovery, "list_optical_devices", lambda: [])
async def platzt():
raise RuntimeError("Platte weg")
monkeypatch.setattr(main, "system_stand_fuer_snapshot", platzt)
zustand = asyncio.run(main._snapshot())
assert {"jobs", "workers", "logs", "devices"} <= set(zustand)
def test_betrieb_meldet_faehigkeiten_statt_nur_einen_namen():
"""Der Befund vom 28.08.2026: Das Windows-Fenster zeigte "Worker
erreichbar: 0 von 1", "Container-Platte" und "Pruefen: docker compose ps"
auf einem PC ohne Container und ohne zweiten Worker.
Das UI muss FAEHIGKEITEN bekommen, keinen Modus-Namen: Aus einem Namen
auf Verhalten zu schliessen bricht beim naechsten Betriebsfall (ein
Docker-All-in-One hat Container-Pfade, aber keine externen Worker).
"""
from fastapi.testclient import TestClient
from main import app
# OHNE `with`: Der Kontextmanager loest den Lebenszyklus aus, und der legt
# Tabellen an — auf der Ampel gibt es keine Datenbank. Genau daran ist
# Lauf 170 rot geworden. /betrieb braucht keine.
antwort = TestClient(app).get("/betrieb")
assert antwort.status_code == 200
daten = antwort.json()
assert daten["modus"] in ("standalone", "verteilt")
assert daten["plattform"] in ("windows", "linux", "macos")
assert set(daten["kann"]) == {"externe_worker", "freigaben_einhaengen",
"container_pfade", "werkzeuge_verwalten",
"frei_blaettern"}
# Beide Orte muessen dabei sein. Fehlte einer, muesste die Oberflaeche
# wieder raten — und genau daraus wurde „Container-Platte" auf einem PC,
# der keinen Container hat (Befund 28.08.2026).
assert daten["ablage_vorgabe"] and daten["arbeits_vorgabe"]
assert all(isinstance(w, bool) for w in daten["kann"].values())
# Ein Hinweis auf docker compose darf NUR im Container erscheinen.
if not daten["im_container"]:
assert daten["hilfe_befehl"] == ""
# ── Die Grenze DB → Oberflaeche (Befund 29.08.2026) ─────────────────────
#
# Commander mit Bildschirmfoto: „schau mal hier, das Datum ist falsch."
#
# TYP „DISC" STARTZEIT „1.1.1970, 01:00:00" STATUS „running"
#
# Der Waechter schickte die ROHE Datenbankzeile ueber den Ereignisstrom. Dort
# heissen die Spalten `disc_type` und `created_at`, im UI aber `type` und
# `startTime` — die Uebersetzung macht `_job_row_to_model`, und sie bildet
# auch `running` auf `processing` ab.
#
# Der Test, den ich beim ersten Anlauf geschrieben habe, hat das NICHT
# gefunden: Ich hatte seine Beispielzeile selbst erfunden, mit meinen
# falschen Feldnamen. Ein Test, der dieselbe Annahme macht wie der Code,
# prueft nichts. Dieser hier geht von der ECHTEN Zeile aus.
def _echte_db_zeile():
"""Eine Zeile mit den Spaltennamen, die wirklich in der Datenbank stehen."""
from datetime import datetime
return {
"id": "j1",
"disc_type": "bluray", # NICHT "type"
"created_at": datetime(2026, 8, 29, 12, 7, 2), # NICHT "startTime"
"finished_at": None,
"status": "running", # wird zu "processing"
"device": r"\.\G:",
"progress": 12,
"title": "Evangelion 2.22",
"error": None,
"meta": None,
}
def test_die_umwandlung_liefert_die_namen_die_das_ui_kennt():
import main
ui = main._job_row_to_model(_echte_db_zeile()).model_dump()
assert ui["type"] == "bluray"
assert ui["startTime"].startswith("2026-08-29")
assert ui["status"] == "processing", "der Worker-Status heisst im UI anders"
def test_das_live_ereignis_traegt_dieselben_namen_wie_die_jobliste():
"""DER Waechter gegen „1.1.1970". Ohne die Umwandlung sind alle
Pflichtfelder leer und leer sieht im Browser aus wie eine Auskunft."""
import main
from rippy.bus.waechter import UI_PFLICHTFELDER, _job_kurz
ui = main._job_row_to_model(_echte_db_zeile()).model_dump()
kurz = _job_kurz(ui)
for feld in UI_PFLICHTFELDER:
assert kurz.get(feld) is not None, "%s waere im Browser leer" % feld
assert kurz["type"] == "bluray"
assert kurz["status"] == "processing"
def test_der_waechter_ist_mit_der_umwandlung_verdrahtet():
"""Sonst waere die Reparatur wieder nur eine Moeglichkeit, keine Tatsache."""
import inspect
import main
quelle = inspect.getsource(main.startup_event)
assert "job_form=" in quelle, "Waechter bekommt die Umwandlung nicht"
assert "_job_row_to_model" in quelle
def test_die_laufwerksliste_kommt_aus_EINER_quelle():
"""Waechter gegen die vierte Kopie (Befund 29.08.2026).
Commander: Es ist eine Disk im laufwerk, aber er erkennt sie dort nicht."
Die Laufwerksliste wurde an DREI Stellen gebaut: im `/devices`-Endpunkt
(mit angehaengter Disc), im Ereignis-Waechter und im SSE-Schnappschuss
(beide ohne). Das Dashboard liest den Schnappschuss und schloss aus der
fehlenden Disc auf ein leeres Laufwerk, waehrend ihr Titel eine Zeile
weiter oben stand.
Eine Auskunft in drei Fassungen ist zwei Fassungen zu viel.
"""
import inspect
import main
quelle = inspect.getsource(main)
# Die eine erlaubte Fundstelle ist die Funktion selbst.
stellen = quelle.count("device_discovery.device_info(")
assert stellen == 1, (
"device_info wird an %d Stellen aufgerufen — die Liste gehoert in "
"laufwerke_mit_disc(), sonst fehlt irgendwo die Disc" % stellen)
for name in ("_snapshot", "startup_event", "get_devices"):
text = inspect.getsource(getattr(main, name))
assert "device_info(" not in text, \
"%s baut die Laufwerksliste selbst" % name
def test_laufwerke_mit_disc_haengt_die_erkannte_disc_an(monkeypatch):
import main
monkeypatch.setattr(main.device_discovery, "list_optical_devices",
lambda: [r"\.\G:"])
monkeypatch.setattr(main.device_discovery, "device_info",
lambda p: {"id": "G", "name": "Laufwerk G:", "path": p,
"type": "bluray", "status": "ready"})
monkeypatch.setitem(main.DISC_CACHE, r"\.\G:", {"title": "Evangelion 2.22"})
geraete = main.laufwerke_mit_disc()
assert geraete[0]["disc"]["title"] == "Evangelion 2.22"
def test_eine_noch_laufende_erkennung_wird_NICHT_als_disc_gemeldet(monkeypatch):
"""`_laeuft` heisst „wird gerade erkannt" — das ist noch keine Auskunft."""
import main
monkeypatch.setattr(main.device_discovery, "list_optical_devices",
lambda: [r"\.\G:"])
monkeypatch.setattr(main.device_discovery, "device_info",
lambda p: {"id": "G", "name": "Laufwerk G:", "path": p,
"type": "bluray", "status": "ready"})
monkeypatch.setitem(main.DISC_CACHE, r"\.\G:",
{"_laeuft": True, "title": "Wird erkannt…"})
assert "disc" not in main.laufwerke_mit_disc()[0]
def test_eine_laufende_erkennung_ist_SICHTBAR(monkeypatch):
"""Commander 29.08.2026: „das die disc erkennung noch läuft muss sichtbar
sein."
Vorher liess `laufwerke_mit_disc` einen laufenden Eintrag KOMPLETT weg
damit keine halbfertige Disc-Karte mit Wird erkannt" als Titel und
einem Rippen starten"-Knopf erscheint. Richtig gedacht, falsch geloest:
Fuer die Oberflaeche sah es aus wie ein leeres Laufwerk. Und das dauert:
`makemkvcon info` laeuft an einer Blu-ray in seine 120-Sekunden-Grenze
(gemessen: Disc nach 119 s erkannt).
"""
import main
monkeypatch.setattr(main.device_discovery, "list_optical_devices",
lambda: [r"\.\G:"])
monkeypatch.setattr(main.device_discovery, "device_info",
lambda p: {"id": "G", "name": "Laufwerk G:", "path": p,
"type": "bluray", "status": "ready"})
monkeypatch.setitem(main.DISC_CACHE, r"\.\G:",
{"_laeuft": True, "title": "Wird erkannt…"})
geraet = main.laufwerke_mit_disc()[0]
assert geraet["disc_wird_erkannt"] is True
# UND weiterhin keinen Titel behaupten, den es noch nicht gibt.
assert "disc" not in geraet
def test_nach_der_erkennung_ist_die_marke_wieder_weg(monkeypatch):
import main
monkeypatch.setattr(main.device_discovery, "list_optical_devices",
lambda: [r"\.\G:"])
monkeypatch.setattr(main.device_discovery, "device_info",
lambda p: {"id": "G", "name": "Laufwerk G:", "path": p,
"type": "bluray", "status": "ready"})
monkeypatch.setitem(main.DISC_CACHE, r"\.\G:", {"title": "Evangelion 2.22"})
geraet = main.laufwerke_mit_disc()[0]
assert not geraet.get("disc_wird_erkannt")
assert geraet["disc"]["title"] == "Evangelion 2.22"
def test_das_geraetemodell_gibt_die_marke_auch_heraus():
"""Ohne Feld im Modell schneidet FastAPI sie weg — und das UI saehe
wieder nichts (derselbe Fehler wie 25.07. bei `meta`)."""
import main
assert "disc_wird_erkannt" in main.Device.model_fields
# ── Die Notdurft-Auskunft (Befund 29.08.2026) ──────────────────────────
#
# Waehrend der Disc-Erkennung haelt makemkvcon das Laufwerk. Gemessen:
# /devices braucht dann 14,0 s, die Zeitgrenze des Schnappschusses ist 5,0 s.
# Der lieferte deshalb `devices = None` („konnte nicht nachsehen") — und nach
# einem frischen Laden hatte das UI keinen alten Stand, den es haette behalten
# koennen. Der Bildschirm blieb leer, ausgerechnet in der Phase, die sichtbar
# sein soll.
def test_notdurft_meldet_den_letzten_stand_plus_die_erkennung(monkeypatch):
import main
monkeypatch.setattr(main, "LETZTE_LAUFWERKE",
[{"id": "G", "name": "Laufwerk G:", "path": r"\.\G:",
"type": "bluray", "status": "ready"}])
monkeypatch.setitem(main.DISC_CACHE, r"\.\G:", {"_laeuft": True})
geraete = main.laufwerke_notdurft()
assert geraete[0]["disc_wird_erkannt"] is True
assert geraete[0]["type"] == "bluray", "der letzte bekannte Typ bleibt"
def test_notdurft_ohne_jeden_stand_erfindet_nichts(monkeypatch):
"""Wer nie erfolgreich gelesen hat, soll schweigen — `None` heisst
behalte deinen Stand", und das ist die ehrliche Antwort."""
import main
monkeypatch.setattr(main, "LETZTE_LAUFWERKE", [])
monkeypatch.setattr(main.device_discovery, "list_optical_devices", lambda: [])
assert main.laufwerke_notdurft() is None
def test_notdurft_beim_kaltstart_nennt_wenigstens_das_laufwerk(monkeypatch):
"""Kaltstart mitten in der Erkennung: Die LISTE der Laufwerke ist billig,
nur das Abfragen des Laufwerks ist teuer."""
import main
monkeypatch.setattr(main, "LETZTE_LAUFWERKE", [])
monkeypatch.setattr(main.device_discovery, "list_optical_devices",
lambda: [r"\.\G:"])
monkeypatch.setitem(main.DISC_CACHE, r"\.\G:", {"_laeuft": True})
geraete = main.laufwerke_notdurft()
assert geraete[0]["disc_wird_erkannt"] is True
assert geraete[0]["type"] == "unknown", "kein Typ wird erfunden"
def test_ein_fertiges_ergebnis_ueberschreibt_die_alte_marke(monkeypatch):
"""Sonst bliebe „wird erkannt" stehen, nachdem die Disc laengst da ist."""
import main
monkeypatch.setattr(main, "LETZTE_LAUFWERKE",
[{"id": "G", "name": "Laufwerk G:", "path": r"\.\G:",
"type": "bluray", "status": "ready",
"disc_wird_erkannt": True}])
monkeypatch.setitem(main.DISC_CACHE, r"\.\G:", {"title": "Evangelion 2.22"})
geraet = main.laufwerke_notdurft()[0]
assert "disc_wird_erkannt" not in geraet
assert geraet["disc"]["title"] == "Evangelion 2.22"
# ── Die Disc-Wache: kein Dauerscan (Befund 29.08.2026) ─────────────────
#
# Commander: „liest er die disc NOCHMAL ein das macht aber keinen sinn, wenn
# er sie bereits erkannt hat. Außerdem öffnen sich nun immer irgendwelche
# fenster ganz kurz im hintergrund."
#
# Beides war dieselbe Schleife: `except OSError: continue` liess
# `bekannt[pfad]` ungesetzt, der naechste Durchlauf hielt das Laufwerk fuer
# neu und stiess einen weiteren Vor-Scan an. Der haelt das Laufwerk, die
# naechste Statusabfrage scheitert — und so weiter.
def _CDS():
import main
return main.CDS_DISC_OK, main.CDS_NO_DISC, main.CDS_TRAY_OPEN
def test_erster_blick_auf_eine_liegende_disc_erkennt_sie():
import main
ok, _, _ = _CDS()
assert main.disc_entscheidung(False, None, ok) == "erststart"
def test_ein_leeres_laufwerk_beim_start_loest_nichts_aus():
import main
_, leer, _ = _CDS()
assert main.disc_entscheidung(False, None, leer) == ""
def test_dieselbe_disc_wird_NICHT_nochmal_gelesen():
"""Der Kern des Befundes."""
import main
ok, _, _ = _CDS()
assert main.disc_entscheidung(True, ok, ok) == ""
def test_ein_fehlgeschlagener_lesevorgang_startet_KEINEN_neuen_scan():
"""DER Fehler: Nach einem Fehlschlag blieb `vorher` leer. Wer das mit
noch nie gesehen" verwechselt, scannt endlos.
Ablauf wie in echt: erst erfolgreich gelesen, dann scheitert der Lesevor-
gang (makemkvcon haelt das Laufwerk), dann klappt er wieder.
"""
import main
ok, _, _ = _CDS()
# Der Fehlschlag setzt `bekannt` nicht — `vorher` ist danach None.
# `schon_gesehen` bleibt aber True, und genau daran haengt alles.
assert main.disc_entscheidung(True, None, ok) == "eingelegt", \
"eine Statusaenderung nach unbekannt->Disc ist ein Einlegen …"
# … aber NICHT ein Erststart, der ohne jede Aenderung scannt:
assert main.disc_entscheidung(True, ok, ok) == ""
def test_auswurf_wird_erkannt():
import main
ok, leer, offen = _CDS()
assert main.disc_entscheidung(True, ok, leer) == "entfernt"
assert main.disc_entscheidung(True, ok, offen) == "entfernt"
def test_ein_wackliger_zwischenstatus_wirft_die_disc_nicht_weg():
"""3 = „nicht bereit" heisst nicht „ausgeworfen". Sonst faellt der Vorrat
weg, sobald das Laufwerk kurz beschaeftigt ist."""
import main
ok, _, _ = _CDS()
assert main.disc_entscheidung(True, ok, 3) == ""
def test_die_wache_setzt_gesehen_auch_nach_einem_fehlschlag_nicht_zurueck():
"""Waechter gegen die Rueckkehr des `continue`-Fehlers."""
import inspect
import main
quelle = inspect.getsource(main.disc_watcher)
assert "gesehen" in quelle, "die Wache muss sich merken, was sie je las"
assert "disc_entscheidung(" in quelle, "die Entscheidung gehoert in die pure Funktion"
def test_schnappschuss_und_jobs_liefern_DIESELBE_jobliste():
"""Waechter gegen die zweite Fassung (Befund 29.08.2026).
Commander: Über den kompletten vorgang steht dort Restzeit wird
gemessen' aber messung wird nicht abgeschlossen."
Die Restzeit wurde nur in `/jobs` berechnet. Der SSE-Schnappschuss baute
seine Jobs mit dem nackten `_job_row_to_model` also ohne. Seit V2-3
liest die Oberflaeche aber genau diesen Schnappschuss. Die Restzeit wurde
also brav berechnet und niemandem gezeigt.
"""
import inspect
import main
quelle = inspect.getsource(main._snapshot)
assert "jobs_fuer_ui(" in quelle, "der Schnappschuss baut die Jobs selbst"
assert "_job_row_to_model(z).model_dump() for z in db.list_jobs" not in quelle
def test_die_jobliste_traegt_die_restzeit_felder():
"""Ohne die Felder im Modell schneidet FastAPI sie weg."""
import main
for feld in ("eta_sekunden", "eta_text", "can_retry", "retry_art"):
assert feld in main.Job.model_fields, feld
# ── Kein Vor-Scan waehrend eines Rips (Befund 29.08.2026) ───────────────
#
# Commander: „der Disk wird gelesen' panel braucht eeeeewig. Der Rip ist
# bereits bei 30% und er liest immernoch."
#
# Waehrend eines Rips haelt makemkvcon das Laufwerk. Ein zweites
# `makemkvcon info` daneben wartet bis zu seiner Zeitgrenze — und die Marke
# `_laeuft` blieb solange stehen, also stand auch das Panel. Es gibt keinen
# Grund, dann zu scannen: Das Laufwerk ist belegt, und WELCHE Disc drin ist,
# wissen wir — der Job laeuft ja auf ihr.
def test_kein_vorscan_solange_ein_job_auf_dem_laufwerk_laeuft(monkeypatch):
import asyncio
import main
gescannt = []
class NieBenutzt:
def scan(self, pfad):
gescannt.append(pfad)
raise AssertionError("waehrend eines Rips darf nicht gescannt werden")
monkeypatch.setattr(main, "PreScan", NieBenutzt)
monkeypatch.setattr(main.db, "has_active_job", lambda p: True)
main.DISC_CACHE.pop(r"\.\G:", None)
asyncio.run(main._auto_prescan(r"\.\G:"))
assert gescannt == []
assert r"\.\G:" not in main.DISC_CACHE, "auch keine Marke setzen"
def test_ohne_laufenden_job_wird_normal_gescannt(monkeypatch):
import asyncio
import main
class Ergebnis:
title, year, disc_type, confidence, fingerprint = "Akira", 1988, "Blu-ray", 0.9, "x"
def to_dict(self):
return {"title": "Akira"}
class Scanner:
def scan(self, pfad):
return Ergebnis()
monkeypatch.setattr(main, "PreScan", Scanner)
monkeypatch.setattr(main.db, "has_active_job", lambda p: False)
monkeypatch.setattr(main.db, "add_log", lambda *a, **k: None)
monkeypatch.setattr(main, "_duplikat_suchen", lambda f: None)
monkeypatch.setattr(main, "_auto_rip_wenn_aktiviert",
lambda p: asyncio.sleep(0))
main.DISC_CACHE.pop(r"\.\G:", None)
asyncio.run(main._auto_prescan(r"\.\G:"))
assert main.DISC_CACHE[r"\.\G:"]["title"] == "Akira"
main.DISC_CACHE.pop(r"\.\G:", None)
def test_der_job_start_raeumt_eine_haengende_erkennung_weg():
"""Eine Marke, die KURZ VOR dem Rip gesetzt wurde, bliebe sonst bis zum
Ende stehen der Scan davor haelt sie ja fest."""
import inspect
import main
quelle = inspect.getsource(main.create_job) if hasattr(main, "create_job") else ""
if not quelle:
# Der Endpunkt heisst anders — dann ueber das Modul suchen.
quelle = inspect.getsource(main)
assert 'DISC_CACHE.pop(device_path, None)' in quelle, \
"beim Job-Start muss eine haengende Erkennungs-Marke weg"
# ── Kein zweiter Rip waehrend der Kompression (Befund 29.08.2026) ───────
#
# Der Commander: „Der Rip an sich war bereits fertig, bei der komprimierung
# passiert das" — Fehlertext: „Das Öffnen der Disk schlug fehl".
#
# Ablauf dahinter: Rip fertig → Disc ausgeworfen → Status `transcoding`.
# `has_active_job` kennt nur pending/running und meldete „Laufwerk frei".
# Die Disc-Wache sah den Auswurf als Statuswechsel, die Vollautomatik startete
# einen ZWEITEN Rip — in eine Schublade, die gerade herausfuhr.
def test_automatik_startet_nicht_waehrend_der_kompression(monkeypatch):
import asyncio
import main
gestartet = []
monkeypatch.setattr(main.db, "get_settings", lambda: {"autoRipStart": True})
monkeypatch.setattr(main.db, "job_offen", lambda p: True) # Job komprimiert
monkeypatch.setattr(main.db, "has_active_job", lambda p: False) # Laufwerk frei
monkeypatch.setattr(main, "start_rip", lambda *a, **k: gestartet.append(a))
main.DISC_CACHE[r"\.\G:"] = {"title": "Akira"}
asyncio.run(main._auto_rip_wenn_aktiviert(r"\.\G:"))
assert gestartet == [], "waehrend der Kompression faengt die Automatik nichts Neues an"
def test_job_offen_zaehlt_die_kompression_mit():
from rippy.store import JOB_OFFEN
assert "transcoding" in JOB_OFFEN, "die Kompression gehoert zum Vorgang"
assert "canceling" in JOB_OFFEN, "ein Abbruch ist auch noch nicht durch"
assert "completed" not in JOB_OFFEN and "failed" not in JOB_OFFEN
def test_auswurf_bleibt_waehrend_der_kompression_erlaubt():
"""Waechter gegen einen zu breiten Riegel: `has_active_job` fragt „haelt
jemand das Laufwerk?" — waehrend der Kompression tut das niemand, die Disc
darf raus. Nur die AUTOMATIK haelt sich zurueck."""
import inspect
from rippy import store
assert "transcoding" not in inspect.getsource(store.has_active_job)
def test_laufwerk_bleibt_waehrend_eines_rips_unberuehrt(monkeypatch):
"""Befund 30.08.2026, aus dem Protokoll des Commanders:
12:49:52 bluray-Rip gestartet
12:50:09 [watcher] Laufwerk G: beantwortet keine Medien-Abfragen
12:50:12 MSG 2003 SCSI-Fehler ILLEGAL REQUEST:INVALID FIELD IN CDB
12:50:12 makemkvcon endete mit Code 11
Der Waechter fragt alle drei Sekunden ab drei CreateFileW plus IOCTLs
auf ein Geraet, das makemkvcon gerade liest. Sein Befund: das Laufwerk
hoert einfach auf zu lesen. `_auto_prescan` haelt sich seit dem
29.08.2026 an dieselbe Regel; die Laufwerksabfrage tat es nicht.
"""
import main
gefragt = []
monkeypatch.setattr(main.device_discovery, "list_optical_devices",
lambda: ["/dev/sr0"])
monkeypatch.setattr(main.device_discovery, "device_info",
lambda p: gefragt.append(p) or dict({"id": "sr0", "name": "Laufwerk", "type": "bluray", "path": "/dev/sr0", "status": "ready", "model": "X", "serial": "Y", "grund": ""}))
monkeypatch.setattr(main, "LETZTE_LAUFWERKE", [dict({"id": "sr0", "name": "Laufwerk", "type": "bluray", "path": "/dev/sr0", "status": "ready", "model": "X", "serial": "Y", "grund": ""})])
monkeypatch.setattr(main.db, "has_active_job", lambda p: True)
stand = main.laufwerke_mit_disc()
assert gefragt == [], "waehrend eines Rips darf niemand das Laufwerk anfassen"
assert stand[0]["type"] == "bluray" # letzter bekannter Stand gilt
def test_ohne_rip_wird_das_laufwerk_normal_abgefragt(monkeypatch):
"""Die Ausnahme darf nur fuer den laufenden Rip gelten."""
import main
gefragt = []
monkeypatch.setattr(main.device_discovery, "list_optical_devices",
lambda: ["/dev/sr0"])
monkeypatch.setattr(main.device_discovery, "device_info",
lambda p: gefragt.append(p) or dict({"id": "sr0", "name": "Laufwerk", "type": "bluray", "path": "/dev/sr0", "status": "ready", "model": "X", "serial": "Y", "grund": ""}))
monkeypatch.setattr(main, "LETZTE_LAUFWERKE", [dict({"id": "sr0", "name": "Laufwerk", "type": "bluray", "path": "/dev/sr0", "status": "ready", "model": "X", "serial": "Y", "grund": ""})])
monkeypatch.setattr(main.db, "has_active_job", lambda p: False)
main.laufwerke_mit_disc()
assert gefragt == ["/dev/sr0"]
-69
View File
@@ -1,69 +0,0 @@
"""Tests für auth.py: Hashing, Token-Lebenszyklus, Blacklist."""
import time
from auth import (
add_to_blacklist,
cleanup_blacklist,
create_access_token,
create_refresh_token,
decode_token,
get_password_hash,
is_access_token,
is_blacklisted,
is_refresh_token,
token_blacklist,
verify_password,
)
def test_passwort_hash_roundtrip():
hashed = get_password_hash("geheim123")
assert hashed != "geheim123"
assert verify_password("geheim123", hashed) is True
assert verify_password("falsch", hashed) is False
def test_access_token_roundtrip():
token = create_access_token({"sub": "commander"})
payload = decode_token(token)
assert payload is not None
assert payload["sub"] == "commander"
assert payload["type"] == "access"
assert is_access_token(token) is True
assert is_refresh_token(token) is False
def test_refresh_token_roundtrip():
token = create_refresh_token({"sub": "commander"})
payload = decode_token(token)
assert payload is not None
assert payload["type"] == "refresh"
assert is_refresh_token(token) is True
assert is_access_token(token) is False
def test_muell_token_gibt_none_und_false():
assert decode_token("kein.echter.token") is None
# Rückgabetyp muss bool sein, nicht None (Review-Fund 22.07.)
assert is_access_token("kein.echter.token") is False
assert is_refresh_token("kein.echter.token") is False
def test_blacklist_logout_wirkt():
token = create_access_token({"sub": "commander"})
assert is_blacklisted(token) is False
add_to_blacklist(token)
assert is_blacklisted(token) is True
def test_cleanup_entfernt_nur_abgelaufene():
"""Review-Fund 22.07.: das alte cleanup löschte ALLES — Logout war Placebo."""
frisch = create_access_token({"sub": "commander"})
add_to_blacklist(frisch)
token_blacklist["laengst-abgelaufener-token"] = time.time() - 3600
cleanup_blacklist()
assert "laengst-abgelaufener-token" not in token_blacklist
assert is_blacklisted(frisch) is True
+157
View File
@@ -0,0 +1,157 @@
"""Die Metadaten-Clients muessen sich OHNE Datenbank und OHNE Redis bauen lassen.
## Warum es diese Tests gibt (Befund 28.08.2026)
Der Commander meldete, dass eine eingelegte Blu-ray namenlos blieb und keine
Metadaten-Abfrage lief. Zwei Ursachen, beide unsichtbar:
**1. Ein Phantom-Modul.** `clients/tmdb.py`, `clients/omdb.py` und
`clients/thetvdb.py` machten im Konstruktor `from db import get_settings`.
`docker/api/db.py` gibt es seit der Zusammenlegung in V2-1 (dd1d0b7) nicht
mehr main.py schreibt seitdem `from rippy import store as db`, diese drei
Module haben es nie mitbekommen. Damit starb JEDE Metadaten-Abfrage schon
beim Erzeugen des Clients mit `ModuleNotFoundError`, auf Windows UND auf der
VM. `_auto_prescan` verschluckte es in seinem `except Exception`.
**2. Ein harter Redis-Zwang.** `cache/cache.py` sprach `redis:6379` an den
Dienstnamen aus `docker-compose.yml`. Auf einem Windows-PC gibt es kein
Redis, und jeder Zugriff endete mit `ConnectionError`. Das riss den Pre-Scan
mit.
Beide Male war der SYMPTOM sichtbar (keine Metadaten) und die URSACHE nicht.
Diese Tests machen die Ursache sichtbar: Sie bauen die Clients und benutzen
den Zwischenspeicher, ohne dass irgendetwas davon erreichbar sein muss.
"""
import pytest
def test_tmdb_client_baut_sich_ohne_datenbank():
"""Der Test, der den Phantom-Import gefangen haette."""
from clients.tmdb import TMDBClient
klient = TMDBClient()
assert hasattr(klient, "api_key")
def test_omdb_client_baut_sich_ohne_datenbank():
from clients.omdb import OMDbClient
assert OMDbClient() is not None
def test_thetvdb_client_baut_sich_ohne_datenbank():
from clients.thetvdb import TheTVDBClient
assert TheTVDBClient() is not None
def test_kein_client_importiert_das_verschwundene_db_modul():
"""Der Waechter gegen genau diesen Fehler, mechanisch.
Ein `from db import ...` faellt sonst erst auf, wenn jemand eine Disc
einlegt und dann als keine Metadaten", nicht als Import-Fehler.
"""
import os
hier = os.path.dirname(os.path.abspath(__file__))
fundstellen = []
for wurzel, ordner, dateien in os.walk(os.path.join(hier, "clients")):
ordner[:] = [o for o in ordner if o != "__pycache__"]
for name in dateien:
if not name.endswith(".py"):
continue
pfad = os.path.join(wurzel, name)
with open(pfad, encoding="utf-8") as f:
for nr, zeile in enumerate(f, 1):
if zeile.strip().startswith(("from db import", "import db")):
fundstellen.append("%s:%d" % (name, nr))
assert not fundstellen, (
"docker/api/db.py gibt es seit V2-1 nicht mehr — benutzt "
"rippy.store. Fundstellen: " + ", ".join(fundstellen))
# ── Der Zwischenspeicher ────────────────────────────────────────────────
def test_cache_ohne_redis_liefert_None_statt_zu_werfen():
"""Ein Zwischenspeicher ist eine Beschleunigung, keine Voraussetzung.
Auf einem Windows-PC gibt es kein Redis. Vorher riss jeder Zugriff den
Pre-Scan mit und die Disc blieb namenlos.
"""
from cache import cache
class ToterRedis:
def get(self, *a, **k):
raise cache.RedisError("nicht erreichbar")
def set(self, *a, **k):
raise cache.RedisError("nicht erreichbar")
def setex(self, *a, **k):
raise cache.RedisError("nicht erreichbar")
def delete(self, *a, **k):
raise cache.RedisError("nicht erreichbar")
def flushdb(self, *a, **k):
raise cache.RedisError("nicht erreichbar")
def ping(self, *a, **k):
raise cache.RedisError("nicht erreichbar")
echt = cache.redis_client
cache.redis_client = ToterRedis()
try:
assert cache.get("egal") is None
assert cache.set("egal", {"a": 1}) is False
assert cache.delete("egal") is False
assert cache.clear() is False
cache.init_cache() # darf ebenfalls nicht werfen
assert cache.zustand()["erreichbar"] is False
finally:
cache.redis_client = echt
def test_cache_meldet_den_ausfall_nur_EINMAL(capsys):
"""Eine Meldung je Anfrage waere Laerm — und bei jedem Titel-Suchlauf
kaeme sie mehrfach."""
from cache import cache
class ToterRedis:
def get(self, *a, **k):
raise cache.RedisError("weg")
echt, zustand = cache.redis_client, cache._erreichbar
cache.redis_client = ToterRedis()
cache._erreichbar = None
try:
for _ in range(5):
cache.get("x")
ausgabe = capsys.readouterr().out
assert ausgabe.count("nicht erreichbar") == 1, ausgabe
finally:
cache.redis_client, cache._erreichbar = echt, zustand
def test_ein_kaputter_eintrag_wirft_nicht():
"""Ein unlesbarer Eintrag ist kein Grund zu scheitern — dann wird die
Antwort eben frisch geholt."""
from cache import cache
class KaputterRedis:
def get(self, *a, **k):
return "{kein json"
echt = cache.redis_client
cache.redis_client = KaputterRedis()
try:
assert cache.get("x") is None
finally:
cache.redis_client = echt
@pytest.mark.parametrize("name", ["tmdb", "omdb", "jikan", "musicbrainz"])
def test_jeder_client_ist_importierbar(name):
"""Ein Tippfehler in einem Modulpfad faellt sonst erst auf, wenn jemand
eine Disc einlegt."""
__import__("clients." + name)
+229
View File
@@ -0,0 +1,229 @@
"""Tests der Restzeit-Schätzung — reine Funktionen, keine Infrastruktur.
Die Zahlen in den Szenarien sind die echten Messwerte vom 25.07.2026: Der
4K-Encode von Akira kam in 29 Minuten von 0 auf 1,44 % (an der Leseposition im
Quellstrom gemessen, `/proc/<pid>/fdinfo/`) hochgerechnet 28-55 Stunden. Genau
dieser Fall muss eine ehrliche Antwort geben, statt gleich fertig" zu behaupten.
"""
import eta
def test_ohne_genug_punkte_keine_aussage():
assert eta.restzeit_sekunden(None, 100.0) == -1
assert eta.restzeit_sekunden({"status": "transcoding", "punkte": []}, 100.0) == -1
einer = {"status": "transcoding", "punkte": [[0.0, 5]]}
assert eta.restzeit_sekunden(einer, 100.0) == -1
def test_zu_kurze_spanne_keine_aussage():
"""Zwei Punkte 10 s auseinander sagen nichts über einen Encode, der Stunden
läuft MINDEST_SPANNE_SEKUNDEN verhindert die Hochrechnung."""
reihe = {"status": "transcoding", "punkte": [[0.0, 1], [10.0, 2]]}
assert eta.restzeit_sekunden(reihe, 10.0) == -1
def test_kein_fortschritt_keine_aussage():
"""Eine Stunde ohne einen einzigen Prozentpunkt: die Rate ist unbekannt,
nicht null. Ohne diese Sperre käme eine Division durch 0."""
reihe = {"status": "transcoding", "punkte": [[0.0, 3]]}
reihe = eta.beobachtung_hinzufuegen(reihe, "transcoding", 3, 3600.0)
assert eta.restzeit_sekunden(reihe, 3600.0) == -1
def test_einfache_hochrechnung():
"""10 % in 10 Minuten → 90 % brauchen 90 Minuten."""
reihe = {"status": "ripping", "punkte": [[0.0, 0], [600.0, 10]]}
assert eta.restzeit_sekunden(reihe, 600.0) == 90 * 60
def test_der_echte_4k_fall_landet_in_der_groessenordnung_tage():
"""Gemessen: 1,44 % in 29 Minuten. Die Schätzung muss in der Größenordnung
TAGE landen das ist die Angabe, deren Fehlen den 50-Stunden-Lauf am
25.07.2026 unsichtbar machte. Die genaue Stundenzahl ist Nebensache; wer
1 Tag 23 h" liest, bricht ab, wer nichts liest, wartet."""
reihe = {"status": "transcoding", "punkte": [[0.0, 0], [29 * 60.0, 1]]}
sekunden = eta.restzeit_sekunden(reihe, 29 * 60.0)
stunden = sekunden / 3600
assert 45 < stunden < 50 # 99 % × 29 min ≈ 47,85 h
assert eta.formatiere_restzeit(sekunden) == "noch ca. 1 Tag 23 h"
# Etwas langsamer, und es heißt nur noch „mehr als 2 Tage" — bei der
# Größenordnung wäre jede Stundenangabe erfundene Genauigkeit.
langsamer = {"status": "transcoding", "punkte": [[0.0, 0], [45 * 60.0, 1]]}
assert eta.formatiere_restzeit(
eta.restzeit_sekunden(langsamer, 45 * 60.0)) == "mehr als 2 Tage"
def test_stillstand_verlaengert_die_schaetzung():
"""Kernpunkt: Bleibt der Fortschritt stehen, MUSS die Restzeit steigen —
sonst zeigt ein hängender Job stundenlang noch 5 Minuten"."""
reihe = {"status": "transcoding", "punkte": [[0.0, 0], [600.0, 50]]}
frisch = eta.restzeit_sekunden(reihe, 600.0)
# ... eine Stunde später steht der Fortschritt immer noch bei 50 %
reihe = eta.beobachtung_hinzufuegen(reihe, "transcoding", 50, 4200.0)
spaeter = eta.restzeit_sekunden(reihe, 4200.0)
assert spaeter > frisch * 5
def test_statuswechsel_verwirft_die_reihe():
"""Rip (eine Stunde) und Kompression (Tage) haben nichts miteinander zu tun.
Ohne diesen Schnitt entstünde beim Phasenwechsel eine Phantasiezahl."""
reihe = {"status": "ripping", "punkte": [[0.0, 0], [600.0, 50]]}
neu = eta.beobachtung_hinzufuegen(reihe, "transcoding", 2, 610.0)
assert neu["status"] == "transcoding"
assert neu["punkte"] == [[610.0, 2]]
assert eta.restzeit_sekunden(neu, 610.0) == -1
def test_nur_das_fenster_zaehlt():
"""Alte Punkte fliegen raus — HandBrake wird bei komplexen Szenen langsamer,
und dann lügt der Anfang der Messreihe."""
reihe = None
for i in range(20):
reihe = eta.beobachtung_hinzufuegen(reihe, "transcoding", i, float(i * 60))
assert len(reihe["punkte"]) == eta.FENSTER
assert reihe["punkte"][0][1] == 10 # die ersten zehn sind weg
def test_gleicher_fortschritt_haengt_keinen_punkt_an():
reihe = eta.beobachtung_hinzufuegen(None, "transcoding", 7, 0.0)
reihe = eta.beobachtung_hinzufuegen(reihe, "transcoding", 7, 30.0)
reihe = eta.beobachtung_hinzufuegen(reihe, "transcoding", 7, 60.0)
assert reihe["punkte"] == [[0.0, 7]]
def test_fertig_ist_null():
reihe = {"status": "transcoding", "punkte": [[0.0, 50], [600.0, 100]]}
assert eta.restzeit_sekunden(reihe, 600.0) == 0
assert eta.formatiere_restzeit(0) == "unter einer Minute"
# --- Textform ---------------------------------------------------------------
def test_textform_deckt_alle_groessenordnungen():
assert eta.formatiere_restzeit(-1) == ""
assert eta.formatiere_restzeit(None) == ""
assert eta.formatiere_restzeit(30) == "unter einer Minute"
assert eta.formatiere_restzeit(90) == "noch ca. 1 min"
assert eta.formatiere_restzeit(45 * 60) == "noch ca. 45 min"
assert eta.formatiere_restzeit(3 * 3600 + 7 * 60) == "noch ca. 3 h 07 min"
assert eta.formatiere_restzeit(30 * 3600) == "noch ca. 1 Tag 6 h"
assert eta.formatiere_restzeit(60 * 3600) == "mehr als 2 Tage"
# --- Der Weg über den Cache -------------------------------------------------
def test_aktualisiere_und_schaetze_ueber_zwei_aufrufe():
"""So läuft es live: /jobs wird alle vier Sekunden abgefragt, jeder Aufruf
schreibt die Reihe fort."""
speicher = {}
def hole(k):
return speicher.get(k)
def lege(k, wert, expire=None):
speicher[k] = wert
erst = eta.aktualisiere_und_schaetze(
"job1", "transcoding", 10, 0.0, hole, lege)
assert erst == {"sekunden": -1, "text": ""} # ein Punkt sagt nichts
dann = eta.aktualisiere_und_schaetze(
"job1", "transcoding", 20, 600.0, hole, lege)
assert dann["sekunden"] == 80 * 60
assert dann["text"] == "noch ca. 1 h 20 min"
def test_kaputter_cache_bringt_nichts_zum_absturz():
"""Redis weg → keine ETA, aber die Job-Liste muss weiter funktionieren."""
def kaputt_holen(k):
raise RuntimeError("Redis weg")
def kaputt_legen(k, wert, expire=None):
raise RuntimeError("Redis weg")
ergebnis = eta.aktualisiere_und_schaetze(
"job1", "transcoding", 10, 0.0, kaputt_holen, kaputt_legen)
assert ergebnis == {"sekunden": -1, "text": ""}
def test_fertige_und_wartende_jobs_bekommen_keine_eta():
speicher = {}
for status, progress in (("completed", 100), ("failed", 42), ("pending", 0)):
ergebnis = eta.aktualisiere_und_schaetze(
"x", status, progress, 0.0,
speicher.get, lambda k, v, expire=None: speicher.__setitem__(k, v))
assert ergebnis == {"sekunden": -1, "text": ""}
assert speicher == {} # nichts geschrieben
# ── Ohne Redis muss die Schaetzung trotzdem zustande kommen ─────────────
#
# Commander 29.08.2026: „Über den kompletten vorgang steht dort Restzeit wird
# gemessen' aber messung wird nicht abgeschlossen. Das heißt man hat kein ETA"
#
# Die Messreihe lag nur im Cache, und der Modul-Kopf sagte „Der Cache (Redis)
# ist schon da". Im Container stimmt das. Auf einem Windows-PC gab `cache_get`
# bei JEDEM Aufruf None zurueck — also jedes Mal eine frische Reihe mit EINEM
# Punkt, und `restzeit_sekunden` braucht zwei.
def _ohne_cache():
"""Ein Cache, der nichts behaelt — genau wie Redis, das es nicht gibt."""
return (lambda k: None), (lambda k, v, expire=None: False)
def test_ohne_cache_kommt_trotzdem_eine_schaetzung():
"""DER Fall des Commanders."""
import eta
eta._REIHEN.clear()
lesen, schreiben = _ohne_cache()
# Zwei Messpunkte, 120 s auseinander, 10 % Fortschritt.
eta.aktualisiere_und_schaetze("j1", "running", 10, 1000.0, lesen, schreiben)
ergebnis = eta.aktualisiere_und_schaetze("j1", "running", 20, 1120.0, lesen, schreiben)
assert ergebnis["sekunden"] > 0, "ohne Redis kam nie eine Zahl heraus"
assert ergebnis["text"], "und damit stand dauerhaft „wird gemessen"
def test_der_cache_hat_weiterhin_vorrang():
"""Wo es Redis gibt, bleibt Redis die Quelle — es ueberlebt einen
API-Neustart, das Woerterbuch im Prozess nicht."""
import eta
eta._REIHEN.clear()
aus_dem_cache = {"status": "running", "punkte": [[500.0, 5], [560.0, 15]]}
ergebnis = eta.aktualisiere_und_schaetze(
"j2", "running", 25, 620.0,
lambda k: aus_dem_cache, lambda k, v, expire=None: True)
# Drei Punkte, 120 s fuer 20 % -> die Reihe aus dem Cache wurde benutzt.
assert ergebnis["sekunden"] > 0
def test_ein_statuswechsel_beginnt_auch_ohne_cache_neu():
"""Rip und Kompression haben nichts miteinander zu tun."""
import eta
eta._REIHEN.clear()
lesen, schreiben = _ohne_cache()
eta.aktualisiere_und_schaetze("j3", "running", 50, 1000.0, lesen, schreiben)
eta.aktualisiere_und_schaetze("j3", "running", 90, 1100.0, lesen, schreiben)
neu = eta.aktualisiere_und_schaetze("j3", "transcoding", 5, 1110.0, lesen, schreiben)
assert neu["sekunden"] == -1, "nach dem Wechsel gibt es noch keine Aussage"
def test_alte_reihen_wachsen_nicht_unbegrenzt():
"""Wer einen Vorrat anlegt, raeumt ihn auch weg (AGENTS.md)."""
import eta
eta._REIHEN.clear()
lesen, schreiben = _ohne_cache()
eta.aktualisiere_und_schaetze("alt", "running", 10, 0.0, lesen, schreiben)
# Einen Tag spaeter ein anderer Job -> der alte fliegt raus.
eta.aktualisiere_und_schaetze("neu", "running", 10,
eta.REIHE_HALTBAR_SEKUNDEN + 10.0, lesen, schreiben)
assert eta.schluessel("alt") not in eta._REIHEN
assert eta.schluessel("neu") in eta._REIHEN
+78
View File
@@ -0,0 +1,78 @@
"""Was das Ähnlichkeits-Gate von Jikan wirklich durchlässt — gemessen.
Hintergrund (26.07.2026): Der SAVEPOINT v3.16 vermutete, das Gate 0,55 sei
großzügig" und Jikan stehe in der Metadaten-Kette zu früh (vor OMDb). Beides
war nachrechenbar, weil `titel_aehnlichkeit` eine reine Funktion ist und die
Rechnung ergab ein anderes Bild als die Vermutung:
- Für kurze Kinofilm-Titel ist das Gate WIRKLICH zu locker (Alien 0,83).
- Für den Fall, für den Jikan eingebaut wurde, ist es sogar zu STRENG
(Evangelion 2.22" gegen den MAL-Titel → 0,51, fällt durch).
Eine einzelne Zahl kann also beides nicht leisten. Die Folge steht in
prescan._scan_video: exakt schlägt unscharf" statt „erster gewinnt".
Die Anime-Titel unten existieren auf MyAnimeList; die Zahlen sind ausgerechnet,
nicht geschätzt. MyAnimeList selbst war bei dieser Messung nicht erreichbar
(Jikan antwortete durchweg HTTP 504) die Live-Abfrage steht damit weiter aus,
die Arithmetik des Gates ist davon aber unberührt.
"""
from clients.jikan import JikanClient, titel_aehnlichkeit
def test_kurze_kinofilm_titel_reissen_das_gate_0_55():
"""Diese vier würden ohne die Änderung Anime-Metadaten bekommen, obwohl
OMDb die Filme kennt es wurde nur nie gefragt."""
faelle = [
("Alien", "Alien 9", 0.83),
("Inception", "Deception", 0.78),
("Hero", "Heroman", 0.73),
("The Dark Knight", "Dark Knight Rises", 0.69),
]
for disc, anime, erwartet in faelle:
score = titel_aehnlichkeit(disc, anime)
assert round(score, 2) == erwartet, f"{disc} vs {anime}: {score}"
# ... liegt über dem Gate (Jikan gibt also einen Treffer zurück) ...
assert score >= JikanClient.MINDEST_AEHNLICHKEIT
# ... aber unter „sicher", darf die Kette also nicht beenden.
assert score < JikanClient.SICHER_AEHNLICHKEIT
def test_echter_treffer_gilt_weiter_als_sicher():
"""Exakter Titel → 1,0. Der Normalfall eines echten Anime-Fundes darf durch
die Verschärfung NICHT verlorengehen (AGENTS Regel B)."""
assert titel_aehnlichkeit("Monster", "Monster") == 1.0
assert titel_aehnlichkeit("Cowboy Bebop", "COWBOY BEBOP") == 1.0
# Interpunktion und Kleinschreibung sind egal — norm() wirft sie weg
assert titel_aehnlichkeit("Akira", "AKIRA!") == 1.0
for a, b in (("Monster", "Monster"), ("Akira", "AKIRA!")):
assert titel_aehnlichkeit(a, b) >= JikanClient.SICHER_AEHNLICHKEIT
def test_untertitel_zaehlt_noch_als_sicher_genug():
"""Discs tragen oft den Kurztitel, MAL den vollen. Das muss ein sicherer
Treffer bleiben, sonst hilft die Quelle bei Anime nicht mehr."""
assert titel_aehnlichkeit("Steins Gate", "Steins;Gate") >= JikanClient.SICHER_AEHNLICHKEIT
def test_der_fall_fuer_den_jikan_gebaut_wurde_faellt_heute_durch():
"""Gegenbeweis zur Vermutung „das Gate ist zu großzügig": Für Evangelion
2.22 ist es zu STRENG. Der Wert ist dokumentiert, damit ein späteres
Anheben des Gates nicht unbemerkt auch diesen Fall killt."""
score = titel_aehnlichkeit(
"Evangelion 2.22", "Evangelion: 2.0 You Can (Not) Advance"
)
assert round(score, 2) == 0.51
assert score < JikanClient.MINDEST_AEHNLICHKEIT
def test_voellig_anderer_titel_wird_verworfen():
score = titel_aehnlichkeit("Blade", "Blade of the Immortal")
assert score < JikanClient.MINDEST_AEHNLICHKEIT
def test_leere_titel_geben_null():
assert titel_aehnlichkeit("", "Monster") == 0.0
assert titel_aehnlichkeit("Monster", "") == 0.0
assert titel_aehnlichkeit("!!!", "???") == 0.0
+98
View File
@@ -0,0 +1,98 @@
"""Tests für den MakeMKV-Beta-Key-Parser (dependency-frei, nur extract_key)."""
import pytest
from makemkv_key import extract_key
# Beispiel-Key im echten Format (T- + 64 Zeichen [A-Za-z0-9_]).
_KEY = "T-BSaJ6gwgMx4eIggWkVYXiVP_6zehm7WAO9dEydvzOHFHoZ6YQ82BL5cGpYDxvyRWnS"
def test_extract_key_findet_key_im_html():
html = f'<div class="content"><pre><code>{_KEY}</code></pre></div>'
assert extract_key(html) == _KEY
def test_extract_key_ohne_key_gibt_none():
assert extract_key("<html>kein Schluessel hier</html>") is None
assert extract_key("") is None
def test_extract_key_zu_kurz_kein_treffer():
# Format ist streng T- + genau 64 Zeichen — zu kurz fällt raus.
assert extract_key("T-zukurz123") is None
def test_extract_key_liefert_ganzen_key():
# Regression: die Regex darf den Key NICHT abschneiden (Beta-Keys sind länger
# als die im Forum genannten 64 Zeichen — hier der volle Key zwischen Text).
treffer = extract_key(f"Vorher-Text {_KEY} Nachher-Text")
assert treffer == _KEY
assert treffer.startswith("T-")
# ── Der Knopf „Jetzt aus dem Forum holen" (Commander 28.08.2026) ─────────
#
# > „Bezüglich des MKV Beta Keys - der könnte theoretisch auch automatisch
# > ausgelesen werden, ich glaube das web rippy kann das"
#
# Er hatte recht: `refresh_loop()` laeuft seit jeher taeglich mit (main.py,
# Startereignis). Gemessen am 28.08.2026: Forum antwortet in 3,3 s, Key mit 62
# Zeichen. Nur war davon NICHTS zu sehen — kein Knopf, keine Meldung. Eine
# Automatik, die man nicht sehen kann, ist fuer den Benutzer keine.
@pytest.fixture
def klient():
from fastapi.testclient import TestClient
from main import app
return TestClient(app)
def test_der_knopf_holt_und_meldet_was_passiert_ist(klient, monkeypatch):
import main as api
monkeypatch.setattr("makemkv_key.fetch_current_key", lambda *a, **k: _KEY)
monkeypatch.setattr("makemkv_key._apply_key", lambda key: True)
monkeypatch.setattr(api.db, "add_log", lambda *a, **k: None)
antwort = klient.post("/system/makemkv-key/holen")
assert antwort.status_code == 200
daten = antwort.json()
assert daten["geholt"] is True
assert daten["geaendert"] is True
assert daten["endet_auf"] == _KEY[-6:]
def test_der_key_selbst_wandert_NICHT_ueber_die_leitung(klient, monkeypatch):
"""Er steht in den Einstellungen. Ein zweiter Weg zu demselben Wert ist
ein zweiter Weg, ihn zu verlieren."""
import main as api
monkeypatch.setattr("makemkv_key.fetch_current_key", lambda *a, **k: _KEY)
monkeypatch.setattr("makemkv_key._apply_key", lambda key: False)
monkeypatch.setattr(api.db, "add_log", lambda *a, **k: None)
text = klient.post("/system/makemkv-key/holen").text
assert _KEY not in text
assert _KEY[:20] not in text
def test_ein_stummes_forum_ist_ein_klarer_fehler_kein_leerer_erfolg(klient,
monkeypatch):
"""Sonst hiesse „geholt: true" mit leerem Key, es sei alles in Ordnung."""
def wirft(*a, **k):
raise OSError("Verbindung abgelehnt")
monkeypatch.setattr("makemkv_key.fetch_current_key", wirft)
antwort = klient.post("/system/makemkv-key/holen")
assert antwort.status_code == 502
assert "Forum" in antwort.json()["detail"]
def test_geaendertes_seitenformat_wird_benannt(klient, monkeypatch):
"""Kein Treffer heisst NICHT „kein Key noetig" — es heisst, die Seite hat
sich geaendert. Das muss dastehen, sonst sucht niemand danach."""
monkeypatch.setattr("makemkv_key.fetch_current_key", lambda *a, **k: None)
antwort = klient.post("/system/makemkv-key/holen")
assert antwort.status_code == 502
assert "geändert" in antwort.json()["detail"]
+385 -1
View File
@@ -1,6 +1,12 @@
"""Tests für die SMB-Fehlerübersetzung (Speicherziele → Freigaben auflisten)."""
from mounts import uebersetze_smb_fehler, validiere_name
from mounts import (
pfad_map_vorschlag,
pfad_map_zeile,
uebersetze_smb_fehler,
unc_aus_quelle,
validiere_name,
)
def test_access_denied_ohne_credentials_erklaert_gastproblem():
@@ -39,3 +45,381 @@ def test_unbekannter_fehler_bleibt_erhalten_und_gekappt():
def test_validiere_name_bleibt_streng():
assert validiere_name("nas-filme")
assert not validiere_name("NAS Filme")
def test_stale_mounts_loesen_loest_bis_nichts_mehr_geht(monkeypatch):
"""Löst gestapelte Schichten per lazy umount, bis umount nichts mehr findet
(returncode != 0), und meldet die Zahl der gelösten Schichten."""
import types
import mounts
aufrufe = []
def fake_run(cmd, **kwargs):
aufrufe.append(cmd)
rc = 0 if len(aufrufe) <= 3 else 1 # 3 Schichten lösen, dann leer
return types.SimpleNamespace(returncode=rc, stdout=b"", stderr=b"")
monkeypatch.setattr(mounts.subprocess, "run", fake_run)
assert mounts._stale_mounts_loesen("/app/media/x") == 3
assert all(cmd[:2] == ["umount", "-l"] for cmd in aufrufe)
def test_mounten_loest_stale_vor_dem_mount():
"""Regression (Vorfall 24.07.): mounten() muss Alt-Mounts LÖSEN, bevor es neu
mountet sonst stapelt es auf eine Mount-Leiche (12 Schichten, ls-Timeout)."""
import inspect
import mounts
quelle = inspect.getsource(mounts.mounten)
assert "_stale_mounts_loesen(ziel)" in quelle
# --- RIPPY_PATH_MAP: der Anschluss für externe Worker (Befund 26.07.2026) ----
def test_unc_aus_quelle_uebersetzt_cifs():
assert unc_aus_quelle("cifs", "//192.168.178.62/rippy") == "\\\\192.168.178.62\\rippy"
assert unc_aus_quelle("cifs", "//nas/medien/filme") == "\\\\nas\\medien\\filme"
def test_unc_aus_quelle_raet_bei_nfs_nicht():
"""NFS gibt "" — Windows-Schreibweise ist nicht ableitbar (AGENTS Regel D)."""
assert unc_aus_quelle("nfs", "192.168.178.62:/volume1/rippy") == ""
assert unc_aus_quelle("cifs", "") == ""
assert unc_aus_quelle("cifs", "kein-unc-pfad") == ""
def test_pfad_map_zeile_baut_was_pfad_lokal_liest(monkeypatch):
"""Der erzeugte Wert muss vom Worker gelesen werden können — genau dieses
Format erwartet worker/tasks.pfad_lokal(): Paare, getrennt durch ';'."""
import mounts
monkeypatch.setattr(mounts, "ist_gemountet", lambda name: True)
vorschlaege = pfad_map_vorschlag([
{"name": "rippy", "typ": "cifs", "quelle": "//192.168.178.62/rippy"},
])
assert pfad_map_zeile(vorschlaege) == "/app/media/rippy=\\\\192.168.178.62\\rippy"
def test_pfad_map_zeile_laesst_nfs_weg(monkeypatch):
"""Ein halbes Mapping wäre schlimmer als keines: pfad_lokal() hört beim
ersten passenden Präfix auf, ein NFS-Eintrag ohne Ziel würde also einen
Pfad 'übersetzen', den der Worker danach trotzdem nicht sieht."""
import mounts
monkeypatch.setattr(mounts, "ist_gemountet", lambda name: True)
vorschlaege = pfad_map_vorschlag([
{"name": "nfs-ziel", "typ": "nfs", "quelle": "10.0.0.9:/export"},
{"name": "rippy", "typ": "cifs", "quelle": "//nas/rippy"},
])
assert pfad_map_zeile(vorschlaege) == "/app/media/rippy=\\\\nas\\rippy"
def test_pfad_map_zeile_ohne_mounts_ist_leer():
assert pfad_map_zeile([]) == ""
assert pfad_map_zeile(None) == ""
def test_erzeugtes_mapping_uebersetzt_den_echten_fehlerfall(monkeypatch):
"""Gegenprobe mit dem Pfad, an dem es am 26.07.2026 live scheiterte.
Der Rohschnitt lag auf `/app/media/rippy/95afdc89-/title_t00.mkv`; der
Windows-Worker sah dort nichts. Mit dem hier erzeugten Mapping muss
genau dieser Pfad auf die Freigabe zeigen. `pfad_lokal` ist eine reine
Funktion im Worker hier nachgebaut aufzurufen wäre wertlos, deshalb
wird sie über den Pfad importiert.
"""
import importlib.util
import os
import mounts
monkeypatch.setattr(mounts, "ist_gemountet", lambda name: True)
mapping = pfad_map_zeile(pfad_map_vorschlag([
{"name": "rippy", "typ": "cifs", "quelle": "//192.168.178.62/rippy"},
]))
# Der Worker liegt neben der API im Repo; kein geteiltes Paket zwischen
# den Containern, deshalb per Pfad laden statt importieren.
worker_tasks = os.path.join(
# Seit V2-4 steht der Ablauf in ablauf.py; tasks.py ist nur noch
# die Celery-Huelle. Dieser Waechter muss dorthin schauen, wo der
# Code WIRKLICH steht — sonst prueft er eine leere Datei und ist
# gruen, ohne etwas zu beweisen.
os.path.dirname(os.path.dirname(os.path.abspath(__file__))), "worker", "ablauf.py"
)
spec = importlib.util.spec_from_file_location("_worker_tasks_pfad", worker_tasks)
quelltext = open(worker_tasks, encoding="utf-8").read()
assert "def pfad_lokal" in quelltext and spec is not None
# pfad_lokal ist bewusst rein und ohne Modul-Zustand — die Funktion aus dem
# Quelltext zu holen, ohne tasks.py komplett zu laden (das braucht celery,
# db, requests …), geht am ehrlichsten über exec des Funktionsblocks.
anfang = quelltext.index("def pfad_lokal")
ende = quelltext.index("\nRAW_DIR", anfang)
umgebung = {"os": os}
exec(compile(quelltext[anfang:ende], worker_tasks, "exec"), umgebung) # noqa: S102
pfad_lokal = umgebung["pfad_lokal"]
assert pfad_lokal("/app/media/rippy/95afdc89/title_t00.mkv", mapping) == (
"\\\\192.168.178.62\\rippy\\95afdc89\\title_t00.mkv"
)
# --- Der Mount kam nach einem Rebuild nicht zurueck (Befund 26.07.2026) ------
def test_mounten_geht_bei_totem_mount_den_reparatur_weg(monkeypatch):
"""Regression. Vorher galt `os.path.ismount` als Beweis, dass alles steht -
und nach `docker compose up -d --build` war die CIFS-Freigabe TOT (4 von 4
Zugriffen 10 s Timeout), der Mountpunkt aber weiter vorhanden. Damit brach
das Wiederherstellen genau dort ab, und `schreibtest()` (kein Timeout!)
blockierte den Start-Thread im Kernel.
Antwortet die Freigabe nicht, muss geloest und frisch gemountet werden -
genau wie reparieren() es tut, nur automatisch. Der Test faengt das an der
WIRKUNG: ismount darf dann gar nicht mehr gefragt werden."""
import types
import mounts
ablauf = []
monkeypatch.setattr(mounts.os, "makedirs", lambda *a, **k: None)
# pfad_lage gestubbt: Sie ruft selbst `timeout ls` auf, und hier geht es um
# die Reihenfolge von Loesen und Mounten.
monkeypatch.setattr(mounts, "pfad_lage", lambda ziel: "da")
# Vorher tot (der Vor-Check), nach dem Mount dauerhaft erreichbar. Die
# Doppelprobe wird hier gestubbt, damit der Test nicht 3 s echt wartet.
monkeypatch.setattr(mounts, "ist_erreichbar", lambda name: False)
monkeypatch.setattr(mounts, "wirklich_erreichbar", lambda name: True)
monkeypatch.setattr(mounts, "_stale_mounts_loesen",
lambda ziel: ablauf.append("loesen"))
monkeypatch.setattr(mounts, "schreibtest", lambda p: True)
def fake_run(cmd, **kwargs):
ablauf.append(cmd[0])
return types.SimpleNamespace(returncode=0, stdout="", stderr="")
monkeypatch.setattr(mounts.subprocess, "run", fake_run)
# ismount darf hier gar nicht mehr gefragt werden
monkeypatch.setattr(mounts.os.path, "ismount",
lambda p: (_ for _ in ()).throw(AssertionError("zu frueh gefragt")))
assert mounts.mounten("rippy", "cifs", "//nas/rippy") is True
assert ablauf == ["loesen", "mount"]
def test_mounten_prueft_das_ergebnis_und_versucht_es_zweimal(monkeypatch):
"""Befund 26.07.2026, dreimal reproduziert: `mount` meldete Erfolg, und die
Freigabe antwortete danach TROTZDEM nicht (eine einzige, korrekt aussehende
Schicht in /proc/mounts). Derselbe Ablauf ein zweites Mal stellte sie sofort
her. Also wird das Ergebnis geprueft statt geglaubt."""
import types
import mounts
ablauf = []
# nie erreichbar: vorher, nach Versuch 1, nach Versuch 2
monkeypatch.setattr(mounts.os, "makedirs", lambda *a, **k: None)
monkeypatch.setattr(mounts, "pfad_lage", lambda ziel: "da")
monkeypatch.setattr(mounts, "ist_erreichbar", lambda name: False)
monkeypatch.setattr(mounts, "wirklich_erreichbar", lambda name: False)
monkeypatch.setattr(mounts, "_stale_mounts_loesen", lambda ziel: None)
monkeypatch.setattr(mounts, "_lazy_umount", lambda ziel: ablauf.append("lazy"))
monkeypatch.setattr(mounts, "schreibtest", lambda p: True)
monkeypatch.setattr(
mounts.subprocess, "run",
lambda cmd, **k: (ablauf.append(cmd[0]),
types.SimpleNamespace(returncode=0, stdout="", stderr=""))[1])
import pytest
with pytest.raises(RuntimeError) as fehler:
mounts.mounten("rippy", "cifs", "//nas/rippy")
# Zweimal gemountet, dazwischen einmal geloest
assert ablauf == ["mount", "lazy", "mount"]
# Und die Meldung sagt die Wahrheit statt "eingehaengt"
assert "antwortet aber nicht" in str(fehler.value)
def test_mounten_laesst_gesunden_mount_in_ruhe(monkeypatch):
"""Antwortet die Freigabe, bleibt sie unangetastet - kein Loesen, kein
zweites Mounten (das wuerde stapeln)."""
import mounts
monkeypatch.setattr(mounts.os, "makedirs", lambda *a, **k: None)
monkeypatch.setattr(mounts, "ist_erreichbar", lambda name: True)
monkeypatch.setattr(mounts.os.path, "ismount", lambda p: True)
monkeypatch.setattr(mounts, "schreibtest", lambda p: True)
monkeypatch.setattr(mounts, "_stale_mounts_loesen",
lambda ziel: (_ for _ in ()).throw(AssertionError("nicht loesen!")))
assert mounts.mounten("rippy", "cifs", "//nas/rippy") is True
def test_wirklich_erreichbar_prueft_zweimal_mit_abstand(monkeypatch):
"""Befund 26.07.2026: Direkt nach einem frischen `mount` antwortete die
Freigabe - und Sekunden spaeter lief jeder Zugriff in die Zeitgrenze
(Wettlauf mit dem lazy umount, dessen Abbau hinter den neuen Mount fiel).
Eine EINZIGE Probe kann das nicht sehen."""
import mounts
antworten = iter([True, False]) # erst ja, dann nein
gewartet = []
monkeypatch.setattr(mounts, "ist_erreichbar", lambda name: next(antworten))
assert mounts.wirklich_erreichbar("rippy", warten=gewartet.append) is False
assert gewartet == [3]
def test_wirklich_erreichbar_bei_gesunder_freigabe(monkeypatch):
import mounts
monkeypatch.setattr(mounts, "ist_erreichbar", lambda name: True)
assert mounts.wirklich_erreichbar("rippy", warten=lambda s: None) is True
def test_wirklich_erreichbar_spart_das_warten_wenn_schon_die_erste_probe_faellt(monkeypatch):
import mounts
gewartet = []
monkeypatch.setattr(mounts, "ist_erreichbar", lambda name: False)
assert mounts.wirklich_erreichbar("rippy", warten=gewartet.append) is False
assert gewartet == [] # nicht drei Sekunden fuer nichts
def test_stale_loesen_wartet_den_lazy_abbau_ab(monkeypatch):
"""Der Grund fuer die 150 Sekunden (Befund 26.07.2026): `umount -l` ist lazy,
der Abbau passiert spaeter. Wer direkt danach mountet, riskiert, dass der
Abbau HINTER dem neuen Mount landet - der erste Reparaturversuch scheiterte
dadurch regelmaessig, und der zweite kostete 30 s Timeout."""
import time
import types
import mounts
gewartet = []
monkeypatch.setattr(time, "sleep", gewartet.append)
aufrufe = []
def fake_run(cmd, **kwargs):
aufrufe.append(cmd)
rc = 0 if len(aufrufe) <= 2 else 1
return types.SimpleNamespace(returncode=rc, stdout=b"", stderr=b"")
monkeypatch.setattr(mounts.subprocess, "run", fake_run)
assert mounts._stale_mounts_loesen("/app/media/x") == 2
assert gewartet == [1.5]
def test_stale_loesen_wartet_nicht_wenn_nichts_zu_loesen_war(monkeypatch):
"""War kein Mount da, gibt es auch keinen Abbau abzuwarten - dann darf die
Reparatur nicht kuenstlich gebremst werden."""
import time
import types
import mounts
gewartet = []
monkeypatch.setattr(time, "sleep", gewartet.append)
monkeypatch.setattr(
mounts.subprocess, "run",
lambda cmd, **k: types.SimpleNamespace(returncode=1, stdout=b"", stderr=b""))
assert mounts._stale_mounts_loesen("/app/media/x") == 0
assert gewartet == []
def test_pfad_lage_unterscheidet_da_weg_unklar(monkeypatch):
"""DER Fund vom 26.07.2026: Eine Wiederanbindung brauchte 3 min 15 s, und die
Zeit ging in die ERSTE Zeile von mounten() - `os.makedirs(ziel,
exist_ok=True)`. `exist_ok` prueft mit os.path.isdir, und ein `stat` auf einen
toten CIFS-Mount blockiert im Kernel bis zum SMB-Timeout. Deshalb wird die
Lage jetzt mit einem abbrechbaren Kind-Prozess erfragt."""
import types
import mounts
def antwort(rc):
return lambda cmd, **k: types.SimpleNamespace(returncode=rc, stdout=b"", stderr=b"")
monkeypatch.setattr(mounts.subprocess, "run", antwort(0))
assert mounts.pfad_lage("/app/media/rippy") == "da"
monkeypatch.setattr(mounts.subprocess, "run", antwort(2))
assert mounts.pfad_lage("/app/media/neu") == "weg"
# 124 = `timeout` hat abgeschossen: existiert, antwortet aber nicht
monkeypatch.setattr(mounts.subprocess, "run", antwort(124))
assert mounts.pfad_lage("/app/media/totes-nas") == "unklar"
def test_pfad_lage_nutzt_eine_zeitgrenze(monkeypatch):
import types
import mounts
gesehen = {}
monkeypatch.setattr(
mounts.subprocess, "run",
lambda cmd, **k: (gesehen.update(cmd=cmd, kw=k),
types.SimpleNamespace(returncode=0))[1])
mounts.pfad_lage("/x")
assert gesehen["cmd"][0] == "timeout"
assert gesehen["kw"]["timeout"] is not None
def test_mounten_legt_den_ordner_nur_an_wenn_er_fehlt(monkeypatch):
"""Bei "unklar" (toter Mount) darf makedirs NICHT laufen - genau dort hing es
drei Minuten. Der Ordner ist dann ohnehin da."""
import types
import mounts
angelegt = []
monkeypatch.setattr(mounts, "pfad_lage", lambda ziel: "unklar")
monkeypatch.setattr(mounts.os, "makedirs",
lambda *a, **k: angelegt.append(a[0] if a else ""))
monkeypatch.setattr(mounts, "ist_erreichbar", lambda name: False)
monkeypatch.setattr(mounts, "wirklich_erreichbar", lambda name: True)
monkeypatch.setattr(mounts, "_stale_mounts_loesen", lambda ziel: 0)
monkeypatch.setattr(mounts, "schreibtest", lambda p: True)
monkeypatch.setattr(
mounts.subprocess, "run",
lambda cmd, **k: types.SimpleNamespace(returncode=0, stdout="", stderr=""))
assert mounts.mounten("rippy", "cifs", "//nas/rippy") is True
assert angelegt == []
def test_mounten_legt_den_ordner_bei_erstinstallation_an(monkeypatch):
import types
import mounts
angelegt = []
monkeypatch.setattr(mounts, "pfad_lage", lambda ziel: "weg")
monkeypatch.setattr(mounts.os, "makedirs",
lambda *a, **k: angelegt.append(a[0] if a else ""))
monkeypatch.setattr(mounts, "ist_erreichbar", lambda name: False)
monkeypatch.setattr(mounts, "wirklich_erreichbar", lambda name: True)
monkeypatch.setattr(mounts, "_stale_mounts_loesen", lambda ziel: 0)
monkeypatch.setattr(mounts, "schreibtest", lambda p: True)
monkeypatch.setattr(
mounts.subprocess, "run",
lambda cmd, **k: types.SimpleNamespace(returncode=0, stdout="", stderr=""))
mounts.mounten("rippy", "cifs", "//nas/rippy")
assert angelegt == ["/app/media/rippy"]
def test_reparieren_fragt_ismount_nicht_mehr(monkeypatch):
"""os.path.ismount ist ein `stat` und blockiert auf einem toten CIFS-Mount.
Gebraucht wird es nicht: `umount -l` auf einen leeren Pfad kostet nichts."""
import mounts
monkeypatch.setattr(mounts.os.path, "ismount",
lambda p: (_ for _ in ()).throw(AssertionError("nicht fragen!")))
monkeypatch.setattr(mounts, "_lazy_umount", lambda ziel: None)
monkeypatch.setattr(mounts, "mounten", lambda *a, **k: True)
assert mounts.reparieren("rippy", "cifs", "//nas/rippy") is True
+82
View File
@@ -0,0 +1,82 @@
"""Welche Pfade darf die API anfassen — und wo ist „oben"?
## Warum diese Grenze verschiebbar sein muss (Befund 28.08.2026)
`MEDIA_ROOT = "/app/media"` war zugleich Vorgabe UND Pfadgrenze. Im Container
ist beides richtig. Auf dem Windows-PC des Commanders war beides falsch, und
die Folge war eine Oberflaeche, die stillschweigend nichts konnte:
* `/storage-targets` lieferte `[]` (der Ordner existiert dort nicht),
* `/browse` antwortete auf JEDEN Pfad mit 422,
* im Auswahlfeld fuer das Arbeitsverzeichnis stand genau ein Eintrag.
Sein Befund dazu: Wäre es möglich das Arbeitsverzeichnis zu ändern?
momentan geht das nicht."
Die Grenze faellt aber NICHT einfach weg. Im Container haengt die API im
Netz eine Weboberflaeche, die jeden Pfad des Wirts ausliefern kann, ist ein
Loch. Sie gilt nur dort nicht, wo Rippy den Menschen bedient, der vor dem
Rechner sitzt. Diese Tests halten beide Haelften fest.
"""
import main
# ── Die Grenze gilt, wo zugehoert wird ──────────────────────────────────
def test_im_container_gilt_die_wurzel_weiter():
"""Der Docker-Weg darf sich durch die Reparatur NICHT lockern."""
assert main.pfad_erlaubt("/app/media/movies", "/app/media", frei=False)
assert not main.pfad_erlaubt("/etc/passwd", "/app/media", frei=False)
# Der Klassiker: beginnt mit der Wurzel, liegt aber ausserhalb.
assert not main.pfad_erlaubt("/app/media-boese/x", "/app/media", frei=False)
def test_nativ_ist_auch_eine_freigabe_erlaubt():
"""Sein Ziel ist `\\\\192.168.179.62\\rippy\\movies` — das liegt unter gar
keiner lokalen Wurzel. Mit der alten Regel war es unerreichbar."""
assert main.pfad_erlaubt(r"\\192.168.179.62\rippy\movies", "/app/media", frei=True)
assert main.pfad_erlaubt(r"D:\Rippy-Arbeit", "/app/media", frei=True)
def test_ein_leerer_pfad_ist_nie_erlaubt():
"""Sonst wuerde aus einem vergessenen Feld ein Zugriff auf `/`."""
assert not main.pfad_erlaubt("", "/app/media", frei=True)
assert not main.pfad_erlaubt("", "/app/media", frei=False)
# ── Wo ist oben ─────────────────────────────────────────────────────────
def test_an_der_wurzel_ist_schluss():
"""Im Container. `None` heisst: kein Knopf „nach oben"."""
assert main.eltern_von("/app/media", "/app/media", frei=False) is None
assert main.eltern_von("/app/media/movies", "/app/media", frei=False) == "/app/media"
def test_ueber_der_laufwerkswurzel_steht_die_laufwerksliste():
"""Zwei Fallen auf einmal.
`os.path.dirname("C:\\\\")` ist wieder `"C:\\\\"` ein Knopf nach oben",
der auf denselben Ordner zeigt, sieht aus wie ein Fehler. Und ueber der
Laufwerkswurzel steht nicht *nichts*, sondern die Liste der Laufwerke:
Sonst kaeme man von `D:\\` nie zu `C:\\`, und genau dort ist Platz fuer
100 GB Rohdaten.
"""
import ntpath
import os
echt = os.path.dirname
os.path.dirname = ntpath.dirname # Windows-Pfade auch auf Linux
try:
assert main.eltern_von("C:\\", "D:\\Rippy", frei=True) == ""
assert main.eltern_von("C:\\Users\\Tobi", "D:\\Rippy", frei=True) == "C:\\Users"
finally:
os.path.dirname = echt
def test_die_wurzel_kommt_aus_dem_betrieb_und_ist_nie_leer():
"""Eine leere Wurzel wuerde jede Pruefung durchwinken."""
assert main.medien_wurzel()
def test_laufwerke_ohne_windows_sind_eine_leere_liste():
"""Auf dem Linux-Runner der Ampel darf das kein Fehler sein."""
assert isinstance(main.betrieb_laufwerke(), list)
+68
View File
@@ -0,0 +1,68 @@
"""Tests für die Phasen-Erkennung — was darf der „Neu"-Knopf anbieten?"""
import json
import phasen
def test_laufender_job_bietet_nichts():
assert phasen.retry_art({"status": "running"}) == phasen.NICHTS
assert phasen.retry_art({"status": "completed"}) == phasen.NICHTS
def test_toter_transcode_bietet_komprimieren():
job = {"status": "failed", "meta": json.dumps({"rip_fertig": True})}
assert phasen.retry_art(job) == phasen.NEU_KOMPRIMIEREN
def test_toter_rip_bietet_rippen():
"""Der Vorfall vom 26.07.2026: 5,1 GB von 40 GB. Komprimieren wäre falsch."""
job = {"status": "failed", "meta": json.dumps({"rip_fertig": False, "year": 1988})}
assert phasen.retry_art(job) == phasen.NEU_RIPPEN
def test_bestandsjob_ohne_marke_ist_unklar():
"""Jobs von VOR dieser Änderung dürfen nicht geraten werden."""
assert phasen.retry_art({"status": "failed", "meta": None}) == phasen.UNKLAR
assert phasen.retry_art({"status": "failed"}) == phasen.UNKLAR
assert phasen.retry_art(
{"status": "failed", "meta": json.dumps({"year": 1988})}
) == phasen.UNKLAR
def test_kaputtes_json_ist_unklar_statt_absturz():
"""/jobs darf an einer krummen meta-Zeile nicht scheitern."""
assert phasen.retry_art({"status": "failed", "meta": "{kein json"}) == phasen.UNKLAR
assert phasen.retry_art({"status": "failed", "meta": "[1,2]"}) == phasen.UNKLAR
assert phasen.retry_art({"status": "failed", "meta": 7}) == phasen.UNKLAR
def test_marke_wird_auch_als_dict_gelesen():
"""Der Detail-Endpunkt hat die Metadaten schon geparst."""
job = {"status": "failed", "meta": {"rip_fertig": True}}
assert phasen.retry_art(job) == phasen.NEU_KOMPRIMIEREN
def test_der_schluessel_heisst_im_worker_genauso():
"""Zwei Container, kein geteiltes Paket — die Marke muss zusammenpassen.
Ohne diese Prüfung ist ein Tippfehler in einer der beiden Dateien lautlos:
Der Worker schreibt `rip_fertig`, die API liest `ripFertig`, und JEDER Job
wäre für immer unklar". Genau diese Sorte Auseinanderdriften hat die
Zombie-Erkennung ein Release lang blind gemacht (running" vs. „ripping").
"""
import pathlib
import re
quelle = (
# Seit V2-4 steht der Ablauf in ablauf.py; tasks.py ist nur noch
# die Celery-Huelle. Dieser Waechter muss dorthin schauen, wo der
# Code WIRKLICH steht — sonst prueft er eine leere Datei und ist
# gruen, ohne etwas zu beweisen.
pathlib.Path(__file__).resolve().parents[1] / "worker" / "ablauf.py"
).read_text(encoding="utf-8")
# Der Worker schreibt die Marke über eine Konstante — deren Wert muss hier
# ankommen.
treffer = re.search(r'^RIP_FERTIG\s*=\s*"([^"]+)"', quelle, re.MULTILINE)
assert treffer, "worker/tasks.py definiert RIP_FERTIG nicht mehr"
assert treffer.group(1) == phasen.RIP_FERTIG
+174
View File
@@ -47,3 +47,177 @@ def test_omdb_jahr_parsing():
assert parse_year("20052012") == 2005 # Serien-Zeitspanne
assert parse_year("N/A") is None
assert parse_year("") is None
# --- Reihenfolge der Metadaten-Quellen: exakt schlägt unscharf ---------------
#
# Änderung vom 26.07.2026. Vorher galt der erste Jikan-Treffer über dem Gate
# 0,55 sofort als sicherer Fund, und OMDb kam nie dran — ein Kinofilm, den TMDB
# verpasst, bekam damit Anime-Metadaten. Die Messwerte dazu stehen in
# test_jikan_helpers.py („Alien" gegen „Alien 9" = 0,83).
class _StummerClient:
"""Ein Client, der auf jede Frage dasselbe antwortet — und mitzählt."""
def __init__(self, antwort=None):
self.antwort = antwort
self.aufrufe = 0
def lookup(self, *a, **k):
self.aufrufe += 1
return self.antwort
def search_movie(self, *a, **k):
return []
def search_tv(self, *a, **k):
return []
def get_movie_details(self, *a, **k):
return None
def find_by_imdb(self, *a, **k):
return None
def _scanner(monkeypatch, jikan_antwort, omdb_antwort):
"""PreScan ohne __init__ (das bräuchte DB + API-Keys), Cache stillgelegt."""
from prescan import prescan as modul
monkeypatch.setattr(modul, "get", lambda k: None)
monkeypatch.setattr(modul, "cache_set", lambda *a, **k: None)
scan = modul.PreScan.__new__(modul.PreScan)
scan.tmdb = _StummerClient()
scan.jikan = _StummerClient(jikan_antwort)
scan.omdb = _StummerClient(omdb_antwort)
return scan
def _jikan(score):
return {"type": "movie", "id": "mal-1", "title": "Alien 9",
"source": "jikan", "match_score": score}
def _omdb():
return {"type": "movie", "id": "tt0078748", "title": "Alien",
"source": "omdb", "year": 1979}
def test_unscharfer_jikan_treffer_laesst_omdb_zum_zug(monkeypatch):
"""Der eigentliche Fehler: „Alien" traf mit 0,83 auf den Anime „Alien 9",
und der Film wurde nie gesucht."""
scan = _scanner(monkeypatch, _jikan(0.83), _omdb())
ergebnis = scan._scan_video("/dev/sr0", {"title": "Alien", "disc_type": "Blu-ray"})
assert ergebnis.metadata["source"] == "omdb"
assert ergebnis.confidence == 0.8
assert scan.omdb.aufrufe > 0
def test_exakter_jikan_treffer_gewinnt_sofort(monkeypatch):
"""Der Fall, für den Jikan gebaut wurde, darf NICHT verlorengehen
(AGENTS Regel B): Bei einem sicheren Treffer wird OMDb nicht mehr gefragt."""
scan = _scanner(monkeypatch, _jikan(1.0), _omdb())
ergebnis = scan._scan_video("/dev/sr0", {"title": "Alien 9", "disc_type": "Blu-ray"})
assert ergebnis.metadata["source"] == "jikan"
assert ergebnis.confidence == 0.85
assert scan.omdb.aufrufe == 0
def test_unscharfer_jikan_treffer_bleibt_als_vorschlag(monkeypatch):
"""Hat OMDb nichts (kein Key, kein Treffer), ist der unscharfe Jikan-Treffer
besser als nichts aber er wird als VORSCHLAG ausgewiesen (0,6), nicht als
sicherer Fund."""
scan = _scanner(monkeypatch, _jikan(0.83), None)
ergebnis = scan._scan_video("/dev/sr0", {"title": "Alien", "disc_type": "Blu-ray"})
assert ergebnis.metadata["source"] == "jikan"
assert ergebnis.confidence == 0.6
def test_ohne_jede_quelle_bleibt_es_unbekannt(monkeypatch):
"""Antwortet keine Quelle, bleibt es beim Disc-Titel mit Confidence 0,3 und
`type: unknown` der Bestand, unverändert. Der Rip laeuft trotzdem, die
Datei heisst dann nur wie das Disc-Label."""
scan = _scanner(monkeypatch, None, None)
ergebnis = scan._scan_video("/dev/sr0", {"title": "Nix Da", "disc_type": "DVD"})
assert ergebnis.confidence == 0.3
assert ergebnis.metadata["type"] == "unknown"
assert ergebnis.title == "Nix Da"
# ── Was auf FREMDEN Rechnern gilt (Befund 28.08.2026) ───────────────────
#
# Der Commander: "du hast jetzt nur mein laufwerk analysiert oder? wenn ich
# rippy weitergebe wie laeuft es dort?"
#
# Berechtigt. Gemessen wurde an EINEM Laufwerk (LG BU40N) und EINER Disc
# (BD-50 mit BDMV/META). Diese Tests halten fest, was bei ANDEREN Discs
# passieren muss -- ohne dass eine davon vorhanden sein muss.
def test_bluray_ohne_metadaten_gibt_ehrlich_nichts_zurueck(tmp_path):
"""Sehr viele Blu-rays haben kein BDMV/META. Dann greift der Rueckfall
auf das Volume-Label -- aber diese Funktion darf nichts erfinden."""
from prescan.prescan import titel_aus_bdmt
(tmp_path / "BDMV" / "STREAM").mkdir(parents=True)
assert titel_aus_bdmt(str(tmp_path)) is None
def test_dvd_hat_kein_bdmv(tmp_path):
from prescan.prescan import titel_aus_bdmt
(tmp_path / "VIDEO_TS").mkdir()
assert titel_aus_bdmt(str(tmp_path)) is None
def test_bdmt_wird_gelesen_wenn_da(tmp_path):
"""Der Weg, der bei der Disc des Commanders 'Evangelion 2.22' lieferte —
hier ohne Disc nachgestellt."""
from prescan.prescan import titel_aus_bdmt
meta = tmp_path / "BDMV" / "META" / "DL"
meta.mkdir(parents=True)
(meta / "bdmt_deu.xml").write_text(
'<?xml version="1.0"?><disclib><di:discinfo>'
'<di:title><di:name>Evangelion 2.22</di:name></di:title>'
'</di:discinfo></disclib>', encoding="utf-8")
assert titel_aus_bdmt(str(tmp_path)) == "Evangelion 2.22"
def test_englisch_wird_bevorzugt(tmp_path):
"""Die APIs suchen mit englischen Titeln besser."""
from prescan.prescan import titel_aus_bdmt
meta = tmp_path / "BDMV" / "META" / "DL"
meta.mkdir(parents=True)
for datei, name in (("bdmt_deu.xml", "Deutscher Titel"),
("bdmt_eng.xml", "English Title")):
(meta / datei).write_text(
"<x><di:name>%s</di:name></x>" % name, encoding="utf-8")
assert titel_aus_bdmt(str(tmp_path)) == "English Title"
def test_prescan_ruft_makemkvcon_nicht_mehr_auf():
"""Der makemkvcon-Zweig (Titel-Quelle 3) wurde mit d3e86d2 bewusst
ENTFERNT er lief unter Windows nie (`shutil.which` findet dort nichts,
Programme liegen in Programme", nicht im PATH) und war unter Docker
doppelt zum eigentlichen Rip-Weg. Dieser Waechter passt auf, dass weder
der Aufruf noch die shutil.which-Suche zurueckkommen.
(Bis 30.08.2026 verlangte er stattdessen `werkzeug_katalog.finden`
das war die Welt VOR d3e86d2. Er laeuft nur in der CI (fcntl) und hat
die Entfernung deshalb erst dort gemeldet.)"""
import os
hier = os.path.dirname(os.path.abspath(__file__))
with open(os.path.join(hier, "prescan", "prescan.py"), encoding="utf-8") as f:
# NUR Code, keine Kommentare: Der erste Anlauf dieses Tests fiel ueber
# den eigenen Erklaertext, in dem der alte Aufruf zitiert wird. Ein
# Waechter, der an einer Erklaerung scheitert, prueft das Falsche.
code = [z for z in f if not z.strip().startswith("#")]
quelle = "".join(code)
assert "shutil.which(" not in quelle, (
"shutil.which findet unter Windows keine Programme aus 'Programme'")
assert "makemkvcon" not in quelle, (
"Der makemkvcon-Zweig im Prescan wurde mit d3e86d2 entfernt und "
"soll nicht zurueckkommen — Titel kommen aus Label/BDMV/IFO.")
+156
View File
@@ -0,0 +1,156 @@
"""Wann gilt ein TMDB-Treffer als sicher genug? — ohne Netz geprueft.
## Der Befund des Commanders (28.08.2026)
> Was ist mit dem Cover auf Windows Rippy? In der Web Version haben wir ein
> cover."
Es gab keins, weil es gar keinen Treffer gab. Der Grund war nicht Windows,
sondern eine Bedingung im Pre-Scan:
if movie.get("title", "").lower() == kandidat.lower():
An seiner Disc gemessen:
'Evangelion 2.22' 1 Treffer Evangelion: 2.0 You Can (Not) Advance
'Evangelion' 20 Treffer irgendein Evangelion
Der EINZIGE Treffer auf den vollen Disc-Titel war der richtige Film, mit
Poster und wurde verworfen, weil der Titel nicht woertlich gleich war.
## Warum die Trefferzahl und nicht die Aehnlichkeit
Evangelion 2.22" gegen „Evangelion: 2.0 You Can (Not) Advance" ergibt 0,51
Aehnlichkeit das steht als Messung schon laenger im Code und faellt durch
jedes sinnvolle Gatter. Die SPEZIFITAET der Anfrage sagt mehr: Wer auf den
vollen Disc-Titel eine Handvoll Treffer bekommt, hat gefragt wie jemand, der
weiss was er sucht. Wer 20 bekommt, hat geraten.
Diese Tests spritzen die Clients ein kein Netz, keine Schluessel, keine
Disc.
"""
import pytest
class FakeTMDB:
"""Ein TMDB, das genau die gemessenen Antworten liefert."""
def __init__(self, treffer_je_suche, details=None):
self.treffer = treffer_je_suche
self.details = details or {}
self.gefragt = []
def search_movie(self, begriff):
self.gefragt.append(begriff)
return self.treffer.get(begriff, [])
def search_tv(self, begriff):
return []
def get_movie_details(self, kennung):
return self.details.get(kennung)
def get_tv_details(self, kennung):
return None
def find_by_imdb(self, kennung):
return None
class StummerClient:
def lookup(self, *a, **k):
return None
DETAILS_2_0 = {
22843: {
"title": "Evangelion: 2.0 You Can (Not) Advance",
"release_date": "2009-06-27",
"overview": "Der Pilotin Mari gelingt es …",
"poster_path": "/hpChtHPoXGTfhphnHGXj2kGXZeH.jpg",
"backdrop_path": "/pzsVGcufDdBLmvagKyLFKaeA4O5.jpg",
"runtime": 112,
"genres": [{"name": "Animation"}],
}
}
def _prescan(tmdb):
from prescan.prescan import PreScan
p = PreScan()
p.tmdb = tmdb
p.jikan = StummerClient()
p.omdb = StummerClient()
return p
def _toc(titel):
return {"title": titel, "year": None, "tracks": [], "duration": 0,
"disc_type": "Blu-ray", "fingerprint": "TEST|1"}
def test_der_einzige_treffer_auf_den_vollen_titel_gilt():
"""DER Fall des Commanders. Vorher: kein Treffer, kein Cover, 30 %."""
tmdb = FakeTMDB(
{"Evangelion 2.22": [{"id": 22843,
"title": "Evangelion: 2.0 You Can (Not) Advance"}]},
DETAILS_2_0)
ergebnis = _prescan(tmdb)._scan_video("/dev/x", _toc("Evangelion 2.22"))
assert ergebnis.confidence == 0.8
assert ergebnis.title == "Evangelion: 2.0 You Can (Not) Advance"
assert ergebnis.year == 2009
assert ergebnis.metadata["poster_path"], "ohne poster_path gibt es kein Cover"
assert ergebnis.metadata["source"] == "tmdb"
def test_woertlich_gleicher_titel_bleibt_sicherer():
"""Ein exakter Treffer muss weiterhin hoeher stehen als ein spezifischer."""
tmdb = FakeTMDB(
{"Logan": [{"id": 22843, "title": "Logan"}]},
{22843: dict(DETAILS_2_0[22843], title="Logan")})
ergebnis = _prescan(tmdb)._scan_video("/dev/x", _toc("Logan"))
assert ergebnis.confidence == 0.95
def test_zwanzig_treffer_gelten_NICHT_als_sicher():
"""Wer 20 Treffer bekommt, hat geraten — das darf kein 80-Prozent-Fund
werden. Es bleibt beim ehrlichen Vorschlag."""
viele = [{"id": 1000 + i, "title": "Evangelion %d" % i} for i in range(20)]
tmdb = FakeTMDB({"Evangelion": viele},
{1000: dict(DETAILS_2_0[22843], title="Irgendein Evangelion")})
ergebnis = _prescan(tmdb)._scan_video("/dev/x", _toc("Evangelion"))
assert ergebnis.confidence == 0.6, "20 Treffer sind kein sicherer Fund"
def test_treffer_auf_eine_GEKUERZTE_variante_gilt_nicht_als_sicher():
"""Die Spezifitaet zaehlt nur, wenn der VOLLE Disc-Titel gefragt wurde.
Sonst wuerde Der Herr der Ringe: Die zwei Tuerme" ueber die Kuerzung
Der Herr" zu einem 80-Prozent-Fund fuer irgendetwas.
"""
tmdb = FakeTMDB(
{"Evangelion": [{"id": 22843, "title": "Neon Genesis Evangelion"}]},
{22843: dict(DETAILS_2_0[22843], title="Neon Genesis Evangelion")})
ergebnis = _prescan(tmdb)._scan_video("/dev/x", _toc("Evangelion 2.22"))
# Der volle Titel lieferte nichts, die Kuerzung schon -> nur Vorschlag.
assert ergebnis.confidence == 0.6
def test_ohne_jeden_treffer_bleibt_es_ehrlich_bei_dreissig_prozent():
ergebnis = _prescan(FakeTMDB({}))._scan_video("/dev/x", _toc("Gibt Es Nicht"))
assert ergebnis.confidence == 0.3
assert ergebnis.metadata["type"] == "unknown"
@pytest.mark.parametrize("anzahl,erwartet", [(1, 0.8), (3, 0.8), (4, 0.6)])
def test_die_schwelle_liegt_bei_drei(anzahl, erwartet):
"""Drei ist grosszuegig genug fuer Neuauflagen und Regie-Fassungen
desselben Films, aber eng genug, um Raten auszuschliessen."""
treffer = [{"id": 22843 + i, "title": "Film %d" % i} for i in range(anzahl)]
details = {22843: dict(DETAILS_2_0[22843], title="Film 0")}
tmdb = FakeTMDB({"Ein Sehr Genauer Titel": treffer}, details)
ergebnis = _prescan(tmdb)._scan_video("/dev/x", _toc("Ein Sehr Genauer Titel"))
assert ergebnis.confidence == erwartet
+212
View File
@@ -0,0 +1,212 @@
"""Tests der Preset-Auswahl — reine Funktionen, keine Infrastruktur.
Die Preset-Namen in den Testdaten sind ECHT: `HandBrakeCLI --preset-list` im
Worker-Image der Rippy-VM, 26.07.2026, HandBrake 1.6.1 (AGENTS Regel D).
Erfundene Namen hätten hier keinen Wert genau daran ist das Projekt zweimal
gescheitert.
"""
import presets
# Ausschnitt der echten Liste: die Kategorien, aus denen Rippy wählt.
PRESETS_ECHT = [
# General/
"Very Fast 2160p60 4K AV1", "Very Fast 1080p30",
"HQ 2160p60 4K HEVC Surround", "HQ 1080p30 Surround", "HQ 576p25 Surround",
"Super HQ 2160p60 4K HEVC Surround", "Super HQ 1080p30 Surround",
# Matroska/
"AV1 MKV 2160p60 4K",
"H.265 MKV 2160p60 4K", "H.265 MKV 1080p30", "H.265 MKV 576p25",
"H.265 MKV 480p30", "H.264 MKV 1080p30",
# Hardware/ — steht auch auf Maschinen OHNE Hardware-Encoder in der Liste
"AV1 QSV 2160p 4K",
"H.265 NVENC 2160p 4K", "H.265 NVENC 1080p",
"H.265 QSV 2160p 4K", "H.265 QSV 1080p",
"H.265 VCN 2160p 4K", "H.265 VCN 1080p",
"H.265 MF 2160p 4K", "H.265 MF 1080p",
]
def worker(name="w", encoders=None, simd="", presets_liste=None):
return {
"name": name,
"encoders": encoders if encoders is not None else ["cpu-x264", "cpu-x265"],
"info": {
"cpu_simd": simd,
"presets": presets_liste if presets_liste is not None else PRESETS_ECHT,
},
}
# --- Die Rippy-VM: sse4_2, 4 Kerne, kein Hardware-Encoder --------------------
def test_vm_ohne_avx2_bekommt_4k_verlustfrei():
"""Gemessen: 4K-HEVC in Software = 28-55 h auf dieser Maschine. Die
Empfehlung muss deshalb nicht komprimieren" lauten, nicht ein 4K-Preset."""
w = [worker(simd="sse4_2")]
e = presets.empfehlung("uhd", w)
assert e["preset"] == presets.PRESET_KEINE
assert "28-55 Stunden" in e["grund"]
def test_vm_ohne_avx2_bekommt_h264_fuer_bluray_und_dvd():
w = [worker(simd="sse4_2")]
assert presets.empfehlung("bluray", w)["preset"] == "HQ 1080p30 Surround"
assert presets.empfehlung("dvd", w)["preset"] == "HQ 576p25 Surround"
# --- Der PC des Commanders: avx512f, 16 Kerne, RX 9070 XT -------------------
def test_hardware_av1_wird_bevorzugt_wenn_die_familie_gemeldet_ist():
"""Commander-Vorgabe: „wenn der Worker AV1 oder noch besseres kann, immer
diesem empfehlen". QSV meldet AV1, also muss das AV1-Preset kommen."""
w = [worker(encoders=["cpu-x265", "qsv", "qsv-av1"], simd="avx512f")]
assert presets.empfehlung("uhd", w)["preset"] == "AV1 QSV 2160p 4K"
def test_amd_bekommt_das_amd_preset_nicht_das_intel():
"""Der Encoder heißt `vce`, das Preset heißt `VCN` — ohne diese Zuordnung
liefe die RX 9070 XT des Commanders unter einem Intel-Namen."""
w = [worker(encoders=["cpu-x265", "vce"], simd="avx512f")]
assert presets.empfehlung("uhd", w)["preset"] == "H.265 VCN 2160p 4K"
assert presets.empfehlung("bluray", w)["preset"] == "H.265 VCN 1080p"
def test_hardware_grund_nennt_den_nachteil_auch():
w = [worker(encoders=["vce"], simd="avx512f")]
grund = presets.empfehlung("uhd", w)["grund"]
assert "VCN" in grund
assert "sauberer" in grund # ehrlich: Software hätte etwas mehr Qualität
def test_starke_cpu_ohne_hardware_bekommt_h265():
w = [worker(encoders=["cpu-x264", "cpu-x265"], simd="avx2")]
assert presets.empfehlung("uhd", w)["preset"] == "H.265 MKV 2160p60 4K"
assert presets.empfehlung("bluray", w)["preset"] == "H.265 MKV 1080p30"
assert presets.empfehlung("dvd", w)["preset"] == "H.265 MKV 576p25"
def test_dvd_bekommt_nie_ein_hardware_preset():
"""HandBrake 1.6.1 hat keine Hardware-Presets in DVD-Auflösung — ein
erfundenes H.265 VCN 576p" würde die Kompression scheitern lassen."""
w = [worker(encoders=["vce", "qsv", "nvenc"], simd="avx512f")]
assert presets.empfehlung("dvd", w)["preset"] == "H.265 MKV 576p25"
# --- Hardware, die KEIN passendes Preset hat --------------------------------
def test_vaapi_faellt_auf_software_zurueck_statt_zu_raten():
"""HandBrake 1.6.1 liefert kein VAAPI-Preset mit. Ein VAAPI-Worker darf
deshalb keinen Hardware-Namen bekommen (AGENTS Regel D)."""
w = [worker(encoders=["cpu-x265", "vaapi"], simd="avx2")]
assert presets.empfehlung("uhd", w)["preset"] == "H.265 MKV 2160p60 4K"
def test_mf_wird_nie_empfohlen_steht_aber_zur_wahl():
"""Media-Foundation-Presets existieren, aber ob die Maschine sie nutzen
kann, ist aus der Encoder-Liste nicht ablesbar nicht empfehlen, nicht
verstecken."""
w = [worker(encoders=["cpu-x265"], simd="avx2")]
assert "MF" not in presets.empfehlung("uhd", w)["preset"]
namen = [a["name"] for a in presets.auswahl("uhd", w)]
assert "H.265 MF 2160p 4K" in namen
# --- Nur echte Namen, nie geratene ------------------------------------------
def test_unbekannte_handbrake_version_bekommt_keine_erfundene_empfehlung():
"""Meldet ein Worker nur Presets, die Rippy nicht kennt, wird ehrlich
selbst wählen" gesagt — statt einen Namen einzustellen, den dieses
HandBrake ablehnt."""
w = [worker(simd="avx2", presets_liste=["Irgendwas 4711p", "Noch was"])]
e = presets.empfehlung("uhd", w)
assert e["gefunden"] is False
assert e["preset"] == ""
assert "selbst" in e["grund"]
def test_ohne_worker_greift_der_rueckfall():
"""Kein Worker online (oder alter Worker-Stand ohne Preset-Meldung): die
Auswahl darf nicht leer sein, sonst ist die Seite unbenutzbar."""
assert presets.verfuegbare_presets([]) == list(presets.RUECKFALL_PRESETS)
assert presets.uebersicht([])["quelle"] == "rueckfall"
# ... und der Rückfall muss selbst brauchbar sein:
e = presets.empfehlung("bluray", [])
assert e["gefunden"] is True
assert e["preset"] in presets.RUECKFALL_PRESETS
def test_quelle_ist_worker_wenn_einer_meldet():
assert presets.uebersicht([worker(simd="avx2")])["quelle"] == "worker"
def test_verfuegbare_presets_vereinigt_ohne_doppelte():
a = worker("a", presets_liste=["H.265 MKV 1080p30", "HQ 1080p30 Surround"])
b = worker("b", presets_liste=["H.265 MKV 1080p30", "H.265 NVENC 1080p"])
assert presets.verfuegbare_presets([a, b]) == [
"H.265 MKV 1080p30", "HQ 1080p30 Surround", "H.265 NVENC 1080p",
]
# --- Auswahl-Listen: die 4K-Falle aus v3.12 darf nicht wiederkommen ---------
def test_4k_auswahl_zeigt_2160p_presets_zuerst():
w = [worker(simd="avx2")]
liste = presets.auswahl("uhd", w)
zuerst = [a["name"] for a in liste if not a["verkleinert"]]
assert all("2160p" in n for n in zuerst)
assert "H.265 MKV 2160p60 4K" in zuerst
def test_4k_auswahl_kennzeichnet_das_verkleinern():
"""Ein 1080p-Preset für eine 4K-Disc ist eine legitime Wahl, aber eine
BEWUSSTE in v3.12 passierte es aus Versehen und die 4K-Auflösung war weg."""
w = [worker(simd="avx2")]
verkleinert = [a["name"] for a in presets.auswahl("uhd", w) if a["verkleinert"]]
assert "H.265 MKV 1080p30" in verkleinert
assert all("1080p" in n for n in verkleinert)
def test_dvd_auswahl_nimmt_beide_pal_und_ntsc_aufloesungen():
w = [worker(simd="avx2")]
namen = [a["name"] for a in presets.auswahl("dvd", w)]
assert "H.265 MKV 576p25" in namen # PAL
assert "H.265 MKV 480p30" in namen # NTSC
assert "H.265 MKV 1080p30" not in namen
def test_bluray_auswahl_enthaelt_kein_4k():
w = [worker(simd="avx2")]
namen = [a["name"] for a in presets.auswahl("bluray", w)]
assert namen
assert not any("2160p" in n for n in namen)
# --- Erkennung der Maschinen-Stärke ----------------------------------------
def test_unbekannte_simd_stufe_gilt_nicht_als_schnell_und_nicht_als_langsam():
"""Ein Windows-Worker ohne die Erkennung aus v3.16 meldet `unbekannt`. Er
darf nichts behaupten aber auch keinen schnellen Worker ausbremsen."""
assert presets.simd_schnell([worker(simd="unbekannt")]) is False
assert presets.simd_schnell([worker(simd="unbekannt"), worker(simd="avx2")]) is True
def test_hardware_kuerzel_nur_bei_echter_meldung():
assert presets.hardware_kuerzel([worker(encoders=["cpu-x265"])]) == []
assert presets.hardware_kuerzel([worker(encoders=["nvenc", "nvenc-av1"])]) == ["NVENC"]
# Reihenfolge ist die Vorzugsreihenfolge, nicht die Meldereihenfolge
assert presets.hardware_kuerzel([worker(encoders=["vce", "qsv"])]) == ["QSV", "VCN"]
def test_uebersicht_liefert_alle_drei_disc_typen():
u = presets.uebersicht([worker(simd="avx2")])
assert set(u["typen"]) == {"uhd", "bluray", "dvd"}
for eintrag in u["typen"].values():
assert eintrag["empfehlung"]["preset"]
assert eintrag["auswahl"]
+90
View File
@@ -0,0 +1,90 @@
"""Tests für die Anfrage-Bremse.
Sie hatte bis zum 26.07.2026 keine und dabei war sie seit Wochen die Ursache
eines gemeldeten Fehlers (dieser Bereich wird oft neu geladen"): Das Limit lag
mit 100/min UNTER dem, was Rippys eigenes Dashboard verursacht, und weil hinter
dem nginx alle Clients dieselbe Adresse hatten, galt es auch noch gemeinsam.
"""
import ratelimit
def test_hinter_dem_proxy_zaehlt_der_echte_client():
"""Der ganze Grund für den Fehler: ein Eimer für alle."""
assert ratelimit.client_kennung("172.19.0.6", "192.168.178.20") == "192.168.178.20"
assert ratelimit.client_kennung("172.19.0.6", "192.168.178.99") == "192.168.178.99"
# Zwei Clients hinter demselben Proxy sind zwei Eimer.
assert (
ratelimit.client_kennung("172.19.0.6", "192.168.178.20")
!= ratelimit.client_kennung("172.19.0.6", "192.168.178.99")
)
def test_ohne_kopfzeile_gilt_der_direkte_absender():
assert ratelimit.client_kennung("192.168.178.20", None) == "192.168.178.20"
assert ratelimit.client_kennung("192.168.178.20", "") == "192.168.178.20"
def test_erste_adresse_der_kette_gewinnt():
"""X-Forwarded-For kann eine Liste sein — der Ursprung steht vorn."""
assert ratelimit.client_kennung(
"172.19.0.6", "192.168.178.20, 172.19.0.6"
) == "192.168.178.20"
def test_muell_in_der_kopfzeile_wird_ignoriert():
"""Sonst könnte ein Tippfehler beliebig viele Eimer aufmachen."""
assert ratelimit.client_kennung("172.19.0.6", "nicht-ip") == "172.19.0.6"
assert ratelimit.client_kennung("172.19.0.6", "<script>") == "172.19.0.6"
def test_oeffentliche_adresse_in_der_kopfzeile_wird_nicht_geglaubt():
"""Heimnetz-only: Was nicht aus dem privaten Netz kommt, zählt nicht.
Keine Härtung gegen Angreifer (dafür ist Rippy die falsche Stelle), aber die
Bremse soll sich nicht mit einer beliebigen Kopfzeile aushebeln lassen.
"""
assert ratelimit.client_kennung("172.19.0.6", "8.8.8.8") == "172.19.0.6"
def test_ohne_jede_angabe_bleibt_ein_eimer_uebrig():
assert ratelimit.client_kennung("", None) == "unbekannt"
def test_limit_greift_erst_nach_der_grenze():
ratelimit.reset_rate_limit("test-a")
for i in range(10):
assert ratelimit.check_rate_limit("test-a", max_requests=10), f"Anfrage {i}"
assert not ratelimit.check_rate_limit("test-a", max_requests=10)
def test_eimer_sind_getrennt():
ratelimit.reset_rate_limit("test-b")
ratelimit.reset_rate_limit("test-c")
for _ in range(5):
ratelimit.check_rate_limit("test-b", max_requests=5)
assert not ratelimit.check_rate_limit("test-b", max_requests=5)
assert ratelimit.check_rate_limit("test-c", max_requests=5)
def test_grenze_deckt_die_eigene_last_ab():
"""Die Bremse darf Rippy nicht selbst ausbremsen.
Nachgerechnet aus den Taktgebern im UI (Zahlen im Kopf von ratelimit.py):
Dashboard 75/min + Log-Kasten 24/min + Laufwerke 12/min + Tray 12/min je
Worker = 123/min für EINEN Tab. Mit 100 war das garantiert rot. Diese Prüfung
hält fest, dass die Grenze mit Luft darüber liegt wer den Wert senkt, muss
hier vorbei.
"""
eigene_last_pro_tab = 75 + 24 + 12
tray_pro_worker = 12
assert ratelimit.MAX_REQUESTS_PER_MINUTE >= 2 * eigene_last_pro_tab + 3 * tray_pro_worker
def test_meldung_wird_gedrosselt():
"""Ein Amok-Skript darf nicht das Log-Fenster fluten."""
ratelimit._letzte_meldung.pop("test-d", None)
assert ratelimit.darf_melden("test-d", jetzt=1000.0)
assert not ratelimit.darf_melden("test-d", jetzt=1001.0)
assert not ratelimit.darf_melden("test-d", jetzt=1059.0)
assert ratelimit.darf_melden("test-d", jetzt=1061.0)
+306
View File
@@ -0,0 +1,306 @@
"""Tests der Rohdaten-Suche — mit dem echten Fall, der sie nötig gemacht hat.
Job `95afdc89` (26.07.2026, an der laufenden Instanz gemessen): 79,6 GB
Rohschnitt unter /app/media/rippy/<id>, Einstellung `workDir` leer, `can_retry`
= false. Der Knopf Neu komprimieren" fehlte, obwohl die Datei intakt war.
"""
import rohdaten
JOB = "95afdc89-2426-4d44-829e-ad6ce1411905"
def test_der_echte_fall_wird_gefunden():
"""workDir ist LEER (so stand es live) und der Rohschnitt liegt trotzdem auf
der NAS weil beim Start eine Wahl nur für diesen Rip getroffen wurde."""
orte = rohdaten.kandidaten(JOB, "", ["movies", "music", "rippy", "series"])
assert f"/app/media/rippy/{JOB}" in orte
# Der Container-Standard bleibt der erste Kandidat (schnellster Treffer)
assert orte[0] == f"/app/temp/raw/{JOB}"
# Die Wurzeln des CONTAINER-Betriebs, eingespritzt. Ohne sie hingen diese
# Tests am laufenden Rechner: Unter Windows liefert `wurzeln()` echte
# Windows-Pfade, und die Erwartungen hier gelten dort nicht (am 29.08.2026
# prompt sieben Tests rot geworden).
CONTAINER = ("/app/temp/raw", "/app/media", False)
def test_suche_liefert_nur_was_existiert():
vorhanden = {f"/app/media/rippy/{JOB}"}
gefunden = rohdaten.suche(
JOB, "",
listdir=lambda p: ["movies", "rippy"],
isdir=lambda p: p in vorhanden,
orte_wurzeln=CONTAINER)
assert gefunden == [f"/app/media/rippy/{JOB}"]
def test_eingestelltes_arbeitsverzeichnis_kommt_vor_den_zielen():
orte = rohdaten.kandidaten(JOB, "/app/media/rippy", ["movies", "rippy"])
assert orte[1] == f"/app/media/rippy/{JOB}"
# ... und taucht nicht doppelt auf, obwohl „rippy" auch Ablageziel ist
assert orte.count(f"/app/media/rippy/{JOB}") == 1
def test_arbeitsverzeichnis_ausserhalb_media_wird_ignoriert():
"""Nur /app/media ist erlaubt (so entscheidet _arbeitsverzeichnis im
Worker) ein Pfad daneben darf hier nicht durchrutschen."""
orte = rohdaten.kandidaten(JOB, "/etc", [])
assert orte == [f"/app/temp/raw/{JOB}"]
# Der Klassiker: ein Pfad, der nur mit dem Präfix ANFÄNGT
orte = rohdaten.kandidaten(JOB, "/app/media-boese", [])
assert orte == [f"/app/temp/raw/{JOB}"]
def test_media_root_selbst_ist_erlaubt():
orte = rohdaten.kandidaten(JOB, "/app/media", [])
assert f"/app/media/{JOB}" in orte
#: Die Wurzeln eines NATIVEN Betriebs (Windows, freies Blättern) —
#: Gegenstück zu CONTAINER weiter oben.
NATIV = ("C:\\Rippy\\_arbeit", "C:\\Rippy", True)
def test_laufwerks_wurzel_bleibt_absolut():
"""Der Fall des Commanders (30.08.2026): Arbeitsordner F: — die Wurzel.
Hier wurde der Schluss-Trenner abgestreift und mit dem Rest dann auch
VERBUNDEN. Ein blosses "F:" ist unter Windows aber der AKTUELLE Ordner
auf Laufwerk F, nicht dessen Wurzel die Suche sah damit an einer
ganz anderen Stelle nach. Ergebnis: 16,5 GB Rohschnitt unsichtbar, und
der Wiederholen-Dialog bot nur "Neu rippen" an: Stunden am
beschädigten Datenträger für etwas, das schon dalag.
"""
orte = rohdaten.kandidaten(JOB, "F:\\", [], NATIV)
assert "F:" + chr(92) + JOB in orte
assert "F:" + JOB not in orte
# Ohne Schluss-Trenner muss dasselbe herauskommen
assert rohdaten.kandidaten(JOB, "F:\\Roh\\", [], NATIV)[-1] == (
"F:" + chr(92) + "Roh" + chr(92) + JOB)
def test_media_root_mit_schluss_trenner_zaehlt_auch():
"""/app/media/ und /app/media sind derselbe Ort — der Vergleich darf
nicht am Trenner scheitern."""
orte = rohdaten.kandidaten(JOB, "/app/media/", [], CONTAINER)
assert f"/app/media/{JOB}" in orte
def test_ohne_job_id_nichts():
assert rohdaten.kandidaten("", "/app/media", ["x"]) == []
def test_kaputter_mount_reisst_die_suche_nicht_mit():
"""Ein toter CIFS-Mount lässt isdir mit OSError fliegen. Das darf die
Job-Liste nicht mitnehmen (Befund 24.07. bei /storage-targets)."""
def isdir_kaputt(p):
if "totes-nas" in p:
raise OSError("Stale file handle")
return p == f"/app/temp/raw/{JOB}"
gefunden = rohdaten.suche(
JOB, "", listdir=lambda p: ["totes-nas", "movies"], isdir=isdir_kaputt, orte_wurzeln=CONTAINER)
assert gefunden == [f"/app/temp/raw/{JOB}"]
def test_listdir_kaputt_faellt_auf_den_standard_zurueck():
def listdir_kaputt(p):
raise OSError("kein /app/media")
gefunden = rohdaten.suche(
JOB, "", listdir=listdir_kaputt, isdir=lambda p: True, orte_wurzeln=CONTAINER)
assert gefunden == [f"/app/temp/raw/{JOB}"]
# --- Größe ------------------------------------------------------------------
def test_groesse_zaehlt_nur_dateien():
dateien = {
f"/app/media/rippy/{JOB}/title_t00.mkv": 79604951639,
f"/app/media/rippy/{JOB}/title_t01.mkv": 1000,
}
bytes_gesamt, anzahl = rohdaten.groesse(
[f"/app/media/rippy/{JOB}"],
listdir=lambda p: ["title_t00.mkv", "title_t01.mkv", "unterordner"],
isfile=lambda p: p in dateien,
getsize=lambda p: dateien[p],
)
# Die echte Größe des Akira-Rohschnitts, plus eine zweite Datei
assert bytes_gesamt == 79604952639
assert anzahl == 2
assert round(bytes_gesamt / 1024**3, 1) == 74.1
def test_groesse_ohne_pfade_ist_null():
assert rohdaten.groesse([], lambda p: [], lambda p: True, lambda p: 1) == (0, 0)
assert rohdaten.groesse(None, lambda p: [], lambda p: True, lambda p: 1) == (0, 0)
def test_groesse_ueberspringt_unlesbares():
def getsize_kaputt(p):
raise OSError("weg")
bytes_gesamt, anzahl = rohdaten.groesse(
["/x"], lambda p: ["a.mkv"], lambda p: True, getsize_kaputt)
assert (bytes_gesamt, anzahl) == (0, 0)
# --- Die harte Zeitgrenze: ein haengender Mount darf nichts toeten -----------
#
# Am 26.07.2026 hing os.path.isdir an der CIFS-Freigabe im
# KERNEL (Prozess-Zustand D). asyncio.to_thread kam nie zurueck, die
# Hintergrund-Schleife erreichte ihr sleep nie und war dauerhaft tot.
class _Lauf:
"""Merkt sich das Kommando und liefert einen gesetzten Rueckgabewert."""
def __init__(self, rc=0, wirf=None):
self.rc, self.wirf, self.cmd = rc, wirf, None
def __call__(self, cmd, **kwargs):
self.cmd = cmd
if self.wirf:
raise self.wirf
class E:
returncode = self.rc
return E()
def test_verzeichnis_da_nutzt_timeout_und_ls():
"""Ein Kind-PROZESS laesst sich abbrechen, ein im Kernel haengender Thread
nicht. Deshalb genau dieses Kommando - wie mounts.ist_erreichbar."""
lauf = _Lauf(rc=0)
assert rohdaten.verzeichnis_da("/app/media/rippy/x", lauf) is True
assert lauf.cmd[0] == "timeout"
assert lauf.cmd[1] == str(rohdaten.PRUEF_TIMEOUT_SEKUNDEN)
assert lauf.cmd[2:] == ["ls", "-d", "/app/media/rippy/x"]
def test_verzeichnis_da_nicht_vorhanden():
assert rohdaten.verzeichnis_da("/gibt/es/nicht", _Lauf(rc=2)) is False
def test_verzeichnis_in_der_zeitgrenze_gilt_als_nicht_da():
"""`timeout` beendet ls mit 124. Ein Ort, den man nicht in Sekunden ansehen
kann, ist fuer einen Rip ohnehin unbrauchbar."""
assert rohdaten.verzeichnis_da("/app/media/totes-nas/x", _Lauf(rc=124)) is False
def test_verzeichnis_da_ueberlebt_kaputte_umgebung():
import subprocess as sp
assert rohdaten.verzeichnis_da("/x", _Lauf(wirf=OSError("kein timeout"))) is False
assert rohdaten.verzeichnis_da(
"/x", _Lauf(wirf=sp.TimeoutExpired("ls", 6))) is False
assert rohdaten.verzeichnis_da("", _Lauf(rc=0)) is False
def test_suche_mit_der_zeitgrenze_findet_den_echten_fall():
"""Zusammenspiel: os.listdir fuer /app/media (lokal, sicher),
verzeichnis_da fuer die Kandidaten (koennen im Netz liegen)."""
def laufen(cmd, **kwargs):
pfad = cmd[-1]
class E:
returncode = 0 if pfad == f"/app/media/rippy/{JOB}" else 1
return E()
gefunden = rohdaten.suche(
JOB, "",
listdir=lambda p: ["bluray", "movies", "rippy"],
isdir=lambda p: rohdaten.verzeichnis_da(p, laufen),
orte_wurzeln=CONTAINER)
assert gefunden == [f"/app/media/rippy/{JOB}"]
# --- Drei Antworten: "konnte nicht nachsehen" ist nicht "ist weg" ------------
def test_pruefen_unterscheidet_drei_faelle():
assert rohdaten.pruefen("/x", _Lauf(rc=0)) == "da"
assert rohdaten.pruefen("/x", _Lauf(rc=2)) == "weg"
# 124 = `timeout` hat das Kind abgeschossen (coreutils) -> nicht angesehen
assert rohdaten.pruefen("/x", _Lauf(rc=124)) == "unklar"
assert rohdaten.pruefen("/x", _Lauf(wirf=OSError("kein timeout"))) == "unklar"
assert rohdaten.pruefen("", _Lauf(rc=0)) == "weg"
def test_verzeichnis_da_bleibt_streng():
"""Wer Ja/Nein braucht, bekommt im Zweifel Nein."""
assert rohdaten.verzeichnis_da("/x", _Lauf(rc=0)) is True
assert rohdaten.verzeichnis_da("/x", _Lauf(rc=124)) is False
def test_suche_mit_status_meldet_ungepruefte_orte():
"""Der echte Fall: Die Freigabe antwortet nicht, der lokale Ort ist leer.
Ein leeres Ergebnis darf dann NICHT als "nichts da" gelten."""
def pruefe(pfad):
return "unklar" if pfad.startswith("/app/media/rippy/") else "weg"
e = rohdaten.suche_mit_status(
JOB, "", listdir=lambda p: ["rippy"], pruefer=pruefe, orte_wurzeln=CONTAINER)
assert e == {"pfade": [], "unklar": True}
def test_suche_mit_status_ohne_zweifel():
def pruefe(pfad):
return "da" if pfad == f"/app/media/rippy/{JOB}" else "weg"
e = rohdaten.suche_mit_status(
JOB, "", listdir=lambda p: ["movies", "rippy"], pruefer=pruefe, orte_wurzeln=CONTAINER)
assert e == {"pfade": [f"/app/media/rippy/{JOB}"], "unklar": False}
def test_suche_mit_status_findet_trotz_unklarem_anderen_ort():
"""Ein Treffer bleibt ein Treffer, auch wenn ein anderer Ort schweigt."""
def pruefe(pfad):
if pfad == f"/app/media/rippy/{JOB}":
return "da"
return "unklar" if "totes-nas" in pfad else "weg"
e = rohdaten.suche_mit_status(
JOB, "", listdir=lambda p: ["rippy", "totes-nas"], pruefer=pruefe, orte_wurzeln=CONTAINER)
assert e["pfade"] == [f"/app/media/rippy/{JOB}"]
assert e["unklar"] is True
def test_nativ_wird_kein_prozess_gestartet(monkeypatch, tmp_path):
"""Befund 30.08.2026, an der laufenden Instanz beobachtet:
14:54:40 timeout.exe timeout 4 ls -d C:...d7ee6c06-...
14:54:40 WindowsTerminal.exe
Der Commander sah Fenster aufblitzen. `timeout` und `ls` sind
Linux-Befehle; die Windows-eigene timeout.exe kennt weder `ls` noch
`-d`, braucht aber eine Konsole. Dreifach falsch: ein Fenster je
Durchlauf, ein Prozess fuer nichts, und Rueckgabewert ungleich 0 also
die Antwort weg fuer JEDES Verzeichnis.
"""
gestartet = []
monkeypatch.setattr(rohdaten, "nativ_nachsehen", lambda: True)
monkeypatch.setattr(rohdaten.subprocess, "run",
lambda *a, **k: gestartet.append(a))
assert rohdaten.pruefen(str(tmp_path)) == "da"
assert rohdaten.pruefen(str(tmp_path / "gibt-es-nicht")) == "weg"
assert gestartet == [], "es darf kein Prozess gestartet werden"
def test_im_container_bleibt_der_kindprozess(monkeypatch):
"""Dort ist der Umweg richtig: os.path.isdir kann an einem toten
CIFS-Mount im Kernel haengen (Begruendung in verzeichnis_da)."""
monkeypatch.setattr(rohdaten, "nativ_nachsehen", lambda: False)
aufrufe = []
class Antwort:
returncode = 0
monkeypatch.setattr(rohdaten.subprocess, "run",
lambda *a, **k: aufrufe.append(a[0]) or Antwort())
assert rohdaten.pruefen("/app/media/x") == "da"
assert aufrufe[0][0] == "timeout"
assert aufrufe[0][-1] == "/app/media/x"
+20
View File
@@ -0,0 +1,20 @@
"""Tests für die TMDB-Key-Erkennung (v3-Schlüssel vs. v4-Token).
Befund 24.07.: Der Client konnte nur v4-Bearer mit dem üblichen 32-Hex-
v3-Key war jede Anfrage 401 und TMDB fiel still aus (nur OMDb-Treffer).
"""
from clients.tmdb import ist_v4_token
def test_v4_token_wird_erkannt():
assert ist_v4_token("eyJhbGciOiJIUzI1NiJ9.irgendwas.signatur") is True
def test_v3_hex_key_ist_kein_v4_token():
assert ist_v4_token("842abc0123456789842abc0123456789") is False
def test_leer_ist_kein_token():
assert ist_v4_token("") is False
assert ist_v4_token(None) is False
-6
View File
@@ -1,6 +0,0 @@
FROM postgres:16
COPY init.sql /docker-entrypoint-initdb.d/
EXPOSE 5432
-3
View File
@@ -1,3 +0,0 @@
CREATE DATABASE rippy;
CREATE USER rippy WITH PASSWORD 'rippy123';
GRANT ALL PRIVILEGES ON DATABASE rippy TO rippy;
-5
View File
@@ -1,5 +0,0 @@
FROM redis:7-alpine
COPY redis.conf /usr/local/etc/redis/redis.conf
CMD ["redis-server", "/usr/local/etc/redis/redis.conf"]
-6
View File
@@ -1,6 +0,0 @@
appendonly yes
appendfsync everysec
timeout 0
tcp-keepalive 300
loglevel notice
databases 16
+15
View File
@@ -14,9 +14,24 @@ server {
proxy_pass http://api:8000/;
proxy_http_version 1.1;
proxy_set_header Host $host;
# ⚠️ OHNE DIESE ZEILEN TEILEN SICH ALLE CLIENTS EIN RATE-LIMIT
#
# Die API begrenzt Anfragen pro Client-IP (ratelimit.py). Ohne
# weitergegebene Adresse sah sie als Absender immer DIESEN Container
# Browser, zweiter Tab und der Windows-Tray landeten also in einem
# gemeinsamen Eimer. Gemessen am 26.07.2026: 812 von 876 Anfragen kamen
# scheinbar von 172.19.0.6, und das UI bekam laufend HTTP 429.
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# SSE (/api/stream/jobs) braucht ungepufferte, lange Verbindungen:
proxy_buffering off;
proxy_read_timeout 3600s;
# Der nginx-Default ist 1 MB. Eine echte KEYDB.cfg ist deutlich groesser,
# der Upload ueber POST /api/system/keydb wuerde also schon hier mit
# 413 abgewiesen die API bekaeme die Anfrage nie zu sehen und das UI
# haette keinen detail-Text, den es anzeigen koennte. 64m entspricht dem
# Limit MAX_KEYDB_BYTES in makemkv_daten.py.
client_max_body_size 64m;
}
location / {
+186 -86
View File
@@ -1,99 +1,199 @@
import { useState, useEffect } from 'react'
import { LayoutDashboard, Disc, Settings, Sun, Moon, Terminal } from 'lucide-react'
import { api } from './lib/api'
import { useDarkMode } from './context/ThemeContext'
import { useEffect, useState } from 'react'
import { LayoutDashboard, BookOpen, FileText, Settings as SettingsIcon } from 'lucide-react'
import Dashboard from './pages/Dashboard'
import MetadataPreview from './pages/MetadataPreview'
import SettingsPage from './pages/Settings'
import LogsPage from './pages/Logs'
import AnleitungPage from './pages/Anleitung'
import FirstRunWizard from './components/FirstRunWizard'
import { api } from './lib/api'
import { EventStreamProvider, useStrom } from './lib/useEventStream'
import { BetriebProvider } from './lib/useBetrieb'
import { Fehlergrenze } from './components/Fehlergrenze'
type Page = 'dashboard' | 'metadata' | 'settings' | 'logs'
function App() {
const [page, setPage] = useState<Page>('dashboard')
const [setupDone, setSetupDone] = useState<boolean | null>(null)
const { theme, toggleTheme } = useDarkMode()
useEffect(() => {
api.get('/setup')
.then(r => setSetupDone(!!r.data.done))
.catch(() => setSetupDone(true)) // API nicht erreichbar → kein Wizard-Zwang
}, [])
if (setupDone === false) {
return <FirstRunWizard onDone={() => setSetupDone(true)} />
}
const navItems = [
{ id: 'dashboard', label: 'Dashboard', icon: LayoutDashboard },
{ id: 'metadata', label: 'Metadaten', icon: Disc },
{ id: 'logs', label: 'Logs', icon: Terminal },
{ id: 'settings', label: 'Einstellungen', icon: Settings },
]
type Page = 'dashboard' | 'anleitung' | 'logs' | 'settings'
/**
* Zeigt, ob der Live-Strom steht.
*
* Hier stand bis V2-3 ein fest verdrahtetes ONLINE" mit pulsierendem Punkt
* es leuchtete auch dann gruen, wenn die API tot war. Genau die Sorte
* Placebo-Anzeige, die in Etappe 19 schon einmal aufgeraeumt wurde
* (Fortschritt log, Auswurf tat nichts, Encoder wurden behauptet statt
* gemessen"). Jetzt sagt sie die Wahrheit.
*/
function VerbindungsAnzeige() {
const { verbunden, zuletzt } = useStrom()
if (verbunden) {
return (
<div className="min-h-screen bg-white text-slate-900 dark:bg-slate-900 dark:text-slate-100 font-sans transition-colors duration-300">
<div className="flex h-screen overflow-hidden">
{/* Sidebar */}
<aside className="w-64 bg-slate-900 text-slate-100 flex flex-col">
<div className="p-6">
<div className="flex items-center gap-3">
<div className="p-2 bg-gradient-to-br from-indigo-500 to-purple-600 rounded-xl">
<Disc size={28} className="text-white" />
<div className="flex items-center gap-2 text-xs font-mono text-emerald-400 bg-emerald-500/10 px-3 py-1.5 rounded-xl border border-emerald-500/20">
<span className="w-2 h-2 rounded-full bg-emerald-400 animate-pulse" />
<span>LIVE</span>
</div>
<div>
<h1 className="text-xl font-bold tracking-tight">Rippy</h1>
<p className="text-xs text-slate-400 dark:text-slate-500">Automated Ripping</p>
</div>
</div>
</div>
<button
onClick={toggleTheme}
className="mx-3 flex items-center justify-center gap-2 px-3 py-2 rounded-lg bg-slate-800/50 text-slate-400 hover:bg-slate-700 hover:text-white transition-all duration-200"
title={theme === 'dark' ? 'Light Mode' : 'Light Mode'}
)
}
return (
<div
className="flex items-center gap-2 text-xs font-mono text-amber-400 bg-amber-500/10 px-3 py-1.5 rounded-xl border border-amber-500/30"
title={
zuletzt
? `Letzte Meldung um ${zuletzt.toLocaleTimeString()}. Die Anzeige zeigt diesen Stand, bis die Verbindung zurueck ist.`
: 'Noch keine Verbindung zum Server.'
}
>
{theme === 'dark' ? <Sun size={18} /> : <Moon size={18} />}
</button>
<nav className="flex-1 px-3 py-2 space-y-1">
{navItems.map((item) => (
<button
key={item.id}
onClick={() => setPage(item.id as Page)}
className={`w-full flex items-center gap-3 px-3 py-2.5 rounded-lg transition-all duration-200 ${
page === item.id
? 'bg-indigo-600 text-white shadow-lg shadow-indigo-500/30'
: 'text-slate-400 hover:bg-slate-800 hover:text-white'
}`}
>
<item.icon size={20} />
<span className="font-medium">{item.label}</span>
</button>
))}
</nav>
{/* Abmelden-Knopf entfernt (23.07.): es gibt (noch) keinen
Login-Flow im UI ein toter Knopf gaukelt nur einen vor. */}
<footer className="px-4 py-4 text-center text-xs text-slate-500 border-t border-slate-800">
Created with <span className="text-rose-400"></span> by LucyAI, Claude and KrBrZ
</footer>
</aside>
{/* Main Content */}
<main className="flex-1 overflow-auto bg-slate-50 dark:bg-slate-950">
<div className="max-w-7xl mx-auto p-6">
{page === 'dashboard' && <Dashboard />}
{page === 'metadata' && <MetadataPreview />}
{page === 'logs' && <LogsPage />}
{page === 'settings' && <SettingsPage />}
</div>
</main>
</div>
<span className="w-2 h-2 rounded-full bg-amber-400" />
<span>VERBINDUNG WEG</span>
</div>
)
}
export default App
function AppInhalt() {
const [currentPage, setCurrentPage] = useState<Page>('dashboard')
// First-Run: solange der Einrichtungs-Assistent nicht abgeschlossen ist, zeigen wir
// ihn statt des Dashboards. null = /setup noch nicht geprüft (kein Aufblitzen).
const [setupDone, setSetupDone] = useState<boolean | null>(null)
/*
* Ein fehlgeschlagener Abruf ist KEINE Aussage über die Einrichtung.
*
* Hier stand `.catch(() => setSetupDone(true))` mit der Begründung
* API/Setup nicht erreichbar nicht blockieren". Die Folge hat der
* Commander am 28.08.2026 gemeldet: **Nach einer frischen Installation
* fehlte der Ersteinrichtungs-Assistent.**
*
* Und zwar zwangsläufig: Das Fenster geht unmittelbar nach dem Setup auf,
* der Dienst braucht ein bis zwei Sekunden bis zur ersten Antwort der
* erste Abruf scheitert also fast immer. Aus ich konnte nicht nachsehen"
* wurde ist schon erledigt", und der Assistent war für immer weg.
*
* Dasselbe Prinzip steht nebenan in `useEventStream.tsx`: Wer nichts Neues
* weiß, behält, was er wusste und behauptet nichts.
*
* Deshalb: nachfragen, bis der Server ANTWORTET. Erst eine Antwort
* entscheidet.
*/
useEffect(() => {
let abgemeldet = false
let versuche = 0
const fragen = () => {
api.get('/setup')
.then((r) => { if (!abgemeldet) setSetupDone(Boolean(r.data?.done)) })
.catch(() => {
if (abgemeldet) return
versuche += 1
// Zwei Minuten lang alle zwei Sekunden. Antwortet der Server bis
// dahin nicht, hat der Nutzer ein anderes Problem als den
// Assistenten — dann zeigen wir die Oberfläche, damit er die Logs
// sehen kann.
if (versuche < 60) setTimeout(fragen, 2000)
else setSetupDone(true)
})
}
fragen()
return () => { abgemeldet = true }
}, [])
const navItems: { id: Page; label: string; icon: any }[] = [
{ id: 'dashboard', label: 'Dashboard', icon: LayoutDashboard },
{ id: 'anleitung', label: 'Anleitung', icon: BookOpen },
{ id: 'logs', label: 'Logs', icon: FileText },
{ id: 'settings', label: 'Einstellungen', icon: SettingsIcon },
]
// Solange /setup noch nicht geantwortet hat: sagen, dass gewartet wird.
// Ein leeres Fenster sieht aus wie ein Absturz — und nach einer frischen
// Installation ist genau das der erste Eindruck.
if (setupDone === null) {
return (
<div className="min-h-screen flex items-center justify-center bg-[#0b0f19]">
<div className="text-center">
<div className="text-amber-400 text-3xl mb-3"></div>
<p className="text-slate-300 text-sm">Rippy startet </p>
<p className="text-slate-500 text-xs mt-1 font-mono">
warte auf den Dienst
</p>
</div>
</div>
)
}
if (!setupDone) return <FirstRunWizard onDone={() => setSetupDone(true)} />
return (
<div className="min-h-screen bg-[#080b11] text-slate-100 font-sans selection:bg-amber-500/30 selection:text-amber-300">
{/* Top Header Navigation Bar */}
<header className="sticky top-0 z-50 bg-[#0c101d]/95 backdrop-blur-2xl border-b border-amber-500/20 shadow-xl shadow-black/50">
<div className="max-w-[1400px] mx-auto px-4 sm:px-6 lg:px-8 h-16 flex items-center justify-between gap-4">
{/* Logo */}
<div className="flex items-center gap-3 cursor-pointer" onClick={() => setCurrentPage('dashboard')}>
<span className="text-2xl font-black tracking-wider bg-gradient-to-r from-amber-400 via-amber-300 to-amber-500 bg-clip-text text-transparent drop-shadow-[0_0_12px_rgba(245,158,11,0.4)] font-mono">
RIPPY
</span>
<span className="px-2.5 py-0.5 rounded text-[10px] font-bold uppercase tracking-widest bg-amber-500/15 text-amber-400 border border-amber-500/30">
CINEMA OS
</span>
</div>
{/* Central Nav Tabs */}
<nav className="flex items-center gap-1.5 bg-[#121827] p-1.5 rounded-2xl border border-slate-800 shadow-inner">
{navItems.map((item) => {
const Icon = item.icon
const isActive = currentPage === item.id
return (
<button
key={item.id}
onClick={() => setCurrentPage(item.id)}
className={`flex items-center gap-2 px-4 py-2 rounded-xl text-xs font-semibold transition-all duration-200 ${
isActive
? 'bg-amber-500 text-slate-950 shadow-md shadow-amber-500/20 font-bold scale-[1.02]'
: 'text-slate-400 hover:text-slate-100 hover:bg-slate-800/60'
}`}
>
<Icon size={15} className={isActive ? 'text-slate-950' : 'text-slate-400'} />
<span>{item.label}</span>
</button>
)
})}
</nav>
<VerbindungsAnzeige />
</div>
</header>
{/* Main Content Viewport */}
<main className="max-w-[1400px] mx-auto px-4 sm:px-6 lg:px-8 py-8">
{/* Je Seite eine eigene Grenze: Faellt eine aus, bleibt die
Navigation stehen und man kommt woanders hin. Ohne das war am
29.08.2026 nach einem Klick auf Rippen starten" der ganze
Bildschirm leer samt Kopfzeile. */}
<Fehlergrenze bereich={
currentPage === 'dashboard' ? 'Das Dashboard'
: currentPage === 'anleitung' ? 'Die Anleitung'
: currentPage === 'logs' ? 'Die Protokolle' : 'Die Einstellungen'}>
{currentPage === 'dashboard' && <Dashboard />}
{currentPage === 'anleitung' && <AnleitungPage />}
{currentPage === 'logs' && <LogsPage />}
{currentPage === 'settings' && <SettingsPage />}
</Fehlergrenze>
</main>
</div>
)
}
export default function App() {
// Der Provider haelt GENAU EINE SSE-Verbindung fuer die ganze Anwendung.
// Ein Hook je Komponente waere eine Verbindung je Komponente — also das
// alte Problem in neuer Form.
// BetriebProvider ganz aussen: Was Rippy anzeigen DARF, entscheidet sich
// vor allem anderen. Ohne ihn zeigte das Windows-Fenster "Pruefen: docker
// compose ps" — einen Rat, den dort niemand befolgen kann.
return (
<Fehlergrenze>
<BetriebProvider>
<EventStreamProvider>
<AppInhalt />
</EventStreamProvider>
</BetriebProvider>
</Fehlergrenze>
)
}
+34 -38
View File
@@ -1,5 +1,7 @@
import { useState } from 'react'
import { useDarkMode } from '../context/ThemeContext'
import { ReactNode } from 'react'
import { AlertTriangle, CheckCircle2, HelpCircle } from 'lucide-react'
import { Modal } from './ui/Modal'
import { Button } from './ui/Button'
interface ConfirmDialogProps {
isOpen: boolean
@@ -7,6 +9,9 @@ interface ConfirmDialogProps {
onConfirm: () => void
title: string
message: string
// Zusatz unter der Meldung — z. B. ein Kasten mit der Größe der Rohdaten,
// die beim Entfernen liegen bleiben, samt Wahl „mitlöschen".
extra?: ReactNode
confirmText?: string
cancelText?: string
type?: 'warning' | 'info' | 'success'
@@ -18,66 +23,57 @@ export default function ConfirmDialog({
onConfirm,
title,
message,
extra,
confirmText = 'Bestätigen',
cancelText = 'Abbrechen',
type = 'info',
}: ConfirmDialogProps) {
const { theme } = useDarkMode()
const getIcon = () => {
switch (type) {
case 'warning': return <span className="text-4xl"></span>
case 'success': return <span className="text-4xl"></span>
default: return <span className="text-4xl">🤔</span>
case 'warning':
return <AlertTriangle className="text-amber-500 w-8 h-8 flex-shrink-0" />
case 'success':
return <CheckCircle2 className="text-emerald-500 w-8 h-8 flex-shrink-0" />
default:
return <HelpCircle className="text-indigo-500 w-8 h-8 flex-shrink-0" />
}
}
const getConfirmColor = () => {
const getConfirmVariant = () => {
switch (type) {
case 'warning': return 'bg-amber-600 hover:bg-amber-700 shadow-lg shadow-amber-500/30'
case 'success': return 'bg-emerald-600 hover:bg-emerald-700 shadow-lg shadow-emerald-500/30'
default: return 'bg-indigo-600 hover:bg-indigo-700 shadow-lg shadow-indigo-500/30'
case 'warning':
return 'amber'
case 'success':
return 'primary'
default:
return 'primary'
}
}
if (!isOpen) return null
return (
<div className="fixed inset-0 z-50 flex items-center justify-center p-4 bg-black/50 backdrop-blur-sm transition-all">
<div className={`w-full max-w-md rounded-xl shadow-2xl transition-colors duration-300 ${theme === 'dark' ? 'bg-slate-800' : 'bg-white'}`}>
{/* Header */}
<div className={`px-6 py-4 border-b transition-colors duration-300 ${theme === 'dark' ? 'border-slate-700' : 'border-slate-200'}`}>
<div className="flex items-center gap-3">
<Modal isOpen={isOpen} onClose={onClose} maxWidth="md">
<div className="flex items-start gap-4">
{getIcon()}
<h2 className={`text-xl font-bold ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>
<div className="space-y-2 flex-1">
<h2 className="text-lg font-bold text-slate-900 dark:text-slate-100">
{title}
</h2>
</div>
</div>
{/* Body */}
<div className="px-6 py-6">
<p className={`text-sm leading-relaxed ${theme === 'dark' ? 'text-slate-300' : 'text-slate-700'}`}>
<p className="text-sm leading-relaxed text-slate-600 dark:text-slate-300">
{message}
</p>
{extra}
</div>
</div>
{/* Footer */}
<div className={`px-6 py-4 border-t transition-colors duration-300 ${theme === 'dark' ? 'border-slate-700' : 'border-slate-200'} flex justify-end gap-3`}>
<button
onClick={onClose}
className={`px-4 py-2 rounded-lg text-sm font-medium transition-colors ${theme === 'dark' ? 'text-slate-400 hover:bg-slate-700' : 'text-slate-600 hover:bg-slate-100'}`}
>
<div className="mt-6 flex justify-end gap-3 border-t border-slate-200 dark:border-slate-800 pt-4">
<Button variant="secondary" onClick={onClose}>
{cancelText}
</button>
<button
onClick={onConfirm}
className={`px-4 py-2 rounded-lg text-sm font-medium text-white transition-colors ${getConfirmColor()}`}
>
</Button>
<Button variant={getConfirmVariant()} onClick={onConfirm}>
{confirmText}
</button>
</div>
</div>
</Button>
</div>
</Modal>
)
}
+170 -127
View File
@@ -1,10 +1,13 @@
import { useState, useEffect } from 'react'
import { HardDrive, Disc, AlertCircle, CheckCircle, RefreshCw } from 'lucide-react'
import { api } from '../lib/api'
import { useDarkMode } from '../context/ThemeContext'
import { useToast } from '../context/ToastContext'
import RipTargetModal from './RipTargetModal'
import { Card, CardHeader, CardTitle, CardContent } from './ui/Card'
import { Button } from './ui/Button'
import { TypeBadge } from './ui/Badge'
import RipTargetModal, { RipOptionen } from './RipTargetModal'
import MetadataKorrektur from './MetadataKorrektur'
import { useStrom } from '../lib/useEventStream'
interface DiscInfo {
title: string
@@ -15,27 +18,44 @@ interface DiscInfo {
poster_path?: string
overview?: string
type?: string
source?: string
}
bereits_gerippt?: {
job_id: string
title?: string
finished_at?: string
}
}
interface Device {
id: string
name: string
type: 'cd' | 'dvd' | 'bluray' | 'unknown'
type: 'cd' | 'dvd' | 'bluray' | 'uhd' | 'unknown'
path: string
status: 'empty' | 'ready' | 'ripping'
serial?: string
model?: string
disc?: DiscInfo
/** Erkennung laeuft — noch kein Titel, aber auch kein leeres Laufwerk. */
disc_wird_erkannt?: boolean
}
// TMDB liefert relative Poster-Pfade, OMDb absolute URLs — beides abdecken
function posterUrl(disc?: DiscInfo): string | null {
const p = disc?.metadata?.poster_path
if (!p) return null
return p.startsWith('http') ? p : `https://image.tmdb.org/t/p/w342${p}`
}
function typLabel(type: string): string {
switch (type) {
case 'cd': return 'Audio CD'
case 'dvd': return 'DVD'
case 'bluray': return 'Blu-ray'
case 'uhd': return '4K UHD'
default: return 'Unbekannt'
}
}
export default function DeviceDiscovery() {
const [devices, setDevices] = useState<Device[]>([])
const [loading, setLoading] = useState(true)
@@ -45,12 +65,10 @@ export default function DeviceDiscovery() {
const [actionBusy, setActionBusy] = useState(false)
const [modalDevice, setModalDevice] = useState<Device | null>(null)
const [korrekturDevice, setKorrekturDevice] = useState<Device | null>(null)
const { theme } = useDarkMode()
const { toast } = useToast()
const strom = useStrom()
const refreshDevices = async (manuell = false) => {
// manuell = Klick auf den Refresh-Knopf: dreht das Icon und quittiert
// per Toast — vorher gab der Knopf KEIN sichtbares Feedback.
if (manuell) setRefreshing(true)
try {
const response = await api.get('/devices')
@@ -65,13 +83,22 @@ export default function DeviceDiscovery() {
}
}
const startRip = async (device: Device, targetDir?: string) => {
const startRip = async (device: Device, targetDir?: string, optionen?: RipOptionen) => {
setActionBusy(true)
setActionFeedback(null)
try {
const response = await api.post('/jobs', {
device_path: device.path,
...(targetDir ? { target_dir: targetDir } : {}),
...(optionen?.series ? { series: optionen.series, season: optionen.season } : {}),
...(optionen?.mainFeatureOnly !== undefined ? { main_feature_only: optionen.mainFeatureOnly } : {}),
...(optionen?.titles && optionen.titles.length ? { titles: optionen.titles } : {}),
...(optionen?.transcodeNode ? { transcode_node: optionen.transcodeNode } : {}),
...(optionen?.workDir ? { work_dir: optionen.workDir } : {}),
// Sprachauswahl dieses Rips (leer = alles behalten)
...(optionen?.audioSprachen?.length ? { audio_sprachen: optionen.audioSprachen } : {}),
...(optionen?.untertitelSprachen?.length
? { untertitel_sprachen: optionen.untertitelSprachen } : {}),
})
setActionFeedback(`✓ Job angelegt (${response.data.id.slice(0, 8)}…) — Fortschritt im Dashboard`)
toast('success', 'Rip gestartet — Fortschritt unten bei „Neueste Jobs"')
@@ -101,221 +128,237 @@ export default function DeviceDiscovery() {
}
}
// Vorher: alle 5 s ein eigener Abruf von /devices (12 Anfragen pro Minute).
// Jetzt liefert der Server die Aenderung, sobald sie passiert.
//
// WICHTIG — nur uebernehmen, wenn der Server wirklich etwas WEISS:
// `strom.devices === null` heisst „konnte nicht nachsehen" (haengendes
// Laufwerk, Zeitgrenze) und NICHT „es gibt keine Laufwerke". In dem Fall
// bleibt der letzte bekannte Stand stehen. Genau diese Vermischung hat in
// v1 die Listen im Sekundentakt geleert.
useEffect(() => {
refreshDevices()
const interval = setInterval(refreshDevices, 5000)
return () => clearInterval(interval)
}, [])
const getTypeColor = (type: string) => {
switch (type) {
case 'cd': return theme === 'dark' ? 'bg-blue-900/30 text-blue-400' : 'bg-blue-100 text-blue-600'
case 'dvd': return theme === 'dark' ? 'bg-purple-900/30 text-purple-400' : 'bg-purple-100 text-purple-600'
case 'bluray': return theme === 'dark' ? 'bg-pink-900/30 text-pink-400' : 'bg-pink-100 text-pink-600'
default: return theme === 'dark' ? 'bg-slate-700 text-slate-400' : 'bg-slate-100 text-slate-600'
if (strom.devices !== null) {
setDevices(strom.devices as Device[])
setLoading(false)
}
}, [strom.devices])
const QUELLEN_LABEL: Record<string, string> = {
tmdb: 'TMDB', omdb: 'OMDb', jikan: 'MyAnimeList', manuell: 'manuell gewählt',
}
const getStatusColor = (status: string) => {
const getStatusBadge = (status: string) => {
switch (status) {
case 'empty': return theme === 'dark' ? 'bg-slate-700 text-slate-400' : 'bg-slate-100 text-slate-600'
case 'ready': return theme === 'dark' ? 'bg-emerald-900/30 text-emerald-400' : 'bg-emerald-100 text-emerald-700'
case 'ripping': return theme === 'dark' ? 'bg-blue-900/30 text-blue-400' : 'bg-blue-100 text-blue-700'
default: return theme === 'dark' ? 'bg-slate-700 text-slate-400' : 'bg-slate-100 text-slate-600'
}
}
const getStatusIcon = (status: string) => {
switch (status) {
case 'empty': return <AlertCircle size={16} />
case 'ready': return <CheckCircle size={16} />
case 'ripping': return <RefreshCw size={16} className="animate-spin" />
default: return <AlertCircle size={16} />
case 'empty':
return <span className="inline-flex items-center gap-1.5 px-2.5 py-0.5 rounded-full text-xs font-medium bg-slate-500/15 text-slate-400 border border-slate-500/30"><AlertCircle size={13} /> Keine Disc</span>
case 'ready':
return <span className="inline-flex items-center gap-1.5 px-2.5 py-0.5 rounded-full text-xs font-medium bg-emerald-500/15 text-emerald-600 dark:text-emerald-400 border border-emerald-500/30"><CheckCircle size={13} /> Bereit</span>
case 'ripping':
return <span className="inline-flex items-center gap-1.5 px-2.5 py-0.5 rounded-full text-xs font-medium bg-sky-500/15 text-sky-600 dark:text-sky-400 border border-sky-500/30 animate-pulse"><RefreshCw size={13} className="animate-spin" /> Rippt</span>
default:
return <span className="inline-flex items-center gap-1.5 px-2.5 py-0.5 rounded-full text-xs font-medium bg-slate-500/15 text-slate-400 border border-slate-500/30"><AlertCircle size={13} /> Unbekannt</span>
}
}
if (loading) {
return (
<div className="flex items-center justify-center py-8">
<RefreshCw className="animate-spin text-indigo-600" size={24} />
<RefreshCw className="animate-spin text-amber-500" size={24} />
</div>
)
}
return (
<div className={`rounded-xl shadow-sm border overflow-hidden transition-colors duration-300 ${theme === 'dark' ? 'bg-slate-800 border-slate-700' : 'bg-white border-slate-200'}`}>
<div className={`px-6 py-4 border-b transition-colors duration-300 ${theme === 'dark' ? 'border-slate-700' : 'border-slate-200'} flex items-center justify-between`}>
<Card className="overflow-hidden">
<CardHeader>
<div>
<h2 className={`text-lg font-semibold ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>Laufwerke</h2>
<p className={`text-sm ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>Erkannte Geräte mit automatischer Typ-Erkennung</p>
</div>
<button
onClick={() => refreshDevices(true)}
className={`p-2 rounded-lg transition-colors ${theme === 'dark' ? 'hover:bg-slate-700 text-slate-400' : 'hover:bg-slate-100 text-slate-600'}`}
title="Geräte neu laden"
>
<RefreshCw size={20} className={loading || refreshing ? 'animate-spin' : ''} />
</button>
<CardTitle>Laufwerke</CardTitle>
<p className="text-sm text-slate-500 dark:text-slate-400">Erkannte Geräte mit automatischer Typ-Erkennung</p>
</div>
<Button variant="ghost" size="sm" onClick={() => refreshDevices(true)} title="Geräte neu laden">
<RefreshCw size={18} className={loading || refreshing ? 'animate-spin' : ''} />
</Button>
</CardHeader>
<CardContent>
{/*
Die Erkennung LÄUFT NOCH das muss man sehen.
Commander 29.08.2026: das die disc erkennung noch läuft muss
sichtbar sein". An einer Blu-ray dauert sie rund zwei Minuten
(`makemkvcon info` läuft in seine 120-Sekunden-Grenze; gemessen:
Disc nach 119 s erkannt). Vorher war in dieser Zeit NICHTS zu
sehen weder die Disc noch ein Hinweis. Das sah aus wie ein
leeres Laufwerk, also wie ein Fehler.
*/}
{devices.filter(d => d.disc_wird_erkannt).map(device => (
<div
key={`erkennung-${device.id}`}
className="mb-6 rounded-2xl border border-slate-700 bg-slate-900/60 px-5 py-4 flex items-center gap-3"
>
<RefreshCw size={18} className="animate-spin text-amber-400 flex-shrink-0" />
<div>
<p className="font-semibold text-slate-200">
Disc wird gelesen {device.name}
</p>
<p className="text-xs text-slate-400 mt-0.5">
Rippy liest Titel und Laufzeiten von der Disc. Das dauert bis
zu zwei Minuten; danach steht hier, was drin ist.
</p>
</div>
</div>
))}
<div className="p-6 transition-colors duration-300">
{/* Disc-Karte: WAS liegt gerade im Laufwerk (Auto-Pre-Scan) */}
{devices.filter(d => d.status === 'ready' && d.disc).map(device => (
<div
key={`disc-${device.id}`}
className={`mb-6 rounded-xl overflow-hidden border-2 flex ${theme === 'dark' ? 'border-indigo-500/40 bg-gradient-to-r from-indigo-950/60 to-slate-900' : 'border-indigo-200 bg-gradient-to-r from-indigo-50 to-white'}`}
className="mb-6 rounded-2xl overflow-hidden border border-amber-500/40 bg-gradient-to-r from-amber-500/15 via-slate-900 to-slate-950 flex shadow-xl shadow-amber-500/5 backdrop-blur-md"
>
{posterUrl(device.disc) && (
<img
src={posterUrl(device.disc)!}
alt={device.disc!.title}
className="w-28 object-cover flex-shrink-0"
className="w-32 object-cover flex-shrink-0 border-r border-slate-800"
/>
)}
<div className="p-5 flex-1 min-w-0">
<p className={`text-xs font-semibold uppercase tracking-wider mb-1 ${theme === 'dark' ? 'text-indigo-400' : 'text-indigo-600'}`}>
<div className="p-5 flex-1 min-w-0 flex flex-col justify-between">
<div>
<p className="text-[11px] font-bold uppercase tracking-wider mb-1 text-amber-400">
Im Laufwerk erkannt
</p>
<h3 className={`text-xl font-bold truncate ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>
<h3 className="text-xl font-bold truncate text-slate-900 dark:text-slate-100">
{device.disc!.title}
{device.disc!.year ? <span className={`font-normal ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}> ({device.disc!.year})</span> : null}
{device.disc!.year ? <span className="font-normal text-slate-500 dark:text-slate-400"> ({device.disc!.year})</span> : null}
</h3>
<div className="flex items-center gap-2 mt-2">
<span className={`text-xs font-medium px-2 py-0.5 rounded ${getTypeColor(device.type)}`}>
{device.disc!.disc_type?.toUpperCase()}
</span>
<span className={`text-xs ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
Übereinstimmung {Math.round((device.disc!.confidence || 0) * 100)} %
<TypeBadge type={device.type} />
<span className="text-xs text-slate-500 dark:text-slate-400">
Quelle: {QUELLEN_LABEL[device.disc!.metadata?.source || ''] || device.disc!.metadata?.source || 'Disc-Label'}
{' · '}{Math.round((device.disc!.confidence || 0) * 100)} % sicher
</span>
</div>
{device.disc!.metadata?.overview && (
<p className={`text-sm mt-2 line-clamp-2 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-600'}`}>
<p className="text-sm mt-2 line-clamp-2 text-slate-600 dark:text-slate-300">
{device.disc!.metadata.overview}
</p>
)}
<div className="flex items-center gap-3 mt-3">
<button
onClick={() => setModalDevice(device)}
disabled={actionBusy}
className="px-4 py-2 rounded-lg bg-indigo-600 text-white text-sm font-medium hover:bg-indigo-700 transition-colors disabled:opacity-40"
>
{device.disc!.bereits_gerippt && (
<p className="text-xs mt-2 px-3 py-1.5 rounded-xl inline-flex items-center gap-1.5 bg-amber-500/10 border border-amber-500/20 text-amber-600 dark:text-amber-300">
<AlertCircle size={13} className="flex-shrink-0" />
Diese Disc wurde bereits gerippt
{device.disc!.bereits_gerippt.finished_at
? ` (${new Date(device.disc!.bereits_gerippt.finished_at).toLocaleDateString('de-DE')})`
: ''} nochmal rippen ist möglich.
</p>
)}
</div>
<div className="flex items-center gap-3 mt-4">
<Button variant="amber" onClick={() => setModalDevice(device)} disabled={actionBusy}>
Rippen starten
</button>
<button
onClick={() => setKorrekturDevice(device)}
className={`px-4 py-2 rounded-lg text-sm font-medium transition-colors ${theme === 'dark' ? 'bg-slate-800 text-amber-300 hover:bg-slate-700' : 'bg-slate-100 text-amber-700 hover:bg-slate-200'}`}
>
</Button>
<Button variant="secondary" onClick={() => setKorrekturDevice(device)}>
Nicht korrekt?
</button>
</Button>
</div>
</div>
</div>
))}
{devices.length === 0 ? (
<div className="text-center py-12 transition-colors duration-300">
<div className={`mx-auto w-16 h-16 rounded-full flex items-center justify-center mb-4 ${theme === 'dark' ? 'bg-slate-700' : 'bg-slate-100'}`}>
<HardDrive className={theme === 'dark' ? 'text-slate-400' : 'text-slate-400'} size={32} />
<div className="text-center py-12">
<div className="mx-auto w-16 h-16 rounded-2xl flex items-center justify-center mb-4 bg-slate-100 dark:bg-slate-800 text-slate-400">
<HardDrive size={32} />
</div>
<p className={`text-sm ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>Keine Laufwerke gefunden</p>
<p className={`text-xs mt-2 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
<p className="text-sm text-slate-500 dark:text-slate-400">Keine Laufwerke gefunden</p>
<p className="text-xs mt-1 text-slate-400 dark:text-slate-500">
Stelle sicher, dass ein Laufwerk angeschlossen ist
</p>
</div>
) : (
<div className="space-y-4 transition-colors duration-300">
<div className="space-y-3">
{devices.map(device => (
<div key={device.id} className={`rounded-lg p-5 border transition-colors duration-300 ${theme === 'dark' ? 'bg-slate-900 border-slate-700' : 'bg-slate-50 border-slate-200'}`}>
<div key={device.id} className="rounded-xl p-4 border border-slate-200/80 dark:border-slate-800 bg-slate-50/50 dark:bg-slate-950/80">
<div className="flex items-start justify-between">
<div className="flex items-start gap-4">
<div className={`p-3 rounded-lg ${getTypeColor(device.type)}`}>
<Disc size={24} />
<div className="p-3 rounded-xl bg-slate-200/60 dark:bg-slate-800 text-slate-700 dark:text-slate-300 border border-slate-300 dark:border-slate-700">
<Disc size={22} className={device.status === 'ripping' ? 'animate-disc-spin text-amber-500' : ''} />
</div>
<div>
<div className="flex items-center gap-2 mb-1">
<h3 className={`font-semibold ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>
<h3 className="font-semibold text-slate-900 dark:text-slate-100">
{device.name || 'Unbekanntes Laufwerk'}
</h3>
{device.status === 'ripping' && (
<span className="flex items-center gap-1 text-xs font-medium text-blue-500">
<RefreshCw size={12} className="animate-spin" />
Rippt
</span>
)}
<TypeBadge type={device.type} />
</div>
<div className="flex flex-wrap gap-2 mt-2">
<span className={`text-xs font-mono px-2 py-1 rounded ${theme === 'dark' ? 'bg-slate-800 text-slate-400' : 'bg-slate-100 text-slate-600'}`}>
<span className="text-xs font-mono px-2 py-0.5 rounded bg-slate-200/70 dark:bg-slate-800 text-slate-600 dark:text-slate-400 border border-slate-300 dark:border-slate-700">
{device.path}
</span>
{device.serial && (
<span className={`text-xs px-2 py-1 rounded ${theme === 'dark' ? 'bg-slate-800 text-slate-400' : 'bg-slate-100 text-slate-600'}`}>
<span className="text-xs px-2 py-0.5 rounded bg-slate-200/70 dark:bg-slate-800 text-slate-600 dark:text-slate-400 border border-slate-300 dark:border-slate-700">
{device.serial}
</span>
)}
{device.model && (
<span className={`text-xs px-2 py-1 rounded ${theme === 'dark' ? 'bg-slate-800 text-slate-400' : 'bg-slate-100 text-slate-600'}`}>
<span className="text-xs px-2 py-0.5 rounded bg-slate-200/70 dark:bg-slate-800 text-slate-600 dark:text-slate-400 border border-slate-300 dark:border-slate-700">
{device.model}
</span>
)}
</div>
<div className="flex items-center gap-2 mt-3">
<span className={`inline-flex items-center gap-1 px-2.5 py-1 rounded-md text-xs font-medium ${getStatusColor(device.status)}`}>
{getStatusIcon(device.status)}
{device.status === 'empty' ? 'Keine Disc' :
device.status === 'ready' ? 'Bereit' :
'Rippt'}
</span>
<span className={`text-xs ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
Typ: {device.type.toUpperCase()}
</span>
<div className="mt-3">
{getStatusBadge(device.status)}
</div>
</div>
</div>
<button
<Button
variant="ghost"
size="sm"
onClick={() => {
setExpandedId(expandedId === device.id ? null : device.id)
setActionFeedback(null)
}}
className={`text-sm font-medium transition-colors ${theme === 'dark' ? 'text-indigo-400 hover:text-indigo-300' : 'text-indigo-600 hover:text-indigo-700'}`}
>
{expandedId === device.id ? 'Schließen' : 'Details'}
</button>
</Button>
</div>
{expandedId === device.id && (
<div className={`mt-4 pt-4 border-t space-y-3 ${theme === 'dark' ? 'border-slate-700' : 'border-slate-200'}`}>
<div className="mt-4 pt-4 border-t border-slate-200/80 dark:border-slate-800 space-y-3">
<div className="grid grid-cols-2 gap-x-6 gap-y-1 text-sm">
<span className={theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}>Gerätepfad</span>
<span className={`font-mono ${theme === 'dark' ? 'text-slate-300' : 'text-slate-700'}`}>{device.path}</span>
<span className={theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}>Modell</span>
<span className={theme === 'dark' ? 'text-slate-300' : 'text-slate-700'}>{device.model || 'unbekannt'}</span>
<span className={theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}>Seriennummer</span>
<span className={`font-mono text-xs ${theme === 'dark' ? 'text-slate-300' : 'text-slate-700'}`}>{device.serial || '—'}</span>
<span className={theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}>Disc</span>
<span className={theme === 'dark' ? 'text-slate-300' : 'text-slate-700'}>
{device.status === 'ready' ? `eingelegt (${device.type.toUpperCase()})` : 'keine'}
<span className="text-slate-500 dark:text-slate-400">Gerätepfad</span>
<span className="font-mono text-slate-700 dark:text-slate-300">{device.path}</span>
<span className="text-slate-500 dark:text-slate-400">Modell</span>
<span className="text-slate-700 dark:text-slate-300">{device.model || 'unbekannt'}</span>
<span className="text-slate-500 dark:text-slate-400">Seriennummer</span>
<span className="font-mono text-xs text-slate-700 dark:text-slate-300">{device.serial || '—'}</span>
<span className="text-slate-500 dark:text-slate-400">Disc</span>
<span className="text-slate-700 dark:text-slate-300">
{device.status === 'ready' ? `eingelegt (${typLabel(device.type)})` : 'keine'}
</span>
</div>
<div className="flex items-center gap-3 pt-1">
<button
<Button
variant="amber"
size="sm"
onClick={() => setModalDevice(device)}
disabled={actionBusy || device.status !== 'ready'}
className="px-4 py-2 rounded-lg bg-indigo-600 text-white text-sm font-medium hover:bg-indigo-700 transition-colors disabled:opacity-40 disabled:cursor-not-allowed"
>
Rippen starten
</button>
<button
</Button>
<Button
variant="secondary"
size="sm"
onClick={() => ejectDisc(device)}
disabled={actionBusy || device.status !== 'ready'}
className={`px-4 py-2 rounded-lg text-sm font-medium transition-colors disabled:opacity-40 disabled:cursor-not-allowed ${theme === 'dark' ? 'bg-slate-700 text-slate-200 hover:bg-slate-600' : 'bg-slate-200 text-slate-700 hover:bg-slate-300'}`}
>
Auswerfen
</button>
</Button>
</div>
{actionFeedback && (
<p className={`text-sm ${actionFeedback.startsWith('✓') ? 'text-emerald-500' : 'text-rose-500'}`}>
<p className={`text-sm font-medium ${actionFeedback.startsWith('✓') ? 'text-emerald-500' : 'text-rose-500'}`}>
{actionFeedback}
</p>
)}
@@ -325,21 +368,21 @@ export default function DeviceDiscovery() {
))}
</div>
)}
</div>
</CardContent>
{/* Ziel-Auswahl vor dem Rip-Start (Filme/Serien/Musik oder eigener
Pfad dort eingehängte Shares sind direkt wählbar) */}
<RipTargetModal
isOpen={modalDevice !== null}
initialType={modalDevice?.type === 'cd' ? 'music' : (modalDevice?.disc?.metadata?.type === 'tv' ? 'series' : 'movies')}
discTitle={modalDevice?.disc?.title}
deviceId={modalDevice?.id}
onClose={() => setModalDevice(null)}
onSave={(target) => {
onSave={(target, optionen) => {
if (modalDevice) {
startRip(modalDevice, target.path)
startRip(modalDevice, target.path, optionen)
}
}}
/>
{/* „Nicht korrekt?"-Popup: Korrektur ohne Seitenwechsel */}
<MetadataKorrektur
devicePath={korrekturDevice?.path || ''}
vorschlag={korrekturDevice?.disc?.title}
@@ -347,6 +390,6 @@ export default function DeviceDiscovery() {
onClose={() => setKorrekturDevice(null)}
onUebernommen={refreshDevices}
/>
</div>
</Card>
)
}
+100
View File
@@ -0,0 +1,100 @@
/*
* Eine Fehlergrenze damit ein Fehler nicht die ganze Oberfläche verschluckt.
*
* ## Der Befund des Commanders (29.08.2026)
*
* > wenn man auf rippen starten klickt passiert irgendwas, was das Programm
* > nicht mag. Der Hintergrund ist einfach leer und er startet nix. Es gibt
* > auch keine fehlermeldung."
*
* Nachgestellt und in der Browser-Konsole gemessen:
*
* TypeError: Cannot read properties of undefined (reading 'toUpperCase')
*
* Der Job war in Wirklichkeit angelegt und lief (gemessen: `processing`,
* 12 %). Nur zeigte die Oberfläche das nie sie war weg. Grund: React baut
* bei einem Fehler im Zeichnen den GESAMTEN Baum ab, wenn ihn niemand
* auffängt. Und aufgefangen hat ihn niemand: Es gab in diesem Projekt keine
* einzige Fehlergrenze.
*
* ## Warum die eigentliche Reparatur woanders sitzt
*
* Die Ursache war ein Ereignis, das den halben Job schickte
* (`rippy/bus/waechter.py`), und zwei Stellen, die einen vollständigen
* annahmen. Das ist behoben. Diese Datei behebt etwas anderes: die WIRKUNG.
*
* Ein Programmierfehler in einer Karte darf den Rest des Bildschirms nicht
* mitnehmen und schon gar nicht schweigend. Der nächste Fehler dieser Art
* kommt bestimmt; dann steht wenigstens da, was los ist, und der Rest der
* Oberfläche bleibt bedienbar.
*
* Deshalb wird sie ZWEIMAL eingesetzt: einmal um die ganze Anwendung, und
* einmal um den Job-Bereich allein. Fällt eine Karte aus, bleibt der Rest.
*/
import { Component, ErrorInfo, ReactNode } from 'react'
interface Props {
children: ReactNode
/** Was hier kaputtgehen kann — steht in der Meldung. */
bereich?: string
}
interface State {
fehler: Error | null
}
export class Fehlergrenze extends Component<Props, State> {
state: State = { fehler: null }
static getDerivedStateFromError(fehler: Error): State {
return { fehler }
}
componentDidCatch(fehler: Error, info: ErrorInfo) {
// In die Konsole, damit die Ursache auffindbar bleibt. Ein stiller
// Fehler ist genau das, was diesen Befund so schwer gemacht hat.
console.error('Rippy: Fehler im Bereich', this.props.bereich || 'Oberfläche',
fehler, info.componentStack)
}
neuLaden = () => {
this.setState({ fehler: null })
}
render() {
if (!this.state.fehler) return this.props.children
return (
<div className="m-4 p-5 rounded-xl border border-amber-500/40 bg-amber-500/10">
<h2 className="font-semibold text-amber-700 dark:text-amber-300">
{this.props.bereich
? `${this.props.bereich} lässt sich gerade nicht anzeigen`
: 'Diese Ansicht lässt sich gerade nicht anzeigen'}
</h2>
<p className="text-sm mt-2 text-slate-600 dark:text-slate-300">
Der Fehler betrifft nur die Anzeige.{' '}
<strong>Laufende Rips gehen weiter</strong> Rippy arbeitet im
Hintergrund, auch wenn dieser Bereich leer bleibt.
</p>
<p className="text-xs mt-3 font-mono text-slate-500 dark:text-slate-400 break-all">
{this.state.fehler.message || String(this.state.fehler)}
</p>
<div className="flex gap-2 mt-4">
<button
onClick={this.neuLaden}
className="px-3 py-1.5 text-sm rounded-lg bg-amber-500 text-white hover:bg-amber-600"
>
Nochmal versuchen
</button>
<button
onClick={() => window.location.reload()}
className="px-3 py-1.5 text-sm rounded-lg border border-slate-300 dark:border-slate-700 text-slate-600 dark:text-slate-300"
>
Seite neu laden
</button>
</div>
</div>
)
}
}
+379 -85
View File
@@ -1,110 +1,303 @@
import { useState, useEffect } from 'react'
import { Disc, Cpu, Globe, Tv, CheckCircle, ArrowRight } from 'lucide-react'
import { Disc, Cpu, Globe, Tv, CheckCircle, ArrowRight, HardDrive, AlertTriangle, KeyRound } from 'lucide-react'
import { api } from '../lib/api'
import { useDarkMode } from '../context/ThemeContext'
import { useBetrieb } from '../lib/useBetrieb'
import { MEDIA_SERVER_OPTIONEN } from '../lib/mediaServer'
// Erster Start: Rippy universell einrichten (Commander-Ziel: All-in-one,
// weitergebbar — keine Handarbeit in .env-Dateien nötig).
import { PRESET_KEINE, schwacheEncoderCpu } from '../lib/encoder'
import { Button } from './ui/Button'
import { Input, Select } from './ui/Input'
interface WorkerInfo {
name: string
encoders: string[]
last_seen?: string
online?: boolean
info?: { cpu_kerne?: string; cpu_simd?: string; cpu_modell?: string }
}
interface GeraetInfo {
id: string
name: string
status: string
}
interface PlatzInfo {
name: string
frei_gb: number
gesamt_gb: number
}
const ENCODER_LABELS: Record<string, string> = {
'cpu-x264': 'CPU · H.264 (x264)',
'cpu-x265': 'CPU · H.265 (x265)',
'cpu-av1': 'CPU · AV1 (SVT-AV1)',
'vaapi': 'Hardware · VAAPI (AMD/Intel)',
'nvenc': 'Hardware · NVENC (NVIDIA)',
}
// Unter diesem Wert lohnt der Hinweis auf die Ablage: eine einzelne Blu-ray
// braucht roh rund 40 GB, eine 4K-UHD bis 100 GB.
const PLATZ_WARNUNG_GB = 60
// Antwort von GET /presets — dieselbe Quelle, die auch die Einstellungen-Seite
// benutzt. Bis 26.07.2026 entschied der Wizard hier selbst und mit fest
// verdrahteten Namen; jetzt kommt beides aus api/presets.py, wo es Tests hat.
interface PresetUebersicht {
quelle: 'worker' | 'rueckfall'
hardware: string[]
typen: Record<'uhd' | 'bluray' | 'dvd', {
empfehlung: { preset: string, grund: string, gefunden: boolean }
}>
}
/** Was beim Abschliessen gespeichert wird — die Empfehlung der API. */
function presetsFuer(uebersicht: PresetUebersicht | null) {
const nimm = (typ: 'uhd' | 'bluray' | 'dvd') => {
const e = uebersicht?.typen?.[typ]?.empfehlung
return e?.gefunden ? e.preset : ''
}
const uhd = nimm('uhd')
const bluray = nimm('bluray')
const dvd = nimm('dvd')
// Leere Werte gar nicht schreiben: dann bleibt der Bestandswert stehen,
// statt dass HandBrake später ein leeres --preset bekommt.
return {
...(bluray ? { transcodePreset: bluray, transcodePresetBluray: bluray } : {}),
...(dvd ? { transcodePresetDvd: dvd } : {}),
...(uhd ? { transcodePresetUhd: uhd } : {}),
}
}
export default function FirstRunWizard({ onDone }: { onDone: () => void }) {
const [tmdbKey, setTmdbKey] = useState('')
const [omdbKey, setOmdbKey] = useState('')
// MakeMKV-Beta-Key: Lizenz fuer die SOFTWARE (Blu-ray), nicht der
// Disc-Schluessel einer einzelnen 4K-Disc.
const [makemkvKey, setMakemkvKey] = useState('')
const [mediaServer, setMediaServer] = useState('jellyfin')
const [transcodeEnabled, setTranscodeEnabled] = useState(true)
const [preset, setPreset] = useState('H.265 MKV 1080p30')
const betrieb = useBetrieb()
const [workers, setWorkers] = useState<WorkerInfo[]>([])
const [geraete, setGeraete] = useState<GeraetInfo[]>([])
const [plaetze, setPlaetze] = useState<PlatzInfo[]>([])
const [presetInfo, setPresetInfo] = useState<PresetUebersicht | null>(null)
const [geladen, setGeladen] = useState(false)
const [saving, setSaving] = useState(false)
const [error, setError] = useState<string | null>(null)
const { theme } = useDarkMode()
const [keyWarnung, setKeyWarnung] = useState<string | null>(null)
// Wiederholt laden, bis Worker UND Laufwerk da sind: beim allerersten Start
// läuft der Worker-Container oft noch hoch. Ohne das stand hier dauerhaft
// „Noch kein Worker gemeldet" und der Nutzer wusste nicht, ob er warten soll.
useEffect(() => {
api.get('/capabilities')
.then(r => setWorkers(r.data.workers || []))
.catch(() => setWorkers([]))
let laeuft = true
const laden = async () => {
const [caps, devs, info, pres] = await Promise.allSettled([
api.get('/capabilities'),
api.get('/devices'),
api.get('/system/info'),
api.get('/presets'),
])
if (!laeuft) return
if (caps.status === 'fulfilled') setWorkers(caps.value.data?.workers || [])
if (devs.status === 'fulfilled') setGeraete(devs.value.data || [])
if (info.status === 'fulfilled') setPlaetze(info.value.data?.plaetze || [])
if (pres.status === 'fulfilled') setPresetInfo(pres.value.data || null)
setGeladen(true)
}
laden()
const takt = setInterval(laden, 5000)
return () => { laeuft = false; clearInterval(takt) }
}, [])
const schwach = schwacheEncoderCpu(workers)
const presets = presetsFuer(presetInfo)
const encoderWorker = workers.filter(w => w.encoders.length > 0)
const platz = plaetze.length > 0 ? Math.min(...plaetze.map(p => p.frei_gb)) : null
const abschliessen = async () => {
setSaving(true)
setError(null)
setKeyWarnung(null)
try {
const bestehende = (await api.get('/settings')).data || {}
await api.post('/settings', {
...bestehende,
...(tmdbKey ? { tmdbApiKey: tmdbKey } : {}),
...(omdbKey ? { omdbApiKey: omdbKey } : {}),
...(tmdbKey.trim() ? { tmdbApiKey: tmdbKey.trim() } : {}),
...(omdbKey.trim() ? { omdbApiKey: omdbKey.trim() } : {}),
...(makemkvKey.trim() ? { makemkvAppKey: makemkvKey.trim() } : {}),
mediaServer,
transcodeEnabled,
transcodePreset: preset,
...presets,
})
// Erst SPEICHERN, dann prüfen: /metadata/status liest die Keys aus der
// Datenbank, nicht aus dem Formular. Ein falsch kopierter Key fällt so
// sofort auf, statt erst beim ersten Rip als „Unknown Disc".
if (tmdbKey.trim() || omdbKey.trim()) {
try {
const s = (await api.get('/metadata/status')).data || {}
const kaputt = Object.entries(s)
.filter(([, v]) => v === 'fehler')
.map(([k]) => k.toUpperCase())
if (kaputt.length > 0) {
setKeyWarnung(
`${kaputt.join(' und ')} hat den Key nicht angenommen — vermutlich ein `
+ 'Tippfehler beim Kopieren. Rippy laeuft trotzdem, die Titel heissen dann '
+ 'nur wie das Disc-Label. Nachbessern: Einstellungen → APIs.'
)
setSaving(false)
return // nicht wegklicken, damit die Warnung gelesen wird
}
} catch {
// Prüfung selbst kaputt → kein Grund, die Einrichtung zu blockieren
}
}
await api.post('/setup/complete')
onDone()
} catch {
setError('Speichern fehlgeschlagen — läuft die API?')
} finally {
setError('Speichern fehlgeschlagen — läuft die API? (Seite neu laden hilft meist.)')
setSaving(false)
}
}
const feldKlasse = `w-full px-3 py-2 border rounded-lg focus:ring-2 focus:ring-indigo-500 focus:border-transparent ${theme === 'dark' ? 'bg-slate-800 border-slate-600 text-slate-200' : 'bg-white border-slate-300 text-slate-900'}`
const trotzdemWeiter = async () => {
setSaving(true)
try {
await api.post('/setup/complete')
onDone()
} catch {
setError('Speichern fehlgeschlagen — läuft die API?')
setSaving(false)
}
}
return (
<div className={`min-h-screen flex items-center justify-center p-6 ${theme === 'dark' ? 'bg-slate-950' : 'bg-slate-100'}`}>
<div className={`w-full max-w-2xl rounded-2xl shadow-2xl overflow-hidden ${theme === 'dark' ? 'bg-slate-900 border border-slate-800' : 'bg-white'}`}>
<div className="bg-gradient-to-r from-indigo-600 to-purple-700 p-8 text-white">
<div className="min-h-screen flex items-center justify-center p-6 bg-slate-100 dark:bg-slate-950">
<div className="w-full max-w-2xl rounded-2xl shadow-2xl overflow-hidden bg-white dark:bg-slate-900 border border-slate-200 dark:border-slate-800">
<div className="bg-gradient-to-r from-amber-500 via-indigo-600 to-purple-700 p-8 text-white">
<div className="flex items-center gap-3 mb-2">
<Disc size={32} />
<Disc size={32} className="animate-disc-spin" />
<h1 className="text-2xl font-bold">Willkommen bei Rippy</h1>
</div>
<p className="opacity-90">Einmalige Einrichtung dauert keine zwei Minuten. Alles ist später unter Einstellungen änderbar.</p>
<p className="opacity-90">
Einmalige Einrichtung dauert keine zwei Minuten. Du kannst nichts kaputt
machen: alles ist später unter Einstellungen änderbar.
</p>
</div>
<div className="p-8 space-y-8">
{/* Metadaten-APIs */}
{/* ---- Was Rippy gerade sieht ---------------------------------- */}
<section>
<h2 className={`flex items-center gap-2 text-lg font-semibold mb-3 ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>
<Globe size={18} className="text-indigo-500" /> Metadaten-Erkennung
<h2 className="flex items-center gap-2 text-lg font-semibold mb-3 text-slate-900 dark:text-slate-100">
<HardDrive size={18} className="text-amber-500" /> Was Rippy gerade sieht
</h2>
<div className="rounded-xl border border-slate-200 dark:border-slate-800 divide-y divide-slate-200 dark:divide-slate-800 overflow-hidden">
<Zeile
titel="Laufwerk"
geladen={geladen}
gut={geraete.length > 0}
gutText={geraete.map(g => g.name).join(', ')}
schlechtText="Kein optisches Laufwerk gefunden. Rippy kann dann nur komprimieren, nicht rippen. Prüfe, ob das Laufwerk angeschlossen und (bei einer VM) durchgereicht ist."
/>
<Zeile
/* Auf einem Windows-PC gibt es keinen "Encoding-Worker" und
keinen Worker-Container -- Rippy komprimiert selbst. Der
Commander am 28.08.2026: "Das gilt fuer die ganze
standalone version fuer Windows." */
titel={betrieb.kann.externe_worker ? 'Encoding-Worker' : 'Kompression'}
geladen={geladen}
gut={encoderWorker.length > 0}
gutText={encoderWorker.map(w => {
const kerne = w.info?.cpu_kerne
const simd = w.info?.cpu_simd
const zusatz = [kerne ? `${kerne} Kerne` : '', simd && simd !== 'unbekannt' ? simd : '']
.filter(Boolean).join(', ')
return zusatz ? `${w.name} (${zusatz})` : w.name
}).join(' · ')}
schlechtText={betrieb.kann.externe_worker
? 'Noch kein Worker gemeldet. Beim ersten Start dauert das bis zu einer Minute — diese Anzeige aktualisiert sich selbst. Bleibt es dabei, läuft der Worker-Container nicht.'
: 'Rippy meldet noch keine Encoder. Beim ersten Start dauert das bis zu einer Minute — diese Anzeige aktualisiert sich selbst.'}
/>
<Zeile
titel="Freier Platz"
geladen={geladen}
gut={platz === null || platz >= PLATZ_WARNUNG_GB}
gutText={platz === null ? '—' : `${platz.toFixed(0)} GB`}
schlechtText={`Nur ${platz?.toFixed(0)} GB frei. Eine Blu-ray braucht roh rund 40 GB, eine 4K-UHD bis 100 GB. Lege die Ablage besser auf eine NAS-Freigabe (Einstellungen → Speicherziele).`}
/>
</div>
</section>
{/* ---- Metadaten ---------------------------------------------- */}
<section>
<h2 className="flex items-center gap-2 text-lg font-semibold mb-3 text-slate-900 dark:text-slate-100">
<Globe size={18} className="text-amber-500" /> Metadaten-Erkennung
</h2>
<div className="space-y-3">
<div>
<label className={`block text-sm font-medium mb-1 ${theme === 'dark' ? 'text-slate-300' : 'text-slate-700'}`}>
TMDB API-Key <span className="text-indigo-500">(empfohlen)</span>
</label>
<input type="password" value={tmdbKey} onChange={e => setTmdbKey(e.target.value)} className={feldKlasse} placeholder="Kostenlos auf themoviedb.org" />
</div>
<div>
<label className={`block text-sm font-medium mb-1 ${theme === 'dark' ? 'text-slate-300' : 'text-slate-700'}`}>
OMDb API-Key <span className={theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}>(optional, zweite Quelle)</span>
</label>
<input type="password" value={omdbKey} onChange={e => setOmdbKey(e.target.value)} className={feldKlasse} placeholder="Kostenlos auf omdbapi.com" />
</div>
<p className={`text-xs ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
{/* Bewusst SICHTBAR statt type=password: Das sind kopierte Keys,
keine Passwoerter und einen Tippfehler sieht man in Punkten
nicht. Geprueft wird direkt nach dem Speichern. */}
<Input
label="TMDB API-Key (empfohlen)"
value={tmdbKey}
onChange={e => setTmdbKey(e.target.value)}
placeholder="Kostenlos auf themoviedb.org — hier einfügen"
/>
<Input
label="OMDb API-Key (optional, zweite Quelle)"
value={omdbKey}
onChange={e => setOmdbKey(e.target.value)}
placeholder="Kostenlos auf omdbapi.com"
/>
<p className="text-xs text-slate-500 dark:text-slate-400">
Ohne Keys rippt Rippy trotzdem Discs heißen dann nur wie ihr Volume-Label.
Beide Keys werden direkt nach dem Speichern geprüft.
</p>
</div>
</section>
{/* Media-Server: worauf soll Rippy die Ablage vorbereiten? */}
{/* ---- MakeMKV-Beta-Key --------------------------------------- */}
{/*
Neu 26.07.2026, bei der Weitergabe-Prüfung aufgefallen: Der Key war
in der README, in der .env und in den Einstellungen zu finden nur
NICHT hier. Ein Fremder installiert also, legt eine Blu-ray ein und
bekommt irgendwann einen Fehlschlag, ohne dass ihn beim Einrichten
jemand darauf hingewiesen hätte. Das ist die wahrscheinlichste
Stolperstelle einer frischen Installation.
*/}
<section>
<h2 className={`flex items-center gap-2 text-lg font-semibold mb-3 ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>
<Tv size={18} className="text-indigo-500" /> Dein Media-Server
<h2 className="flex items-center gap-2 text-lg font-semibold mb-3 text-slate-900 dark:text-slate-100">
<KeyRound size={18} className="text-amber-500" /> MakeMKV-Beta-Key
</h2>
<p className={`text-sm mb-3 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>
<div className="space-y-3">
<Input
label="Beta-Key (für Blu-ray; DVDs gehen ohne)"
value={makemkvKey}
onChange={e => setMakemkvKey(e.target.value)}
placeholder="T-… — kostenlos im MakeMKV-Forum, Thread t=1053"
/>
<p className="text-xs text-slate-500 dark:text-slate-400">
MakeMKV ist für <strong>DVDs dauerhaft kostenlos</strong>. Für
<strong> Blu-ray und 4K</strong> braucht es den Beta-Key; ohne ihn läuft
eine 30-Tage-Probezeit, danach bricht jeder Blu-ray-Rip ab. Der Key ist
kostenlos, wechselt aber etwa monatlich nachpflegen unter
Einstellungen System, das wirkt sofort ab dem nächsten Rip, ohne
Neubau.
</p>
<p className="text-xs text-slate-500 dark:text-slate-400">
Nicht verwechseln mit dem <strong>Disc-Schlüssel</strong> einer einzelnen
4K-Disc das ist eine andere Sache und steht unter Einstellungen System.
</p>
</div>
</section>
{/* ---- Media-Server ------------------------------------------- */}
<section>
<h2 className="flex items-center gap-2 text-lg font-semibold mb-3 text-slate-900 dark:text-slate-100">
<Tv size={18} className="text-amber-500" /> Dein Media-Server
</h2>
<p className="text-sm mb-3 text-slate-500 dark:text-slate-400">
Rippy benennt fertige Rips als Titel (Jahr)" und legt für Jellyfin/Emby/Kodi
zusätzlich movie.nfo + poster.jpg dazu dein Server erkennt alles ohne Nacharbeit.
zusätzlich movie.nfo + poster.jpg dazu.
</p>
<div className="grid grid-cols-2 md:grid-cols-5 gap-2">
{MEDIA_SERVER_OPTIONEN.map(o => (
@@ -113,76 +306,146 @@ export default function FirstRunWizard({ onDone }: { onDone: () => void }) {
type="button"
onClick={() => setMediaServer(o.wert)}
title={o.hinweis}
className={`px-3 py-2 rounded-lg text-sm font-medium border transition-all ${
className={`px-3 py-2 rounded-xl text-sm font-medium border transition-all ${
mediaServer === o.wert
? theme === 'dark'
? 'bg-indigo-900/40 border-indigo-500 text-indigo-300'
: 'bg-indigo-50 border-indigo-600 text-indigo-700'
: theme === 'dark'
? 'bg-slate-800 border-slate-700 text-slate-400 hover:border-slate-600'
: 'bg-slate-50 border-slate-200 text-slate-600 hover:border-slate-300'
? 'bg-amber-500/20 border-amber-500 text-amber-600 dark:text-amber-300 font-semibold'
: 'bg-slate-50 dark:bg-slate-800 border-slate-200 dark:border-slate-700 text-slate-600 dark:text-slate-400 hover:border-slate-300 dark:hover:border-slate-600'
}`}
>
{o.label}
</button>
))}
</div>
<p className={`text-xs mt-2 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
<p className="text-xs mt-2 text-slate-500 dark:text-slate-400">
{MEDIA_SERVER_OPTIONEN.find(o => o.wert === mediaServer)?.hinweis}
</p>
</section>
{/* Verarbeitung + erkannte Hardware */}
{/* ---- Verarbeitung ------------------------------------------- */}
<section>
<h2 className={`flex items-center gap-2 text-lg font-semibold mb-3 ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>
<Cpu size={18} className="text-indigo-500" /> Verarbeitung
<h2 className="flex items-center gap-2 text-lg font-semibold mb-3 text-slate-900 dark:text-slate-100">
<Cpu size={18} className="text-amber-500" /> Verarbeitung
</h2>
<div className={`rounded-lg p-4 mb-3 ${theme === 'dark' ? 'bg-slate-800' : 'bg-slate-50'}`}>
<p className={`text-sm font-medium mb-2 ${theme === 'dark' ? 'text-slate-300' : 'text-slate-700'}`}>Erkannte Encoder in deinem System:</p>
{workers.length === 0 ? (
<p className={`text-sm ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>Noch kein Worker gemeldet startet gerade?</p>
<label className="flex items-start gap-3 mb-3 text-sm text-slate-700 dark:text-slate-300">
<input
type="checkbox"
checked={transcodeEnabled}
onChange={e => setTranscodeEnabled(e.target.checked)}
className="w-4 h-4 mt-0.5 accent-amber-500 rounded"
/>
<span>
Nach dem Rip auf Arbeitsgröße komprimieren
<span className="block text-xs text-slate-500 dark:text-slate-400">
Empfohlen ohne Kompression braucht jede Blu-ray rund 40 GB.
</span>
</span>
</label>
{transcodeEnabled && (
<div className={`rounded-xl p-4 border ${
schwach
? 'bg-amber-500/10 border-amber-500/30'
: 'bg-slate-50 dark:bg-slate-950/80 border-slate-200 dark:border-slate-800'
}`}>
{/* Der Kern dieser Seite: Die Empfehlung folgt der GEMESSENEN
Rechenleistung. Vorher stand hier H.265 als Standard - auf
einer CPU ohne AVX2 sind das 28-55 Stunden je 4K-Film, und
genau das ist am 25.07.2026 passiert. */}
{schwach ? (
<>
<p className="text-sm font-medium flex items-start gap-2 text-amber-700 dark:text-amber-300">
<AlertTriangle size={16} className="mt-0.5 flex-shrink-0" />
<span>Rippy hat deine Rechenleistung gemessen und passt die Wahl an.</span>
</p>
<p className="text-xs mt-2 text-amber-700/90 dark:text-amber-300/90">
{betrieb.kann.externe_worker ? 'Keiner deiner Worker' : 'Dieser Rechner'} kann kein AVX2 die Vektorbefehle, von denen H.265
lebt. 4K in H.265 würde hier <strong>ein bis zwei Tage pro Film</strong>
{' '}dauern. Deshalb wird eingestellt:
</p>
</>
) : presetInfo && presetInfo.hardware.length > 0 ? (
<p className="text-sm font-medium text-slate-700 dark:text-slate-300">
Hardware-Encoder gemeldet ({presetInfo.hardware.join(', ')}) Rippy nimmt ihn:
</p>
) : (
workers.map(w => (
<div key={w.name} className="mb-1">
<span className={`text-xs font-mono ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>{w.name}: </span>
{w.encoders.map(e => (
<span key={e} className={`inline-block text-xs px-2 py-0.5 rounded mr-1 ${e.startsWith('cpu') ? (theme === 'dark' ? 'bg-slate-700 text-slate-300' : 'bg-slate-200 text-slate-600') : 'bg-emerald-600/20 text-emerald-500 font-medium'}`}>
<p className="text-sm font-medium text-slate-700 dark:text-slate-300">
Deine Worker sind schnell genug für H.265 Rippy stellt ein:
</p>
)}
<ul className="mt-2 space-y-1 text-xs text-slate-600 dark:text-slate-400">
<li>
<strong>4K-UHD:</strong>{' '}
{presets.transcodePresetUhd === PRESET_KEINE
? 'nicht komprimieren, verlustfrei behalten (20100 GB je Film)'
: presets.transcodePresetUhd || 'unverändert (kein bekanntes Preset gemeldet)'}
</li>
<li>
<strong>Blu-ray:</strong>{' '}
{presets.transcodePresetBluray || 'unverändert (kein bekanntes Preset gemeldet)'}
</li>
<li>
<strong>DVD:</strong>{' '}
{presets.transcodePresetDvd || 'unverändert (kein bekanntes Preset gemeldet)'}
</li>
</ul>
{presetInfo?.typen?.uhd?.empfehlung?.grund && (
<p className="mt-2 text-xs text-slate-500 dark:text-slate-400">
Warum: {presetInfo.typen.uhd.empfehlung.grund}
</p>
)}
<p className="mt-2 text-xs text-slate-500 dark:text-slate-400">
Alles einzeln änderbar unter Einstellungen Verarbeitung.
</p>
</div>
)}
{encoderWorker.length > 0 && (
<div className="mt-3 flex flex-wrap gap-1">
{encoderWorker.flatMap(w => w.encoders).filter((e, i, a) => a.indexOf(e) === i).map(e => (
<span key={e} className={`text-xs px-2 py-0.5 rounded font-medium ${
e.startsWith('cpu')
? 'bg-slate-200 dark:bg-slate-800 text-slate-600 dark:text-slate-300'
: 'bg-emerald-500/15 text-emerald-600 dark:text-emerald-400'
}`}>
{ENCODER_LABELS[e] || e}
</span>
))}
</div>
))
)}
<p className={`text-xs mt-2 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
Tipp: GPU-Maschinen im Netz können als optionale Transcode-Worker angebunden werden (siehe README).
</p>
</div>
<label className={`flex items-center gap-3 mb-3 text-sm ${theme === 'dark' ? 'text-slate-300' : 'text-slate-700'}`}>
<input type="checkbox" checked={transcodeEnabled} onChange={e => setTranscodeEnabled(e.target.checked)} className="w-4 h-4 accent-indigo-600" />
Nach dem Rip auf Arbeitsgröße komprimieren (empfohlen sonst ~40 GB pro Blu-ray)
</label>
{transcodeEnabled && (
<select value={preset} onChange={e => setPreset(e.target.value)} className={feldKlasse}>
<option value="H.265 MKV 1080p30">H.265 klein &amp; modern (Standard)</option>
<option value="HQ 1080p30 Surround">H.264 schneller auf schwacher CPU, etwas größer</option>
</select>
)}
</section>
{error && <p className="text-sm text-rose-500">{error}</p>}
{keyWarnung && (
<div className="p-4 rounded-xl bg-amber-500/10 border border-amber-500/30">
<p className="text-sm text-amber-700 dark:text-amber-300">{keyWarnung}</p>
<div className="flex gap-2 mt-3">
<Button variant="secondary" size="sm" onClick={() => setKeyWarnung(null)}>
Key korrigieren
</Button>
<Button variant="secondary" size="sm" onClick={trotzdemWeiter} disabled={saving}>
Trotzdem fertigstellen
</Button>
</div>
</div>
)}
<button
{error && (
<p className="text-sm p-3 rounded-lg bg-rose-500/10 border border-rose-500/30 text-rose-600 dark:text-rose-400">
{error}
</p>
)}
<Button
variant="amber"
size="lg"
onClick={abschliessen}
disabled={saving}
className="w-full flex items-center justify-center gap-2 px-6 py-3 bg-indigo-600 text-white rounded-lg font-medium hover:bg-indigo-700 transition-colors disabled:opacity-50"
className="w-full"
>
{saving ? 'Speichern…' : <>Los geht's <ArrowRight size={18} /></>}
</button>
</Button>
<p className={`text-xs text-center flex items-center justify-center gap-1 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
<p className="text-xs text-center flex items-center justify-center gap-1 text-slate-500 dark:text-slate-400">
<CheckCircle size={12} /> Läuft komplett lokal keine Cloud, keine Telemetrie.
</p>
</div>
@@ -190,3 +453,34 @@ export default function FirstRunWizard({ onDone }: { onDone: () => void }) {
</div>
)
}
/** Eine Zeile im Was Rippy gerade sieht"-Kasten: gruen, wenn es passt, sonst
* bernstein MIT Handlungsanweisung. Nie nur ein Kreuz ohne Erklaerung. */
function Zeile({ titel, geladen, gut, gutText, schlechtText }: {
titel: string
geladen: boolean
gut: boolean
gutText: string
schlechtText: string
}) {
if (!geladen) {
return (
<div className="flex items-center gap-3 p-3">
<span className="w-2 h-2 rounded-full bg-slate-300 dark:bg-slate-600 animate-pulse flex-shrink-0" />
<span className="text-sm text-slate-500 dark:text-slate-400">{titel} wird geprüft</span>
</div>
)
}
return (
<div className="flex items-start gap-3 p-3">
<span className={`w-2 h-2 mt-1.5 rounded-full flex-shrink-0 ${gut ? 'bg-emerald-500' : 'bg-amber-500'}`} />
<div className="min-w-0">
<p className="text-sm text-slate-700 dark:text-slate-300">
<span className="font-medium">{titel}:</span>{' '}
{gut ? gutText : <span className="text-amber-600 dark:text-amber-400">nicht bereit</span>}
</p>
{!gut && <p className="text-xs mt-0.5 text-amber-700/90 dark:text-amber-300/90">{schlechtText}</p>}
</div>
</div>
)
}
@@ -0,0 +1,218 @@
import { Disc, Sparkles, CheckCircle, Shield, Zap, Tv, HardDrive } from 'lucide-react'
import { RadialProgress } from './ui/RadialProgress'
import { TypeBadge, StatusBadge } from './ui/Badge'
import { Button } from './ui/Button'
interface JobMeta {
year?: number
overview?: string
poster_path?: string
genres?: string[]
runtime?: number
type?: string
source?: string
}
interface Job {
id: string
type: 'cd' | 'dvd' | 'bluray' | 'uhd'
status: 'pending' | 'processing' | 'transcoding' | 'canceling' | 'completed' | 'failed'
device: string
startTime: string
endTime?: string
progress: number
title?: string
can_retry?: boolean
meta?: JobMeta | null
}
function posterUrl(meta?: JobMeta | null): string | null {
const p = meta?.poster_path
if (!p) return null
return p.startsWith('http') ? p : `https://image.tmdb.org/t/p/w500${p}`
}
interface HeroCinemaBannerProps {
aktiverJob?: Job | null
completedJobs?: Job[]
onDetailClick?: (jobId: string) => void
onCancelClick?: (jobId: string) => void
}
export function HeroCinemaBanner({
aktiverJob,
completedJobs = [],
onDetailClick,
onCancelClick,
}: HeroCinemaBannerProps) {
// Fall 1: Aktiver Job (Rippt oder Komprimiert live)
if (aktiverJob) {
const isTranscoding = aktiverJob.status === 'transcoding'
const statusText = isTranscoding ? 'HandBrake Kompression' : 'MakeMKV Extraktion'
const poster = posterUrl(aktiverJob.meta)
return (
<div className="relative rounded-3xl overflow-hidden border-2 border-amber-500/50 bg-gradient-to-r from-slate-950 via-slate-900 to-indigo-950 p-6 md:p-8 shadow-[0_0_50px_-10px_rgba(245,158,11,0.35)] text-slate-100 mb-8">
<div className="relative z-10 flex flex-col lg:flex-row items-center justify-between gap-8">
<div className="flex items-center gap-6">
<div className="relative flex-shrink-0">
{poster ? (
<div className="relative">
<img src={poster} alt="" className="w-28 h-40 rounded-2xl object-cover shadow-2xl border-2 border-amber-500/40" />
<div className="absolute -bottom-3 -right-3 w-14 h-14 rounded-full disc-texture shadow-xl flex items-center justify-center animate-disc-spin border border-amber-400">
<Disc size={20} className="text-amber-400" />
</div>
</div>
) : (
<div className="w-28 h-28 rounded-full disc-texture shadow-2xl flex items-center justify-center p-1.5 animate-disc-spin border-2 border-amber-500/60">
<div className="w-full h-full rounded-full border-2 border-dashed border-white/40 flex items-center justify-center bg-slate-950/70">
<Disc size={40} className="text-amber-400 drop-shadow-[0_0_15px_rgba(245,158,11,0.8)]" />
</div>
</div>
)}
</div>
<div className="space-y-2 text-center sm:text-left">
<div className="flex items-center justify-center sm:justify-start gap-2 flex-wrap">
<span className="px-3 py-1 rounded-full text-xs font-bold uppercase tracking-wider bg-amber-500 text-slate-950 shadow-md">
NOW RIPPING
</span>
<TypeBadge type={aktiverJob.type} />
<StatusBadge status={aktiverJob.status} />
</div>
<h2 className="text-2xl md:text-3xl font-extrabold tracking-tight bg-gradient-to-r from-white via-slate-100 to-amber-200 bg-clip-text text-transparent">
{aktiverJob.title || 'Aktiver Ripping-Prozess'}
</h2>
<p className="text-xs text-slate-400 font-mono">
Laufwerk: <strong className="text-amber-400">{aktiverJob.device}</strong> · {statusText}
</p>
</div>
</div>
<div className="flex flex-col sm:flex-row items-center gap-6 flex-shrink-0 w-full lg:w-auto justify-end">
<RadialProgress progress={aktiverJob.progress} size={96} strokeWidth={8} label="PROGRESS" />
<div className="flex flex-col gap-2 w-full sm:w-auto">
<Button variant="amber" size="md" onClick={() => onDetailClick && onDetailClick(aktiverJob.id)}>
<Sparkles size={16} /> Details
</Button>
<Button variant="danger" size="md" onClick={() => onCancelClick && onCancelClick(aktiverJob.id)}>
Abbrechen
</Button>
</div>
</div>
</div>
</div>
)
}
// Fall 2: Kein aktiver Job -> 5-Panel Kachel-Galerie VOLLSTÄNDIG ausfüllen (Zero "Löcher"!)
// Wir füllen freie Slots mit informativen Cinema-Engine-Showcase-Kacheln auf!
const realMovieTiles = completedJobs.slice(0, 4)
return (
<div className="relative rounded-3xl overflow-hidden border border-amber-500/30 bg-[#0e1322] shadow-[0_0_40px_-5px_rgba(245,158,11,0.18)] mb-8 p-3">
{/* Top Subtle Amber Line */}
<div className="absolute top-0 inset-x-0 h-px bg-gradient-to-r from-transparent via-amber-500/40 to-transparent pointer-events-none" />
<div className="grid grid-cols-2 md:grid-cols-5 gap-3 h-44 md:h-52">
{/* Echte Medien-Kacheln aus der API */}
{realMovieTiles.map((job) => {
const poster = posterUrl(job.meta)
return (
<div
key={job.id}
onClick={() => onDetailClick && onDetailClick(job.id)}
className="relative rounded-2xl overflow-hidden group cursor-pointer border border-slate-800 hover:border-amber-500/50 transition-all bg-slate-900 flex flex-col justify-end p-3"
>
{poster ? (
<img
src={poster}
alt={job.title || ''}
className="absolute inset-0 w-full h-full object-cover group-hover:scale-105 transition-transform duration-500"
/>
) : (
<div className="absolute inset-0 bg-gradient-to-br from-slate-800 via-slate-900 to-slate-950 flex flex-col items-center justify-center p-3 text-center">
<Disc size={32} className="text-amber-400 mb-2" />
<span className="text-[10px] font-bold text-slate-400 uppercase">{job.type}</span>
</div>
)}
<div className="absolute inset-0 bg-gradient-to-t from-slate-950 via-slate-950/40 to-transparent" />
<div className="relative z-10 space-y-1">
<TypeBadge type={job.type} />
<h4 className="text-xs font-bold text-slate-100 truncate group-hover:text-amber-400 transition-colors">
{job.title || 'Unbekannt'}
</h4>
</div>
</div>
)
})}
{/* Center / Showcase Feature Tile: 3D Spinning Optical Disc */}
{realMovieTiles.length < 5 && (
<div className="relative rounded-2xl overflow-hidden bg-gradient-to-br from-slate-900 via-[#131929] to-slate-950 border-2 border-amber-500/40 flex items-center justify-center p-4 shadow-inner group">
<div className="w-28 h-28 md:w-32 md:h-32 rounded-full disc-texture shadow-2xl shadow-black flex items-center justify-center p-1.5 animate-disc-spin border-2 border-amber-400/60">
<div className="w-full h-full rounded-full border-2 border-dashed border-white/40 flex items-center justify-center bg-slate-950/70">
<Disc size={40} className="text-amber-400 drop-shadow-[0_0_16px_rgba(245,158,11,0.9)]" />
</div>
</div>
<div className="absolute bottom-2.5 px-3 py-0.5 rounded-full text-[10px] font-extrabold uppercase tracking-widest bg-amber-500 text-slate-950 shadow-md">
DISC ENGINE
</div>
</div>
)}
{/* Dynamic Engine Tile: Drive Status */}
{realMovieTiles.length < 4 && (
<div className="relative rounded-2xl overflow-hidden bg-gradient-to-br from-slate-900 to-indigo-950/80 border border-slate-800 flex flex-col justify-between p-4 hidden md:flex">
<div className="flex items-center gap-2 text-emerald-400 text-xs font-bold">
<CheckCircle size={14} /> DRIVE READY
</div>
<div>
<h4 className="text-sm font-bold text-slate-100">Automatische Erkennung</h4>
<p className="text-[11px] text-slate-400 mt-0.5">Lege eine Disc ein Rippy rippt sofort los.</p>
</div>
<div className="text-[10px] font-mono text-amber-400 font-bold">
4K UHD · BLU-RAY · DVD · CD
</div>
</div>
)}
{/* Dynamic Engine Tile: Media-Server Sync */}
{realMovieTiles.length < 3 && (
<div className="relative rounded-2xl overflow-hidden bg-gradient-to-br from-slate-900 to-slate-950 border border-slate-800 flex flex-col justify-between p-4 hidden md:flex">
<div className="flex items-center gap-2 text-amber-400 text-xs font-bold">
<Tv size={14} /> MEDIA SERVER
</div>
<div>
<h4 className="text-sm font-bold text-slate-100">Auto-NFO &amp; Poster</h4>
<p className="text-[11px] text-slate-400 mt-0.5">Jellyfin, Plex &amp; Kodi kompatibel.</p>
</div>
<div className="text-[10px] font-mono text-slate-400">
Auto-Scan nach Rip
</div>
</div>
)}
{/* Dynamic Engine Tile: Lossless Assurance */}
{realMovieTiles.length < 2 && (
<div className="relative rounded-2xl overflow-hidden bg-gradient-to-br from-slate-900 to-slate-950 border border-slate-800 flex flex-col justify-between p-4 hidden md:flex">
<div className="flex items-center gap-2 text-indigo-400 text-xs font-bold">
<Shield size={14} /> MakeMKV
</div>
<div>
<h4 className="text-sm font-bold text-slate-100">Lossless 1:1</h4>
<p className="text-[11px] text-slate-400 mt-0.5">Alle Tonspuren &amp; Subtitles erhalten.</p>
</div>
<div className="text-[10px] font-mono text-slate-400">
x265 HandBrake Kompression
</div>
</div>
)}
</div>
</div>
)
}
+105 -59
View File
@@ -1,11 +1,9 @@
import { useState, useEffect } from 'react'
import { X, Film, Loader2, FolderOpen, AlertCircle } from 'lucide-react'
import { Film, Loader2, FolderOpen, AlertCircle, Download } from 'lucide-react'
import { api } from '../lib/api'
import { useDarkMode } from '../context/ThemeContext'
// Klick auf den Titel in „Neueste Jobs" (Commander-Wunsch 24.07.): sofort
// sehen, WAS da gerippt wurde — Poster, Jahr, Beschreibung — plus die
// nüchternen Job-Fakten (Ziel, Ausgabepfad, Fehler).
import { Modal } from './ui/Modal'
import { Button } from './ui/Button'
import { StatusBadge } from './ui/Badge'
interface JobMeta {
year?: number
@@ -32,35 +30,38 @@ interface JobDetail {
meta?: JobMeta | null
}
// TMDB liefert relative Poster-Pfade, OMDb/Jikan absolute URLs
function posterUrl(meta?: JobMeta | null): string | null {
const p = meta?.poster_path
if (!p) return null
return p.startsWith('http') ? p : `https://image.tmdb.org/t/p/w342${p}`
}
const STATUS_LABEL: Record<string, string> = {
pending: 'Wartend',
processing: 'Rippen',
transcoding: 'Komprimieren',
canceling: 'Wird abgebrochen…',
completed: 'Fertig',
failed: 'Fehler',
interface JobDatei {
name: string
size_mb: number | null
}
export default function JobDetailModal({ jobId, onClose }: { jobId: string | null, onClose: () => void }) {
const [detail, setDetail] = useState<JobDetail | null>(null)
const [dateien, setDateien] = useState<JobDatei[] | null>(null)
const [laedt, setLaedt] = useState(false)
const { theme } = useDarkMode()
useEffect(() => {
if (!jobId) {
setDetail(null)
setDateien(null)
return
}
setLaedt(true)
api.get(`/jobs/${jobId}/detail`)
.then(r => setDetail(r.data))
.then(r => {
setDetail(r.data)
if (r.data?.status === 'completed') {
api.get(`/jobs/${jobId}/files`)
.then(f => setDateien(f.data.files))
.catch(() => setDateien(null))
}
})
.catch(() => setDetail(null))
.finally(() => setLaedt(false))
}, [jobId])
@@ -71,45 +72,40 @@ export default function JobDetailModal({ jobId, onClose }: { jobId: string | nul
const poster = posterUrl(meta)
return (
<div className="fixed inset-0 z-50 flex items-center justify-center p-4 bg-black/50 backdrop-blur-sm" onClick={onClose}>
<div
className={`w-full max-w-2xl max-h-[85vh] overflow-y-auto rounded-xl shadow-2xl ${theme === 'dark' ? 'bg-slate-800' : 'bg-white'}`}
onClick={e => e.stopPropagation()}
<Modal
isOpen={!!jobId}
onClose={onClose}
title={detail?.title || 'Job-Details'}
maxWidth="2xl"
>
<div className={`px-6 py-4 border-b flex items-center justify-between ${theme === 'dark' ? 'border-slate-700' : 'border-slate-200'}`}>
<h2 className={`text-lg font-bold truncate ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>
{detail?.title || 'Job-Details'}
</h2>
<button onClick={onClose} className={`p-1.5 rounded flex-shrink-0 ${theme === 'dark' ? 'hover:bg-slate-700 text-slate-400' : 'hover:bg-slate-100 text-slate-500'}`}>
<X size={18} />
</button>
</div>
{laedt ? (
<div className="flex items-center justify-center py-16">
<Loader2 className="animate-spin text-indigo-500" size={28} />
<Loader2 className="animate-spin text-amber-500" size={28} />
</div>
) : !detail ? (
<p className={`px-6 py-10 text-sm text-center ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>
<p className="px-6 py-10 text-sm text-center text-slate-500 dark:text-slate-400">
Job nicht gefunden.
</p>
) : (
<div className="p-6 space-y-5">
<div className="space-y-6">
{/* Film/Serien-Info aus der Disc-Erkennung */}
<div className="flex gap-5">
{poster ? (
<img src={poster} alt={detail.title || ''} className="w-32 rounded-lg object-cover flex-shrink-0 shadow-lg" />
<img src={poster} alt={detail.title || ''} className="w-32 rounded-xl object-cover flex-shrink-0 shadow-lg shadow-black/30 border border-slate-700/50" />
) : (
<div className={`w-32 h-48 rounded-lg flex items-center justify-center flex-shrink-0 ${theme === 'dark' ? 'bg-slate-900 text-slate-600' : 'bg-slate-100 text-slate-400'}`}>
<Film size={32} />
<div className="w-32 h-48 rounded-xl flex items-center justify-center flex-shrink-0 bg-slate-100 dark:bg-slate-800 text-slate-400 dark:text-slate-500 border border-slate-200 dark:border-slate-700">
<Film size={36} />
</div>
)}
<div className="min-w-0">
<p className={`text-xl font-bold ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>
<div className="min-w-0 flex-1">
<div className="flex items-center gap-2 flex-wrap">
<h3 className="text-xl font-bold text-slate-900 dark:text-slate-100">
{detail.title || 'Unbekannt'}
{meta?.year ? <span className={`font-normal ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}> ({meta.year})</span> : null}
</p>
<p className={`text-xs mt-1 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
{meta?.year ? <span className="font-normal text-slate-500 dark:text-slate-400"> ({meta.year})</span> : null}
</h3>
<StatusBadge status={detail.status} />
</div>
<p className="text-xs mt-1 text-slate-500 dark:text-slate-400">
{meta?.type === 'tv' ? 'Serie' : 'Film'}
{meta?.source ? ` · Quelle: ${meta.source}` : ''}
{meta?.runtime ? ` · ${meta.runtime} min` : ''}
@@ -117,57 +113,107 @@ export default function JobDetailModal({ jobId, onClose }: { jobId: string | nul
{meta?.genres && meta.genres.length > 0 && (
<div className="flex flex-wrap gap-1.5 mt-2">
{meta.genres.map(g => (
<span key={g} className={`text-xs px-2 py-0.5 rounded-full ${theme === 'dark' ? 'bg-slate-700 text-slate-300' : 'bg-slate-100 text-slate-600'}`}>{g}</span>
<span key={g} className="text-xs px-2.5 py-0.5 rounded-full bg-slate-100 dark:bg-slate-800 text-slate-700 dark:text-slate-300 border border-slate-200 dark:border-slate-700">
{g}
</span>
))}
</div>
)}
{meta?.overview ? (
<p className={`text-sm mt-3 leading-relaxed ${theme === 'dark' ? 'text-slate-300' : 'text-slate-600'}`}>
<p className="text-sm mt-3 leading-relaxed text-slate-600 dark:text-slate-300 line-clamp-4">
{meta.overview}
</p>
) : (
<p className={`text-sm mt-3 italic ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
<p className="text-sm mt-3 italic text-slate-400 dark:text-slate-500">
Keine Metadaten zu diesem Job gespeichert die Disc wurde ohne Erkennung gerippt.
</p>
)}
</div>
</div>
{/* Nüchterne Job-Fakten */}
<div className={`rounded-lg p-4 grid grid-cols-[auto_1fr] gap-x-6 gap-y-1.5 text-sm ${theme === 'dark' ? 'bg-slate-900' : 'bg-slate-50'}`}>
<span className={theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}>Status</span>
<span className={theme === 'dark' ? 'text-slate-200' : 'text-slate-700'}>
{STATUS_LABEL[detail.status] || detail.status}{detail.progress > 0 && detail.progress < 100 ? ` · ${detail.progress} %` : ''}
{/* Job-Fakten Grid */}
<div className="rounded-xl p-4 grid grid-cols-[auto_1fr] gap-x-6 gap-y-2 text-sm bg-slate-50 dark:bg-slate-950/80 border border-slate-200/80 dark:border-slate-800">
<span className="text-slate-500 dark:text-slate-400 font-medium">Status</span>
<span className="text-slate-900 dark:text-slate-200">
{detail.status}{detail.progress > 0 && detail.progress < 100 ? ` · ${detail.progress} %` : ''}
</span>
<span className={theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}>Laufwerk</span>
<span className={`font-mono text-xs self-center ${theme === 'dark' ? 'text-slate-200' : 'text-slate-700'}`}>{detail.device || '—'}</span>
<span className={theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}>Gestartet</span>
<span className={theme === 'dark' ? 'text-slate-200' : 'text-slate-700'}>
<span className="text-slate-500 dark:text-slate-400 font-medium">Laufwerk</span>
<span className="font-mono text-xs self-center text-slate-900 dark:text-slate-200">{detail.device || '—'}</span>
<span className="text-slate-500 dark:text-slate-400 font-medium">Gestartet</span>
<span className="text-slate-900 dark:text-slate-200">
{detail.startTime ? new Date(detail.startTime).toLocaleString('de-DE') : '—'}
</span>
<span className={theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}>Beendet</span>
<span className={theme === 'dark' ? 'text-slate-200' : 'text-slate-700'}>
<span className="text-slate-500 dark:text-slate-400 font-medium">Beendet</span>
<span className="text-slate-900 dark:text-slate-200">
{detail.endTime ? new Date(detail.endTime).toLocaleString('de-DE') : '—'}
</span>
{(detail.output_path || detail.target_dir) && (
<>
<span className={`flex items-center gap-1 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}><FolderOpen size={13} /> Ablage</span>
<span className={`font-mono text-xs self-center break-all ${theme === 'dark' ? 'text-slate-200' : 'text-slate-700'}`}>
<span className="flex items-center gap-1 text-slate-500 dark:text-slate-400 font-medium"><FolderOpen size={13} /> Ablage</span>
<span className="font-mono text-xs self-center break-all text-slate-900 dark:text-slate-200">
{detail.output_path || detail.target_dir}
</span>
</>
)}
</div>
{/* Dateiliste & Download */}
{detail.status === 'completed' && dateien && dateien.length > 0 && (
<div className="rounded-xl p-4 bg-slate-50 dark:bg-slate-950/80 border border-slate-200/80 dark:border-slate-800">
<div className="flex items-center justify-between mb-3">
<p className="text-sm font-medium flex items-center gap-2 text-slate-900 dark:text-slate-200">
<Download size={15} className="text-amber-500" /> Dateien herunterladen
</p>
{dateien.length > 1 && (
<Button
variant="amber"
size="sm"
onClick={() => {
dateien.forEach((f, i) => {
setTimeout(() => {
const a = document.createElement('a')
a.href = `/api/jobs/${detail.id}/files/${encodeURIComponent(f.name)}`
a.download = f.name
document.body.appendChild(a)
a.click()
a.remove()
}, i * 400)
})
}}
>
Alle herunterladen ({dateien.length})
</Button>
)}
</div>
<div className="space-y-1.5">
{dateien.map(f => (
<a
key={f.name}
href={`/api/jobs/${detail.id}/files/${encodeURIComponent(f.name)}`}
download
className="flex items-center gap-2 px-3 py-2 rounded-lg text-sm transition-colors text-amber-600 dark:text-amber-300 hover:bg-slate-100 dark:hover:bg-slate-800"
>
<Download size={14} className="flex-shrink-0" />
<span className="truncate min-w-0">{f.name}</span>
{f.size_mb != null && (
<span className="ml-auto text-xs flex-shrink-0 text-slate-500 dark:text-slate-400 font-mono">
{f.size_mb >= 1024 ? `${(f.size_mb / 1024).toFixed(1)} GB` : `${f.size_mb} MB`}
</span>
)}
</a>
))}
</div>
</div>
)}
{detail.error && (
<div className={`rounded-lg p-4 flex items-start gap-2.5 text-sm ${theme === 'dark' ? 'bg-rose-900/30 text-rose-300' : 'bg-rose-50 text-rose-700'}`}>
<div className="rounded-xl p-4 flex items-start gap-2.5 text-sm bg-rose-500/10 border border-rose-500/20 text-rose-600 dark:text-rose-400">
<AlertCircle size={16} className="flex-shrink-0 mt-0.5" />
<span className="break-words min-w-0">{detail.error}</span>
</div>
)}
</div>
)}
</div>
</div>
</Modal>
)
}
+42 -71
View File
@@ -1,7 +1,6 @@
import { useState, useEffect } from 'react'
import { Terminal, Play, CheckCircle, AlertCircle } from 'lucide-react'
import { api } from '../lib/api'
import { useDarkMode } from '../context/ThemeContext'
import { Card, CardHeader, CardTitle } from './ui/Card'
import { useStrom } from '../lib/useEventStream'
interface LiveLogEntry {
id: string
@@ -12,88 +11,62 @@ interface LiveLogEntry {
}
export default function LiveLogSection() {
const [logs, setLogs] = useState<LiveLogEntry[]>([])
const [currentJob, setCurrentJob] = useState<any>(null)
const { theme } = useDarkMode()
useEffect(() => {
const fetchJobs = async () => {
try {
const response = await api.get('/jobs')
const jobs = response.data
const current = jobs.find((j: any) => j.status === 'processing' || j.status === 'transcoding')
setCurrentJob(current || jobs.find((j: any) => j.status === 'pending'))
} catch (error) {
console.error('Fehler beim Laden der Jobs:', error)
}
}
const fetchLogs = async () => {
try {
const response = await api.get('/logs', { params: { limit: 50 } })
setLogs(response.data)
} catch (error) {
console.error('Fehler beim Laden der Logs:', error)
}
}
fetchJobs()
fetchLogs()
const jobInterval = setInterval(fetchJobs, 5000)
const logInterval = setInterval(fetchLogs, 5000)
return () => {
clearInterval(jobInterval)
clearInterval(logInterval)
}
}, [])
// Vorher: zwei eigene Taktgeber (alle 5 s /jobs und /logs) = 24 Anfragen pro
// Minute allein aus diesem Kasten. Jetzt kommt beides aus der einen offenen
// Verbindung, die der Provider haelt.
const { jobs, logs } = useStrom()
const currentJob =
jobs.find((j: any) => j.status === 'processing' || j.status === 'transcoding') ||
jobs.find((j: any) => j.status === 'pending') ||
null
const getStatusColor = (level: string) => {
switch (level) {
case 'error': return 'text-rose-500'
case 'warning': return 'text-amber-500'
case 'success': return 'text-emerald-500'
default: return 'text-blue-500'
case 'error': return 'text-rose-500 dark:text-rose-400'
case 'warning': return 'text-amber-500 dark:text-amber-400'
case 'success': return 'text-emerald-500 dark:text-emerald-400'
default: return 'text-sky-500 dark:text-sky-400'
}
}
const getStatusIcon = (level: string) => {
switch (level) {
case 'error': return <AlertCircle size={16} />
case 'warning': return <AlertCircle size={16} />
case 'success': return <CheckCircle size={16} />
default: return <Terminal size={16} />
case 'error': return <AlertCircle size={15} />
case 'warning': return <AlertCircle size={15} />
case 'success': return <CheckCircle size={15} />
default: return <Terminal size={15} />
}
}
return (
<div className={`rounded-xl shadow-sm border overflow-hidden transition-colors duration-300 ${theme === 'dark' ? 'bg-slate-800 border-slate-700' : 'bg-white border-slate-200'}`}>
<div className={`px-6 py-4 border-b transition-colors duration-300 ${theme === 'dark' ? 'border-slate-700' : 'border-slate-200'} flex items-center justify-between`}>
<Card className="overflow-hidden">
<CardHeader>
<div>
<h2 className={`text-lg font-semibold ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>Live-Log</h2>
<p className={`text-sm ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>
<CardTitle>Live-Log</CardTitle>
<p className="text-sm text-slate-500 dark:text-slate-400">
{currentJob
? `Aktiver Job: ${currentJob.type.toUpperCase()} (${currentJob.progress}%)`
// `type?.` ist hier kein Beiwerk: Ein frisch angelegter Job kann
// noch ohne Typ ankommen, und ohne das Fragezeichen riss diese
// eine Zeile am 29.08.2026 die GANZE Oberflaeche mit.
? `Aktiver Job: ${currentJob.type?.toUpperCase() || 'Disc'} (${currentJob.progress ?? 0}%)`
: 'Kein aktiver Job'}
</p>
</div>
{currentJob && (
<div className="flex items-center gap-2">
<div className={`px-3 py-1 rounded-full text-xs font-medium flex items-center gap-2 ${
<div className={`px-3 py-1 rounded-full text-xs font-medium flex items-center gap-2 border ${
currentJob.progress === 100
? theme === 'dark' ? 'bg-emerald-900/30 text-emerald-400' : 'bg-emerald-100 text-emerald-700'
: theme === 'dark' ? 'bg-blue-900/30 text-blue-400' : 'bg-blue-100 text-blue-700'
? 'bg-emerald-500/15 text-emerald-600 dark:text-emerald-400 border-emerald-500/30'
: 'bg-sky-500/15 text-sky-600 dark:text-sky-400 border-sky-500/30'
}`}>
{currentJob.progress === 100 ? <CheckCircle size={12} /> : <Play size={12} />}
{currentJob.progress}%
</div>
</div>
)}
</div>
</CardHeader>
<div className={`max-h-[400px] overflow-y-auto p-4 space-y-2 transition-colors duration-300 font-mono text-xs ${
theme === 'dark' ? 'bg-slate-900' : 'bg-slate-50'
}`}>
<div className="max-h-[380px] overflow-y-auto p-4 space-y-2 font-mono text-xs bg-slate-900/90 text-slate-200 border-b border-slate-800">
{logs.length === 0 ? (
<div className="text-center py-8 text-slate-500">
<Terminal size={32} className="mx-auto mb-2 opacity-50" />
@@ -101,14 +74,14 @@ export default function LiveLogSection() {
</div>
) : (
logs.map((log) => (
<div key={log.id} className={`flex items-start gap-2 ${theme === 'dark' ? 'text-slate-300' : 'text-slate-700'}`}>
<div key={log.id} className="flex items-start gap-2 text-slate-300">
<span className="text-slate-500 whitespace-nowrap">
{new Date(log.timestamp).toLocaleTimeString('de-DE', { hour12: false })}
</span>
<span className={`font-bold ${getStatusColor(log.level)}`}>
[{log.source}]
</span>
<span className="flex-1">{log.message}</span>
<span className="flex-1 text-slate-200">{log.message}</span>
<span className={getStatusColor(log.level)}>
{getStatusIcon(log.level)}
</span>
@@ -118,30 +91,28 @@ export default function LiveLogSection() {
</div>
{/* Quick Stats */}
<div className={`px-6 py-3 border-t transition-colors duration-300 ${theme === 'dark' ? 'border-slate-700' : 'border-slate-200'} grid grid-cols-3 gap-4`}>
{currentJob && (
<>
<div className="px-6 py-3 grid grid-cols-3 gap-4 bg-slate-50/50 dark:bg-slate-900/50">
<div>
<p className={`text-xs ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>Fortschritt</p>
<p className={`text-lg font-bold ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>
<p className="text-xs text-slate-500 dark:text-slate-400">Fortschritt</p>
<p className="text-lg font-bold text-slate-900 dark:text-slate-100">
{currentJob.progress}%
</p>
</div>
<div>
<p className={`text-xs ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>Gerät</p>
<p className={`text-sm font-medium ${theme === 'dark' ? 'text-slate-300' : 'text-slate-700'}`}>
<p className="text-xs text-slate-500 dark:text-slate-400">Gerät</p>
<p className="text-sm font-medium text-slate-700 dark:text-slate-300">
{currentJob.device || 'Unbekannt'}
</p>
</div>
<div>
<p className={`text-xs ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>Typ</p>
<p className={`text-sm font-medium ${theme === 'dark' ? 'text-slate-300' : 'text-slate-700'}`}>
<p className="text-xs text-slate-500 dark:text-slate-400">Typ</p>
<p className="text-sm font-medium text-slate-700 dark:text-slate-300">
{currentJob.type?.toUpperCase() || 'Unbekannt'}
</p>
</div>
</>
</div>
)}
</div>
</div>
</Card>
)
}
+30 -37
View File
@@ -1,11 +1,9 @@
import { useState, useEffect } from 'react'
import { Search, Loader2, X, Film } from 'lucide-react'
import { Search, Loader2, Film } from 'lucide-react'
import { api } from '../lib/api'
import { useDarkMode } from '../context/ThemeContext'
// „Nicht korrekt?!"-Popup (Commander-Wunsch 23.07.): Korrektur direkt am
// Dashboard — suchen, richtigen Treffer anklicken, Rippy merkt sich die Wahl
// für diese Disc (30 Tage, per Disc-Fingerabdruck).
import { Modal } from './ui/Modal'
import { Button } from './ui/Button'
import { Input } from './ui/Input'
interface SuchKandidat {
title: string
@@ -30,7 +28,6 @@ export default function MetadataKorrektur({ devicePath, vorschlag, isOpen, onClo
const [kandidaten, setKandidaten] = useState<SuchKandidat[]>([])
const [laeuft, setLaeuft] = useState(false)
const [fehler, setFehler] = useState<string | null>(null)
const { theme } = useDarkMode()
useEffect(() => {
if (isOpen) {
@@ -74,63 +71,60 @@ export default function MetadataKorrektur({ devicePath, vorschlag, isOpen, onClo
}
}
if (!isOpen) return null
return (
<div className="fixed inset-0 z-50 flex items-center justify-center p-4 bg-black/50 backdrop-blur-sm">
<div className={`w-full max-w-2xl max-h-[85vh] flex flex-col rounded-xl shadow-2xl ${theme === 'dark' ? 'bg-slate-800' : 'bg-white'}`}>
<div className={`px-6 py-4 border-b flex items-center justify-between ${theme === 'dark' ? 'border-slate-700' : 'border-slate-200'}`}>
<div>
<h2 className={`text-lg font-bold ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>Richtigen Titel wählen</h2>
<p className={`text-xs mt-0.5 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>
<Modal
isOpen={isOpen}
onClose={onClose}
title="Richtigen Titel wählen"
maxWidth="2xl"
>
<div className="space-y-4">
<p className="text-xs text-slate-500 dark:text-slate-400">
Deine Wahl gilt für diese Disc auch beim nächsten Einlegen.
</p>
</div>
<button onClick={onClose} className={`p-1.5 rounded ${theme === 'dark' ? 'hover:bg-slate-700 text-slate-400' : 'hover:bg-slate-100 text-slate-500'}`}>
<X size={18} />
</button>
</div>
<div className="p-6 overflow-y-auto">
<div className="flex gap-3">
<input
<div className="flex gap-3 items-end">
<div className="flex-1">
<Input
value={suchbegriff}
onChange={e => setSuchbegriff(e.target.value)}
onKeyDown={e => e.key === 'Enter' && suchen()}
autoFocus
placeholder="Titel eingeben…"
className={`flex-1 px-4 py-2 border rounded-lg focus:ring-2 focus:ring-indigo-500 focus:border-transparent ${theme === 'dark' ? 'bg-slate-700 border-slate-600 text-slate-100' : 'bg-white border-slate-300 text-slate-900'}`}
/>
<button
</div>
<Button
variant="amber"
onClick={suchen}
disabled={!suchbegriff || laeuft}
className="flex items-center gap-2 px-5 py-2 rounded-lg bg-indigo-600 text-white hover:bg-indigo-700 transition-colors disabled:opacity-40"
>
{laeuft ? <Loader2 className="animate-spin" size={18} /> : <Search size={18} />}
Suchen
</button>
</Button>
</div>
{fehler && <p className="text-sm text-rose-500 mt-3">{fehler}</p>}
{fehler && <p className="text-sm text-rose-500 font-medium">{fehler}</p>}
{kandidaten.length > 0 && (
<div className="grid grid-cols-2 md:grid-cols-4 gap-3 mt-4">
<div className="grid grid-cols-2 md:grid-cols-4 gap-3.5 pt-2 max-h-[60vh] overflow-y-auto">
{kandidaten.map((k, i) => (
<button
key={i}
onClick={() => waehlen(k)}
className={`text-left rounded-lg border overflow-hidden transition-all hover:border-indigo-500 hover:shadow-lg ${theme === 'dark' ? 'bg-slate-900 border-slate-700' : 'bg-slate-50 border-slate-200'}`}
className="text-left rounded-xl border border-slate-200 dark:border-slate-800 bg-slate-50 dark:bg-slate-950/80 overflow-hidden transition-all hover:border-amber-500/50 hover:shadow-lg hover:shadow-amber-500/10 group"
>
{k.poster ? (
<img src={k.poster} alt={k.title} className="w-full h-40 object-cover" />
<img src={k.poster} alt={k.title} className="w-full h-40 object-cover group-hover:scale-105 transition-transform duration-300" />
) : (
<div className={`w-full h-40 flex items-center justify-center ${theme === 'dark' ? 'bg-slate-800 text-slate-600' : 'bg-slate-100 text-slate-400'}`}>
<div className="w-full h-40 flex items-center justify-center bg-slate-200 dark:bg-slate-900 text-slate-400 dark:text-slate-600">
<Film size={32} />
</div>
)}
<div className="p-2">
<p className={`text-xs font-semibold leading-tight line-clamp-2 ${theme === 'dark' ? 'text-slate-200' : 'text-slate-800'}`}>{k.title}</p>
<p className={`text-xs mt-0.5 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
<div className="p-2.5">
<p className="text-xs font-semibold leading-tight line-clamp-2 text-slate-900 dark:text-slate-200 group-hover:text-amber-500 dark:group-hover:text-amber-400 transition-colors">
{k.title}
</p>
<p className="text-[11px] mt-1 text-slate-500 dark:text-slate-400">
{k.year || '—'} · {k.type === 'tv' ? 'Serie' : 'Film'} · {k.source}
</p>
</div>
@@ -139,7 +133,6 @@ export default function MetadataKorrektur({ devicePath, vorschlag, isOpen, onClo
</div>
)}
</div>
</div>
</div>
</Modal>
)
}
+162
View File
@@ -0,0 +1,162 @@
/*
* Ein Pfadfeld mit Durchsuchen " wie im Installer.
*
* ## Der Wunsch des Commanders (29.08.2026)
*
* > Wenn man im Nachhinein noch die Verzeichnisse ändern will, geht das
* > heute nur manuell über die einstellungen. Der Durchsuchen button fehlt.
* > Wie es der Installer auch macht"
*
* Er hat recht, und der Unterschied ist größer als ein Knopf: Im Setup wählt
* man den Ordner, danach musste man ihn abtippen. Einen Pfad wie
* `\\192.168.179.62\rippy\movies` tippt niemand zweimal richtig.
*
* ## Warum eine eigene Datei
*
* Weil es der DRITTE Ordner-Browser in diesem Projekt gewesen wäre:
* `RipTargetModal` hat einen, `StorageMounts` hat einen. Beide sind fest in
* ihre Karte eingebaut. Diesen hier kann jedes Feld benutzen.
*
* Der Browser selbst ist die API `/browse` weiß seit dem 28.08.2026, in
* welchem Betrieb es läuft: im Container die Medien-Wurzel, nativ die Liste
* der Laufwerke. Diese Komponente muss darüber nichts wissen.
*/
import { useEffect, useState } from 'react'
import { ArrowUp, Folder, FolderOpen } from 'lucide-react'
import { api } from '../lib/api'
import { Modal } from './ui/Modal'
import { Button } from './ui/Button'
import { Input } from './ui/Input'
interface Eintrag {
name: string
path: string
}
interface Props {
label: string
value: string
placeholder?: string
onChange: (pfad: string) => void
}
export function OrdnerWaehler({ label, value, placeholder, onChange }: Props) {
const [offen, setOffen] = useState(false)
const [pfad, setPfad] = useState('')
const [eltern, setEltern] = useState<string | null>(null)
const [ordner, setOrdner] = useState<Eintrag[]>([])
const [fehler, setFehler] = useState('')
const [laedt, setLaedt] = useState(false)
const laden = async (ziel: string) => {
setLaedt(true)
setFehler('')
try {
const r = await api.get('/browse', { params: { path: ziel } })
setPfad(r.data.path || '')
setEltern(r.data.parent)
setOrdner(Array.isArray(r.data.dirs) ? r.data.dirs : [])
} catch (e: any) {
// Ein nicht lesbarer Ordner ist kein Grund, den Dialog zu schließen —
// man kommt mit „nach oben" wieder heraus.
setFehler(e?.response?.data?.detail || 'Ordner nicht lesbar')
setOrdner([])
} finally {
setLaedt(false)
}
}
useEffect(() => {
if (!offen) return
// Beim eingetragenen Wert einsteigen, sonst ganz oben. Leerer Pfad heißt
// für /browse „oberste Ebene" — nativ also die Laufwerksliste.
laden(value || '')
}, [offen])
return (
<div className="space-y-2">
<div className="flex items-end gap-2">
<div className="flex-1">
<Input
label={label}
value={value}
placeholder={placeholder}
onChange={(e) => onChange(e.target.value)}
/>
</div>
<Button variant="secondary" onClick={() => setOffen(true)}>
Durchsuchen
</Button>
</div>
<Modal
isOpen={offen}
onClose={() => setOffen(false)}
title={label}
maxWidth="lg"
>
<div className="space-y-3">
<div className="flex items-center gap-2 px-3 py-2 rounded-xl border border-slate-200 dark:border-slate-800 bg-slate-100/50 dark:bg-slate-900/50">
<button
onClick={() => eltern !== null && laden(eltern)}
disabled={eltern === null}
className="p-1 rounded-lg disabled:opacity-30 hover:bg-slate-200 dark:hover:bg-slate-800 text-slate-500 dark:text-slate-400"
title="Eine Ebene höher"
>
<ArrowUp size={16} />
</button>
<span className="text-xs font-mono truncate flex-1 text-slate-600 dark:text-slate-300">
{pfad || 'Laufwerke'}
</span>
</div>
<div className="max-h-72 overflow-y-auto rounded-xl border border-slate-200 dark:border-slate-800 p-1">
{laedt && (
<p className="px-3 py-2 text-xs text-slate-400">wird gelesen </p>
)}
{!laedt && fehler && (
<p className="px-3 py-2 text-xs text-amber-600 dark:text-amber-400">{fehler}</p>
)}
{!laedt && !fehler && ordner.length === 0 && (
<p className="px-3 py-2 text-xs text-slate-400">Keine Unterordner.</p>
)}
{ordner.map((o) => (
<button
key={o.path}
onClick={() => laden(o.path)}
className="w-full flex items-center gap-2 px-3 py-1.5 text-xs text-left rounded-lg transition-colors text-slate-700 dark:text-slate-300 hover:bg-slate-100 dark:hover:bg-slate-800"
>
<Folder size={14} className="text-slate-400" />
{o.name}
</button>
))}
</div>
<div className="flex items-center justify-between gap-2">
<p className="text-xs text-slate-500 dark:text-slate-400 flex items-center gap-1.5">
<FolderOpen size={13} />
Ein Netzwerkpfad lässt sich auch direkt ins Feld schreiben.
</p>
<div className="flex gap-2">
<Button variant="secondary" onClick={() => setOffen(false)}>
Abbrechen
</Button>
<Button
variant="amber"
disabled={!pfad}
onClick={() => {
onChange(pfad)
setOffen(false)
}}
>
Diesen Ordner nutzen
</Button>
</div>
</div>
</div>
</Modal>
</div>
)
}
+165
View File
@@ -0,0 +1,165 @@
import { AlertTriangle, HelpCircle, RotateCcw, Disc } from 'lucide-react'
import { Modal } from './ui/Modal'
import { Button } from './ui/Button'
/*
* Was wird bei Neu" eigentlich wiederholt?
*
* Commander-Frage 26.07.2026: Hier gibt es den Button neu' aber WAS wird dann
* gemacht? Komprimierung? Neu Gerippt? Das muss ja je nach fehlgeschlagenem Job
* eine Option anbieten." Bis dahin hieß der Knopf nur „Neu" und rief immer die
* Kompression auch bei einem Job, dessen RIP abgebrochen war. Aus 5,1 GB
* Bruchstück (von rund 40 GB) wäre brav ein Film geworden, der bei 12 % endet.
*
* Dieser Dialog nennt beim Namen, was passiert, und in welchen Punkten sich die
* beiden Wege unterscheiden: Braucht es die Disc? Wie lange dauert es? Was
* passiert mit dem, was schon auf der Platte liegt?
*
* Die Phase kommt aus api/phasen.py. Kennt Rippy sie nicht (Jobs von vor der
* Einführung der Marke), wird nicht geraten dann stehen beide Wege da, und
* die Größe der Rohdaten ist die Entscheidungshilfe: Wer ungefähr eine
* Disc-Größe daliegen sieht, hatte einen fertigen Rip.
*/
interface RetryDialogProps {
offen: boolean
titel: string
plan: 'transcode' | 'rip' | 'unklar'
rohdaten: { gb: number, dateien: number, pfade: string[] } | null
onClose: () => void
onStart: (art: 'transcode' | 'rip') => void
}
function Rohdaten({ rohdaten }: { rohdaten: RetryDialogProps['rohdaten'] }) {
if (!rohdaten) return null
if (!rohdaten.gb) {
return (
<p className="text-xs text-slate-500 dark:text-slate-400">
Auf der Platte liegt zu diesem Job nichts (mehr) neu rippen ist damit
der einzige Weg.
</p>
)
}
return (
<p className="text-xs text-slate-500 dark:text-slate-400">
Auf der Platte liegen <strong>{rohdaten.gb} GB</strong> Rohdaten
{rohdaten.dateien > 0 ? ` in ${rohdaten.dateien} Datei${rohdaten.dateien === 1 ? '' : 'en'}` : ''}.
{' '}Eine Blu-ray bringt roh etwa 2545 GB mit, eine 4K-UHD 50100 GB, eine
DVD 48 GB. Passt die Zahl dazu, war der Rip fertig.
</p>
)
}
export default function RetryDialog({
offen, titel, plan, rohdaten, onClose, onStart,
}: RetryDialogProps) {
const name = titel || 'Dieser Job'
return (
<Modal isOpen={offen} onClose={onClose} maxWidth="lg">
{plan === 'transcode' && (
<>
<div className="flex items-start gap-4">
<RotateCcw className="text-indigo-500 w-8 h-8 flex-shrink-0" />
<div className="space-y-2 flex-1">
<h2 className="text-lg font-bold text-slate-900 dark:text-slate-100">
{name}" neu komprimieren?
</h2>
<p className="text-sm leading-relaxed text-slate-600 dark:text-slate-300">
Der Rip war fertig abgebrochen ist erst die Kompression. Rippy
nimmt die vorhandene Roh-Datei und komprimiert sie noch einmal.
<strong> Die Disc wird nicht gebraucht</strong>, das Laufwerk
bleibt frei, und die Stunde fürs Rippen fällt nicht erneut an.
</p>
<Rohdaten rohdaten={rohdaten} />
</div>
</div>
<div className="mt-6 flex flex-wrap justify-end gap-3 border-t border-slate-200 dark:border-slate-800 pt-4">
<Button variant="secondary" onClick={onClose}>Abbrechen</Button>
<Button variant="ghost" onClick={() => onStart('rip')}>
<Disc size={14} /> Doch von der Disc neu rippen
</Button>
<Button variant="primary" onClick={() => onStart('transcode')}>
<RotateCcw size={14} /> Neu komprimieren
</Button>
</div>
</>
)}
{plan === 'rip' && (
<>
<div className="flex items-start gap-4">
<AlertTriangle className="text-amber-500 w-8 h-8 flex-shrink-0" />
<div className="space-y-2 flex-1">
<h2 className="text-lg font-bold text-slate-900 dark:text-slate-100">
{name}" neu rippen?
</h2>
<p className="text-sm leading-relaxed text-slate-600 dark:text-slate-300">
Hier ist der <strong>Rip selbst</strong> abgebrochen. Was davon
auf der Platte liegt, ist ein Bruchstück komprimieren würde
daraus einen Film machen, der mitten drin aufhört. Rippy liest
die Disc deshalb von vorn.
</p>
<p className="text-sm leading-relaxed text-slate-600 dark:text-slate-300">
<strong>Die Disc muss dafür im Laufwerk liegen.</strong> Nach dem
Fehlschlag wurde sie möglicherweise ausgeworfen. Titel, Ablage,
Sprachwahl und Encoder-Worker werden vom alten Job übernommen.
</p>
<Rohdaten rohdaten={rohdaten} />
<p className="text-xs text-slate-500 dark:text-slate-400">
Der alte Eintrag bleibt zum Nachlesen stehen; das Bruchstück
lässt sich über den Papierkorb daran mitlöschen.
</p>
</div>
</div>
<div className="mt-6 flex justify-end gap-3 border-t border-slate-200 dark:border-slate-800 pt-4">
<Button variant="secondary" onClick={onClose}>Abbrechen</Button>
<Button variant="amber" onClick={() => onStart('rip')}>
<Disc size={14} /> Neu rippen
</Button>
</div>
</>
)}
{plan === 'unklar' && (
<>
<div className="flex items-start gap-4">
<HelpCircle className="text-indigo-500 w-8 h-8 flex-shrink-0" />
<div className="space-y-2 flex-1">
<h2 className="text-lg font-bold text-slate-900 dark:text-slate-100">
{name}": was soll wiederholt werden?
</h2>
<p className="text-sm leading-relaxed text-slate-600 dark:text-slate-300">
Bei diesem Job kann Rippy nicht mehr feststellen, ob der Rip
fertig war oder mitten drin abbrach er ist älter als der
Vermerk dafür. Deshalb wird hier nicht geraten:
</p>
<ul className="text-sm leading-relaxed text-slate-600 dark:text-slate-300 space-y-1 list-disc pl-5">
<li>
<strong>Neu komprimieren</strong> schnell, braucht die Disc
nicht. Richtig, wenn der Rip durchlief.
</li>
<li>
<strong>Neu rippen</strong> dauert wieder eine Weile und
braucht die Disc im Laufwerk. Immer richtig, nur teurer.
</li>
</ul>
<Rohdaten rohdaten={rohdaten} />
</div>
</div>
<div className="mt-6 flex flex-wrap justify-end gap-3 border-t border-slate-200 dark:border-slate-800 pt-4">
<Button variant="secondary" onClick={onClose}>Abbrechen</Button>
{!!rohdaten?.gb && (
<Button variant="primary" onClick={() => onStart('transcode')}>
<RotateCcw size={14} /> Neu komprimieren
</Button>
)}
<Button variant="amber" onClick={() => onStart('rip')}>
<Disc size={14} /> Neu rippen
</Button>
</div>
</>
)}
</Modal>
)
}
+606 -94
View File
@@ -1,7 +1,11 @@
import { useState, useEffect } from 'react'
import { Folder, FolderOpen, File, ArrowUp, CheckCircle } from 'lucide-react'
import { Folder, FolderOpen, ArrowUp, CheckCircle, Film, Tv, Music, Cpu, HardDrive, ChevronRight, ChevronDown } from 'lucide-react'
import { api } from '../lib/api'
import { useDarkMode } from '../context/ThemeContext'
import { Modal } from './ui/Modal'
import { Button } from './ui/Button'
import { Input, Select } from './ui/Input'
import { automatikWarnung, externWarnung, freigabenAusMapping, sprachName } from '../lib/encoder'
import { useBetrieb } from '../lib/useBetrieb'
interface TargetConfig {
id: string
@@ -11,10 +15,70 @@ interface TargetConfig {
isActive: boolean
}
export interface RipOptionen {
series?: string
season?: number
mainFeatureOnly?: boolean
titles?: number[]
transcodeNode?: string // gewählter Encoder-Worker (Celery-Node) oder leer = auto
workDir?: string // Arbeitsverzeichnis für die Rohdaten; leer = Einstellung
// Sprachauswahl (ISO-639-2). Leer = alles behalten. Wirkt bei der
// KOMPRESSION — der Rip bleibt vollständig und verlustfrei.
audioSprachen?: string[]
untertitelSprachen?: string[]
}
// Eine Sprache, die die Disc anbietet (aus dem Titel-Scan, MakeMKV SINFO).
interface DiscSprache {
lang: string // ISO-639-2, z. B. "deu"
sprache: string // Klartext, z. B. "German"
spuren: number
}
// Ein Ablageziel aus GET /storage-targets.
interface StorageZiel {
name: string
path: string
is_mount: boolean
free_gb: number | null
}
interface WorkerWahl {
name: string
node: string | null
online?: boolean
encoders: string[]
// extern: 'ja' = läuft AUSSERHALB des Rippy-Containers und erreicht die
// Container-Pfade nur über eine Freigabe plus pfad_map. Der Worker meldet
// beides selbst (worker/caps.py).
info?: { extern?: string, pfad_map?: string }
}
const ENCODER_KURZ: Record<string, string> = {
'cpu-x264': 'H.264', 'cpu-x265': 'H.265', 'cpu-av1': 'AV1',
'vaapi': 'VAAPI⚡', 'nvenc': 'NVENC⚡',
}
interface TitelInfo {
nr: number
dauer_s: number
groesse_bytes: number
kapitel: number
}
interface RipTargetModalProps {
isOpen: boolean
initialType?: TargetConfig['type']
discTitle?: string
deviceId?: string
onClose: () => void
onSave: (target: TargetConfig) => void
onSave: (target: TargetConfig, optionen: RipOptionen) => void
}
function dauerText(s: number): string {
const h = Math.floor(s / 3600)
const m = Math.floor((s % 3600) / 60)
return h > 0 ? `${h}:${String(m).padStart(2, '0')} h` : `${m} min`
}
interface BrowseDir {
@@ -22,35 +86,156 @@ interface BrowseDir {
path: string
}
// Ziel-Auswahl vor dem Rip: Schnellwahl (Filme/Serien/Musik) ODER frei per
// Ordner-Browser — auch in eingehängte Netzwerk-Ziele (NAS, PC-Freigabe).
export default function RipTargetModal({ isOpen, onClose, onSave }: RipTargetModalProps) {
export default function RipTargetModal({ isOpen, initialType, discTitle, deviceId, onClose, onSave }: RipTargetModalProps) {
const [selectedType, setSelectedType] = useState<TargetConfig['type']>('movies')
const [targets, setTargets] = useState<TargetConfig[]>([
{ id: '1', name: 'Filme', path: '/app/media/movies', type: 'movies', isActive: true },
{ id: '2', name: 'Serien', path: '/app/media/series', type: 'series', isActive: true },
{ id: '3', name: 'Musik', path: '/app/media/music', type: 'music', isActive: true },
])
const [browsePath, setBrowsePath] = useState<string>('/app/media')
const [serienName, setSerienName] = useState('')
const [staffel, setStaffel] = useState(1)
const [nurHauptfilm, setNurHauptfilm] = useState(false)
const [scanStatus, setScanStatus] = useState<'idle' | 'running' | 'done' | 'error'>('idle')
const [scanFehler, setScanFehler] = useState('')
const [titelListe, setTitelListe] = useState<TitelInfo[]>([])
const [gewaehlt, setGewaehlt] = useState<Set<number>>(new Set())
const [workers, setWorkers] = useState<WorkerWahl[]>([])
const [encoderNode, setEncoderNode] = useState('') // '' = automatisch
/*
* Sprachen der Disc (Commander-Anforderung 26.07.2026: Die Disc hat Material
* in X Sprachen und X Untertiteln Rippy muss VOR dem Rip fragen: Was genau
* willst du haben?").
*
* Die Auskunft kommt aus demselben Titel-Scan, der schon für die
* Titel-Auswahl läuft MakeMKV liefert sie in derselben Ausgabe mit, sie
* wurde bisher nur weggeworfen.
*
* Leere Auswahl heißt bewusst alles behalten": Wer nichts anklickt, bekommt
* das Verhalten von vorher, und niemand verliert versehentlich seine Tonspur.
*/
const [discSprachen, setDiscSprachen] = useState<{ audio: DiscSprache[], untertitel: DiscSprache[] } | null>(null)
const [audioWahl, setAudioWahl] = useState<Set<string>>(new Set())
const [untertitelWahl, setUntertitelWahl] = useState<Set<string>>(new Set())
// Wunschsprachen aus den Einstellungen — sie werden beim Scan vorausgewählt,
// soweit die Disc sie überhaupt hat.
const [standardAudio, setStandardAudio] = useState<string[]>([])
const [standardUntertitel, setStandardUntertitel] = useState<string[]>([])
const scanStarten = async () => {
if (!deviceId) return
setScanStatus('running')
setScanFehler('')
try {
await api.post(`/devices/${deviceId}/scan-tracks`)
} catch (e: any) {
setScanStatus('error')
setScanFehler(e?.response?.data?.detail || 'Scan konnte nicht gestartet werden')
}
}
useEffect(() => {
if (scanStatus !== 'running' || !deviceId) return
const interval = setInterval(async () => {
try {
const r = await api.get(`/devices/${deviceId}/tracks`)
if (r.data.status === 'done') {
const tracks: TitelInfo[] = r.data.tracks || []
setTitelListe(tracks)
setGewaehlt(new Set(tracks.filter(t => t.dauer_s >= 300).map(t => t.nr)))
const spr = r.data.sprachen || null
setDiscSprachen(spr)
// Wunschsprachen vorauswählen — aber nur, was die Disc wirklich hat.
// Sonst stünde da eine Auswahl, die nichts bewirkt.
if (spr) {
const vorhanden = (liste: DiscSprache[], wunsch: string[]) =>
new Set(liste.filter(s => wunsch.includes(s.lang)).map(s => s.lang))
setAudioWahl(vorhanden(spr.audio || [], standardAudio))
setUntertitelWahl(vorhanden(spr.untertitel || [], standardUntertitel))
}
setScanStatus('done')
} else if (r.data.status === 'error') {
setScanFehler(r.data.error || 'Scan fehlgeschlagen')
setScanStatus('error')
}
} catch { /* API kurz weg — weiter pollen */ }
}, 3000)
return () => clearInterval(interval)
}, [scanStatus, deviceId])
// Welcher Betrieb? Ohne diese Auskunft stand hier „Container-Platte" —
// auf einem Windows-PC eine Ortsangabe fuer einen Ort, den es nicht gibt.
const betrieb = useBetrieb()
/*
* Leer starten statt mit Container-Pfaden (Befund 29.08.2026).
*
* Hier standen `/app/media/movies` & Co. als Anfangswert. Auf einem
* Windows-PC gibt es die nicht und fuer den Augenblick zwischen Oeffnen
* des Dialogs und der Antwort von /settings stand dort ein Pfad, den es
* nirgends gibt. Ein leerer Wert ist ehrlicher: Er behauptet nichts.
*/
const [targets, setTargets] = useState<TargetConfig[]>([])
const [browsePath, setBrowsePath] = useState<string>('')
const [browseParent, setBrowseParent] = useState<string | null>(null)
const [browseDirs, setBrowseDirs] = useState<BrowseDir[]>([])
const [browseFiles, setBrowseFiles] = useState<{ name: string, size_mb: number | null }[]>([])
const [customPath, setCustomPath] = useState('')
const { theme } = useDarkMode()
// Der Ordner-Browser ist EINGEKLAPPT (Commander 26.07.2026: „Warum wird hier
// der Datei Browser noch angezeigt — das ist doch quatsch"). Er ist nicht
// wirklich redundant: nur über ihn lässt sich für DIESEN einen Rip ein
// beliebiger Zielordner wählen. Aber der Normalfall ist die Schnellwahl
// darüber, und der Browser überschrieb sie stillschweigend, sobald man auf
// „Diesen Ordner nutzen" klickte. Jetzt muss man ihn aufklappen — dann ist
// die Wahl bewusst. Nebenbefund beim Aufräumen: `browseFiles` wurde geladen
// und NIE angezeigt (samt ungenutztem File-Icon) — beides entfernt.
const [browserOffen, setBrowserOffen] = useState(false)
// Arbeitsverzeichnis dieses Rips (Commander-Wunsch 25.07.2026: hier wählbar,
// nicht global vorgegeben). '' = der Wert aus den Einstellungen, der auch
// bei Vollautomatik-Rips gilt, weil dort niemand gefragt wird.
const [arbeitsZiele, setArbeitsZiele] = useState<StorageZiel[]>([])
const [arbeitsDir, setArbeitsDir] = useState('')
const [standardArbeitsDir, setStandardArbeitsDir] = useState('')
// Ein frei erblätterter Arbeitsordner. Er braucht einen eigenen Platz in
// der Liste, sonst zeigt das Auswahlfeld einen Wert an, den es nicht kennt
// — und stünde leer da, obwohl etwas gewählt ist.
const [eigenesArbeitsZiel, setEigenesArbeitsZiel] = useState('')
// Standard-Unterordner aus den Einstellungen ziehen (nicht hartkodiert)
useEffect(() => {
if (!isOpen) return
setSelectedType(initialType || 'movies')
setCustomPath('')
setSerienName(discTitle || '')
setStaffel(1)
setScanStatus('idle')
setScanFehler('')
setTitelListe([])
setGewaehlt(new Set())
setEncoderNode('')
setArbeitsDir('')
setEigenesArbeitsZiel('')
setBrowserOffen(false)
setDiscSprachen(null)
setAudioWahl(new Set())
setUntertitelWahl(new Set())
api.get('/storage-targets')
.then(r => setArbeitsZiele(Array.isArray(r.data) ? r.data : []))
.catch(() => setArbeitsZiele([]))
// Online-Worker für die Encoder-Wahl (nur relevant, wenn ≥2 verfügbar)
api.get('/capabilities').then(r => {
setWorkers((r.data.workers || []).filter((w: WorkerWahl) => w.online && w.node))
}).catch(() => setWorkers([]))
api.get('/settings').then(r => {
const s = r.data || {}
const basis = s.outputDir || '/app/media'
setNurHauptfilm(!!s.mainFeatureOnly)
setStandardArbeitsDir((s.workDir || '').trim())
const codes = (wert: any) => String(wert || '')
.split(',').map((t: string) => t.trim().toLowerCase()).filter(Boolean)
setStandardAudio(codes(s.audioSprachen))
setStandardUntertitel(codes(s.untertitelSprachen))
const basis = s.outputDir || betrieb.ablage_vorgabe
setTargets([
{ id: '1', name: 'Filme', path: `${basis}/${s.movieDir || 'movies'}`, type: 'movies', isActive: true },
{ id: '2', name: 'Serien', path: `${basis}/${s.seriesDir || 'series'}`, type: 'series', isActive: true },
{ id: '3', name: 'Musik', path: `${basis}/${s.musicDir || 'music'}`, type: 'music', isActive: true },
])
}).catch(() => {})
laden('/app/media')
// /browse wird erst beim Aufklappen geholt — der Dialog braucht es im
// Normalfall gar nicht.
}, [isOpen])
const laden = async (pfad: string) => {
@@ -59,139 +244,466 @@ export default function RipTargetModal({ isOpen, onClose, onSave }: RipTargetMod
setBrowsePath(r.data.path)
setBrowseParent(r.data.parent)
setBrowseDirs(r.data.dirs)
setBrowseFiles(r.data.files || [])
} catch {
setBrowseDirs([])
setBrowseFiles([])
}
}
// Der effektive Zielpfad dieses Rips — Schnellwahl oder eigener Ordner.
const zielPfad = customPath || targets.find(t => t.type === selectedType)?.path || ''
// Das effektive Arbeitsverzeichnis: Wahl für diesen Rip → Einstellung →
// leer (= Container-Platte /app/temp, für externe Worker unerreichbar).
const arbeitsPfadEffektiv = arbeitsDir || standardArbeitsDir
/*
* Was WIRKLICH benutzt wird, wenn niemand etwas wählt.
*
* Commander am 28.08.2026: Warum heißt das hier noch container platte? Er
* holt sich das Arbeitsverzeichnis ja von der Installation."
*
* Genau so ist es nur stand hier fest verdrahtet (Container-Platte)",
* sobald die Einstellung leer war. Auf seinem PC war das die Beschreibung
* eines Ortes, den es nicht gibt. Jetzt sagt der Betrieb, wohin es geht.
*/
const arbeitsVorgabe = standardArbeitsDir || betrieb.arbeits_vorgabe
// Warnung VOR dem Start, wenn der gewählte externe Encoder die Pfade nicht
// erreicht (Punkt 6 des Savepoints v3.16). Am 26.07.2026 fiel genau das erst
// NACH dem Rip auf, weil nur der Worker selbst prüfte.
const gewaehlterWorker = workers.find(w => w.node === encoderNode)
/*
* Ein-Klick-Abhilfe: dasselbe Ziel, aber auf der Freigabe, die der gewählte
* Worker erreicht. Aus /app/media/movies wird /app/media/<freigabe>/movies.
*
* Nur wenn es überhaupt eine Freigabe gibt und das Ziel noch nicht darauf
* liegt sonst stünde ein Knopf da, der nichts tut.
*/
const zielAufFreigabe = (() => {
const freigabe = freigabenAusMapping(gewaehlterWorker?.info?.pfad_map)[0]
if (!freigabe || !zielPfad) return ''
const unterordner = zielPfad.split('/').filter(Boolean).pop() || ''
const neu = `/app/media/${freigabe}/${unterordner}`
return neu === zielPfad ? '' : neu
})()
const pfadWarnung = selectedType === 'music'
? null
: encoderNode
? externWarnung(gewaehlterWorker, zielPfad, arbeitsPfadEffektiv)
// „Automatisch": die geteilte Queue nimmt den ersten freien Worker — auch
// einen, der die Pfade nicht erreicht.
: automatikWarnung(workers, zielPfad, arbeitsPfadEffektiv)
const handleSave = () => {
const optionen: RipOptionen = { mainFeatureOnly: nurHauptfilm }
if (selectedType === 'series' && serienName.trim()) {
optionen.series = serienName.trim()
optionen.season = Math.max(1, staffel || 1)
}
if (scanStatus === 'done' && gewaehlt.size > 0 && gewaehlt.size < titelListe.length) {
optionen.titles = [...gewaehlt].sort((a, b) => a - b)
}
if (encoderNode) optionen.transcodeNode = encoderNode
if (arbeitsDir) optionen.workDir = arbeitsDir
if (audioWahl.size > 0) optionen.audioSprachen = [...audioWahl]
if (untertitelWahl.size > 0) optionen.untertitelSprachen = [...untertitelWahl]
const target = targets.find(t => t.type === selectedType)
if (customPath) {
onSave({ id: 'custom', name: 'Eigener Ordner', path: customPath, type: selectedType, isActive: true })
onSave({ id: 'custom', name: 'Eigener Ordner', path: customPath, type: selectedType, isActive: true }, optionen)
} else if (target) {
onSave(target)
onSave(target, optionen)
}
onClose()
}
if (!isOpen) return null
return (
<div className="fixed inset-0 z-50 flex items-center justify-center p-4 bg-black/50 backdrop-blur-sm transition-all">
<div className={`w-full max-w-lg rounded-xl shadow-2xl transition-colors duration-300 ${theme === 'dark' ? 'bg-slate-800' : 'bg-white'}`}>
{/* Header */}
<div className={`px-6 py-4 border-b transition-colors duration-300 ${theme === 'dark' ? 'border-slate-700' : 'border-slate-200'}`}>
<h2 className={`text-xl font-bold ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>Rip-Ziel auswählen</h2>
<p className={`text-sm mt-1 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>
<Modal
isOpen={isOpen}
onClose={onClose}
title="Rip-Ziel auswählen"
maxWidth="lg"
>
<div className="space-y-5">
<p className="text-xs text-slate-500 dark:text-slate-400">
Schnellwahl oder eigenen Ordner wählen Netzwerk-Ziele (NAS, PC) sind unter Einstellungen Speicherziele einhängbar.
</p>
</div>
{/* Body */}
<div className="p-6 space-y-5">
{/* Schnellwahl */}
<div className="grid grid-cols-3 gap-3">
{targets.map((t) => (
{targets.map((t) => {
const isSelected = selectedType === t.type && !customPath
return (
<button
key={t.type}
onClick={() => { setSelectedType(t.type); setCustomPath('') }}
className={`flex flex-col items-center justify-center gap-1.5 p-3 rounded-lg border transition-all ${
selectedType === t.type && !customPath
? theme === 'dark'
? 'bg-indigo-900/30 border-indigo-500 text-indigo-400'
: 'bg-indigo-50 border-indigo-600 text-indigo-700'
: theme === 'dark'
? 'bg-slate-900 border-slate-700 text-slate-400 hover:border-slate-600'
: 'bg-slate-50 border-slate-200 text-slate-600 hover:border-slate-300'
className={`flex flex-col items-center justify-center gap-1.5 p-3.5 rounded-xl border transition-all ${
isSelected
? 'bg-amber-500/15 border-amber-500 text-amber-600 dark:text-amber-300 font-semibold shadow-md shadow-amber-500/10'
: 'bg-slate-50 dark:bg-slate-950/80 border-slate-200 dark:border-slate-800 text-slate-600 dark:text-slate-400 hover:border-slate-300 dark:hover:border-slate-700'
}`}
>
<span className="text-xl">
{t.type === 'movies' && '🎥'}
{t.type === 'series' && '📺'}
{t.type === 'music' && '🎵'}
</span>
<span className="text-sm font-medium">{t.name}</span>
{t.type === 'movies' && <Film size={22} className={isSelected ? 'text-amber-500' : ''} />}
{t.type === 'series' && <Tv size={22} className={isSelected ? 'text-amber-500' : ''} />}
{t.type === 'music' && <Music size={22} className={isSelected ? 'text-amber-500' : ''} />}
<span className="text-sm">{t.name}</span>
</button>
))}
)
})}
</div>
{/* Ordner-Browser */}
<div className={`rounded-lg border overflow-hidden ${theme === 'dark' ? 'border-slate-700' : 'border-slate-200'}`}>
<div className={`flex items-center gap-2 px-3 py-2 border-b ${theme === 'dark' ? 'border-slate-700 bg-slate-900' : 'border-slate-200 bg-slate-50'}`}>
{/* Serien-Flow */}
{selectedType === 'series' && (
<div className="rounded-xl p-4 space-y-3 bg-slate-50 dark:bg-slate-950/80 border border-slate-200 dark:border-slate-800">
<div className="grid grid-cols-[1fr_90px] gap-3">
<Input
label="Serienname"
value={serienName}
onChange={e => setSerienName(e.target.value)}
placeholder="z. B. Neon Genesis Evangelion"
/>
<Input
label="Staffel"
type="number"
min={1}
value={staffel}
onChange={e => setStaffel(parseInt(e.target.value) || 1)}
/>
</div>
<p className="text-xs text-slate-500 dark:text-slate-400">
Ablage: {serienName.trim() || '<Serie>'}/Season {String(Math.max(1, staffel || 1)).padStart(2, '0')}
</p>
</div>
)}
{/* Hauptfilm-Wahl */}
{selectedType === 'movies' && scanStatus !== 'done' && (
<label className="flex items-center gap-3 text-sm text-slate-700 dark:text-slate-300">
<input
type="checkbox"
checked={nurHauptfilm}
onChange={e => setNurHauptfilm(e.target.checked)}
className="w-4 h-4 accent-amber-500 rounded"
/>
Nur Hauptfilm rippen (längster Titel Extras/Trailer bleiben weg)
</label>
)}
{/*
Arbeitsverzeichnis für DIESEN Rip (Commander-Wunsch 25.07.2026).
Warum es hier steht: Der Roh-Rip einer 4K-UHD ist bis zu 100 GB groß
und lag bisher immer auf der Container-Platte am 25.07. lief sie
damit voll (74 GB Rohschnitt auf 148 GB Platte). Die Wahl gehört zur
Disc, nicht in eine globale Einstellung. Leer = der Wert aus
Einstellungen Verarbeitung; genau der greift auch bei
Vollautomatik-Rips, weil dort niemand gefragt wird.
Musik-Rips gehen direkt als FLAC ins Ziel, ohne Roh-Zwischenstufe.
*/}
{selectedType !== 'music' && (
<div>
<Select
label="Arbeitsverzeichnis für die Rohdaten"
value={arbeitsDir}
onChange={e => setArbeitsDir(e.target.value)}
>
<option value="">
Standard{arbeitsVorgabe ? `${arbeitsVorgabe}` : ''}
</option>
{arbeitsZiele.map(z => (
<option key={z.path} value={z.path}>
{z.name}{z.is_mount ? ' (Netzwerk-Freigabe)' : ''}
{z.free_gb != null ? `${z.free_gb} GB frei` : ''}
</option>
))}
{eigenesArbeitsZiel && (
<option value={eigenesArbeitsZiel}>{eigenesArbeitsZiel}</option>
)}
</Select>
<p className="text-xs mt-1.5 text-slate-500 dark:text-slate-400 flex items-center gap-1.5">
<HardDrive size={13} />
Bei 4K-UHD bis zu 100 GB nimm ein Laufwerk mit Platz, am besten dasselbe wie das Ziel oben.
Dann muss Rippy am Ende nur umhängen statt zu kopieren.
</p>
</div>
)}
{/* Encoder-/Worker-Wahl nur wenn mehrere Worker online sind
(sonst gibt es nichts zu wählen). Musik wird nicht komprimiert. */}
{selectedType !== 'music' && workers.length >= 2 && (
<div>
<Select
label="Encoder / Worker für die Kompression"
value={encoderNode}
onChange={e => setEncoderNode(e.target.value)}
>
<option value="">Automatisch (erster freier Worker)</option>
{workers.map(w => (
<option key={w.node!} value={w.node!}>
{w.name} {w.encoders.map(e => ENCODER_KURZ[e] || e).join(', ')}
</option>
))}
</Select>
<p className="text-xs mt-1.5 text-slate-500 dark:text-slate-400 flex items-center gap-1.5">
<Cpu size={13} /> Wähle gezielt eine Maschine (z. B. die mit GPU) sonst nimmt der erste freie Worker.
</p>
</div>
)}
{/* Die Warnung, die am 26.07.2026 gefehlt hat: Der gewählte externe
Encoder nahm die Aufgabe an und lehnte sie 182 ms später ab, weil er
die Container-Pfade nicht sieht. Sichtbar war das erst NACH dem Rip. */}
{pfadWarnung && (
<div className="text-xs p-3 rounded-lg bg-amber-500/10 border border-amber-500/30 text-amber-700 dark:text-amber-300">
<strong> Dieser Encoder kann so nicht arbeiten.</strong>
<p className="mt-1">{pfadWarnung}</p>
{/* Ein Knopf statt einer Wegbeschreibung: Er legt das Ziel NUR FÜR
DIESEN RIP auf die Freigabe, die der Worker erreicht ohne die
globale Ablage anzufassen. Geh in die Einstellungen" mitten im
Dialog ist lästig, und wer den Rip jetzt starten will, will
jetzt eine Lösung. */}
{zielAufFreigabe && (
<Button
variant="secondary"
size="sm"
className="mt-2"
onClick={() => { setCustomPath(zielAufFreigabe); setBrowserOffen(false) }}
>
Ziel für diesen Rip auf die Freigabe legen
</Button>
)}
</div>
)}
{/* Titel-Auswahl (Track-Tabelle) */}
{deviceId && selectedType !== 'music' && (
<div className="rounded-xl border border-slate-200 dark:border-slate-800 overflow-hidden bg-slate-50/50 dark:bg-slate-950/50">
<div className="flex items-center justify-between px-4 py-2.5 border-b border-slate-200 dark:border-slate-800">
<div>
<span className="text-sm font-medium text-slate-900 dark:text-slate-200">Titel-Auswahl (optional)</span>
{scanStatus === 'idle' && (
<p className="text-xs text-slate-500 dark:text-slate-400">
Disc scannen und einzelne Titel an-/abwählen.
</p>
)}
</div>
{scanStatus === 'running' ? (
<span className="text-xs flex items-center gap-2 text-slate-500 dark:text-slate-400">
<span className="animate-spin rounded-full h-3.5 w-3.5 border-2 border-amber-500 border-t-transparent" />
Disc wird gelesen (20120 s)
</span>
) : (
<Button variant="secondary" size="sm" onClick={scanStarten}>
{scanStatus === 'done' ? 'Neu scannen' : 'Disc scannen'}
</Button>
)}
</div>
{scanStatus === 'error' && (
<p className="text-xs text-rose-500 px-4 py-2.5">{scanFehler}</p>
)}
{scanStatus === 'done' && titelListe.length > 0 && (
<>
<div className="max-h-44 overflow-y-auto">
{titelListe.map(t => (
<label
key={t.nr}
className="flex items-center gap-3 px-4 py-2 text-sm cursor-pointer border-b border-slate-200/50 dark:border-slate-800/50 hover:bg-slate-100 dark:hover:bg-slate-800/60"
>
<input
type="checkbox"
checked={gewaehlt.has(t.nr)}
onChange={e => {
const neu = new Set(gewaehlt)
if (e.target.checked) neu.add(t.nr); else neu.delete(t.nr)
setGewaehlt(neu)
}}
className="w-4 h-4 accent-amber-500 rounded"
/>
<span className="font-mono text-xs w-14 font-semibold text-slate-700 dark:text-slate-300">Titel {t.nr}</span>
<span className="text-slate-600 dark:text-slate-300">{dauerText(t.dauer_s)}</span>
{t.kapitel > 0 && (
<span className="text-xs text-slate-400">{t.kapitel} Kap.</span>
)}
<span className="ml-auto text-xs font-mono text-slate-400">
{t.groesse_bytes > 0 ? `${(t.groesse_bytes / 1024 ** 3).toFixed(1)} GB` : ''}
</span>
</label>
))}
</div>
<p className="text-xs px-4 py-2 bg-slate-100 dark:bg-slate-900 text-slate-500 dark:text-slate-400">
{gewaehlt.size} von {titelListe.length} Titeln gewählt
</p>
</>
)}
</div>
)}
{/* Sprachen der Disc steht direkt unter der Titel-Auswahl, weil beides
aus DEMSELBEN Scan kommt. Vorher warf Rippy diese Auskunft weg. */}
{scanStatus === 'done' && discSprachen
&& (discSprachen.audio.length > 0 || discSprachen.untertitel.length > 0) && (
<div className="rounded-xl border border-slate-200 dark:border-slate-800 overflow-hidden bg-slate-50/50 dark:bg-slate-950/50">
<div className="px-4 py-2.5 border-b border-slate-200 dark:border-slate-800">
<span className="text-sm font-medium text-slate-900 dark:text-slate-200">
Sprachen auf dieser Disc
</span>
<p className="text-xs text-slate-500 dark:text-slate-400">
{discSprachen.audio.length} Tonsprache{discSprachen.audio.length === 1 ? '' : 'n'}
{discSprachen.untertitel.length > 0
&& `, ${discSprachen.untertitel.length} Untertitelsprache${discSprachen.untertitel.length === 1 ? '' : 'n'}`}
{' — '}nichts angeklickt heißt <strong>alles behalten</strong>.
</p>
</div>
<div className="p-4 space-y-3">
{(['audio', 'untertitel'] as const).map(art => {
const liste = discSprachen[art]
if (liste.length === 0) return null
const wahl = art === 'audio' ? audioWahl : untertitelWahl
const setzen = art === 'audio' ? setAudioWahl : setUntertitelWahl
return (
<div key={art}>
<p className="text-xs font-medium mb-1.5 text-slate-700 dark:text-slate-300">
{art === 'audio' ? 'Tonspuren' : 'Untertitel'}
</p>
<div className="flex flex-wrap gap-2">
{liste.map(s => {
const an = wahl.has(s.lang)
return (
<button
key={s.lang}
onClick={() => {
const neu = new Set(wahl)
if (an) neu.delete(s.lang); else neu.add(s.lang)
setzen(neu)
}}
className={`px-3 py-1.5 rounded-lg text-xs font-medium border transition-colors ${
an
? 'bg-amber-500 border-amber-500 text-slate-950 font-bold'
: 'bg-slate-100 dark:bg-slate-900 border-slate-200 dark:border-slate-700 text-slate-600 dark:text-slate-300 hover:border-slate-300 dark:hover:border-slate-600'
}`}
>
{sprachName(s.lang, s.sprache)}
<span className="opacity-70"> ({s.lang})</span>
{s.spuren > 1 && <span className="opacity-70"> · {s.spuren}×</span>}
</button>
)
})}
</div>
</div>
)
})}
{/* Der wichtigste Satz: WANN die Auswahl greift. Sonst glaubt man,
die Disc würde unvollständig gerippt. */}
<p className="text-xs text-slate-500 dark:text-slate-400">
{audioWahl.size > 0 || untertitelWahl.size > 0 ? (
<>
Der Rip selbst bleibt <strong>vollständig und verlustfrei</strong> die
Auswahl wirkt beim Komprimieren. Du kannst also später jederzeit
Neu komprimieren" mit anderen Sprachen wählen, ohne die Disc noch
einmal einzulegen.
</>
) : (
<>Ohne Auswahl behält Rippy alle Sprachen wie bisher.</>
)}
</p>
</div>
</div>
)}
{/* Ordner-Browser — eingeklappt, siehe Begründung bei browserOffen */}
<div>
<button
onClick={() => {
const auf = !browserOffen
setBrowserOffen(auf)
if (auf && browseDirs.length === 0) laden('')
}}
className="flex items-center gap-1.5 text-xs text-slate-500 dark:text-slate-400 hover:text-slate-700 dark:hover:text-slate-200"
>
{browserOffen ? <ChevronDown size={14} /> : <ChevronRight size={14} />}
{selectedType === 'music'
? 'Anderen Zielordner wählen (nur für diesen Rip)'
: 'Ordner durchsuchen — Ziel oder Arbeitsordner (nur für diesen Rip)'}
</button>
{browserOffen && (
<div className="mt-2 rounded-xl border border-slate-200 dark:border-slate-800 overflow-hidden bg-slate-50/50 dark:bg-slate-950/50">
<div className="flex items-center gap-2 px-3 py-2 border-b border-slate-200 dark:border-slate-800 bg-slate-100/50 dark:bg-slate-900/50">
<button
onClick={() => browseParent && laden(browseParent)}
disabled={!browseParent}
className={`p-1 rounded disabled:opacity-30 ${theme === 'dark' ? 'hover:bg-slate-700 text-slate-400' : 'hover:bg-slate-200 text-slate-500'}`}
className="p-1 rounded-lg disabled:opacity-30 hover:bg-slate-200 dark:hover:bg-slate-800 text-slate-500 dark:text-slate-400"
title="Ordner hoch"
>
<ArrowUp size={16} />
</button>
<span className={`text-xs font-mono truncate flex-1 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>{browsePath}</span>
<button
onClick={() => setCustomPath(browsePath)}
className={`text-xs font-medium px-2.5 py-1 rounded transition-colors ${customPath === browsePath ? 'bg-indigo-600 text-white' : theme === 'dark' ? 'bg-slate-700 text-indigo-300 hover:bg-slate-600' : 'bg-slate-200 text-indigo-700 hover:bg-slate-300'}`}
<span className="text-xs font-mono truncate flex-1 text-slate-500 dark:text-slate-400">
{browsePath || 'Laufwerke'}
</span>
<Button
variant={customPath === browsePath ? 'amber' : 'secondary'}
size="sm"
disabled={!browsePath}
onClick={() => setCustomPath(customPath === browsePath ? '' : browsePath)}
>
{customPath === browsePath ? '✓ gewählt' : 'Diesen Ordner nutzen'}
</button>
{customPath === browsePath ? '✓ Ziel' : 'Als Ziel'}
</Button>
{/* Der zweite Knopf ist der Grund, warum es diesen Browser für
das Arbeitsverzeichnis überhaupt braucht: Die Schnellwahl
darüber kennt nur Laufwerke und Unterordner der Ablage. Ein
beliebiger Ordner etwa D:\Rippy-Arbeit ging bisher gar
nicht (momentan geht das nicht", 28.08.2026). */}
{selectedType !== 'music' && (
<Button
variant={arbeitsDir === browsePath ? 'amber' : 'secondary'}
size="sm"
disabled={!browsePath}
onClick={() => {
if (arbeitsDir === browsePath) { setArbeitsDir(''); return }
setEigenesArbeitsZiel(browsePath)
setArbeitsDir(browsePath)
}}
>
{arbeitsDir === browsePath ? '✓ Arbeitsordner' : 'Als Arbeitsordner'}
</Button>
)}
</div>
<div className="max-h-40 overflow-y-auto">
{browseDirs.length === 0 && browseFiles.length === 0 ? (
<p className={`text-xs px-3 py-3 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>Ordner ist leer</p>
) : (
<>
<div className="max-h-36 overflow-y-auto p-1">
{browseDirs.map(d => (
<button
key={d.path}
onClick={() => laden(d.path)}
className={`w-full flex items-center gap-2 px-3 py-2 text-sm text-left transition-colors ${theme === 'dark' ? 'text-slate-300 hover:bg-slate-700' : 'text-slate-700 hover:bg-slate-100'}`}
className="w-full flex items-center gap-2 px-3 py-1.5 text-xs text-left rounded-lg transition-colors text-slate-700 dark:text-slate-300 hover:bg-slate-100 dark:hover:bg-slate-800"
>
<Folder size={15} className={theme === 'dark' ? 'text-slate-500' : 'text-slate-400'} />
<Folder size={14} className="text-slate-400" />
{d.name}
</button>
))}
{browseFiles.map(f => (
<div key={f.name} className={`flex items-center gap-2 px-3 py-1.5 text-sm ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
<File size={14} className="flex-shrink-0" />
<span className="truncate">{f.name}</span>
{f.size_mb != null && (
<span className="ml-auto text-xs flex-shrink-0">
{f.size_mb >= 1024 ? `${(f.size_mb / 1024).toFixed(1)} GB` : `${f.size_mb} MB`}
</span>
{browseDirs.length === 0 && (
<p className="px-3 py-1.5 text-xs text-slate-400">Keine Unterordner.</p>
)}
</div>
))}
</>
)}
</div>
)}
</div>
{/* Gewähltes Ziel */}
<div className={`flex items-center gap-2 text-sm px-3 py-2 rounded-lg ${theme === 'dark' ? 'bg-slate-900' : 'bg-slate-50'}`}>
{customPath ? <FolderOpen size={16} className="text-indigo-500" /> : <CheckCircle size={16} className="text-emerald-500" />}
<span className={`font-mono text-xs truncate ${theme === 'dark' ? 'text-slate-300' : 'text-slate-600'}`}>
{customPath || targets.find(t => t.type === selectedType)?.path}
{/* Gewähltes Ziel Display */}
<div className="flex items-center gap-2 text-sm px-3.5 py-2.5 rounded-xl bg-slate-100 dark:bg-slate-900 border border-slate-200 dark:border-slate-800">
{customPath ? <FolderOpen size={16} className="text-amber-500" /> : <CheckCircle size={16} className="text-emerald-500" />}
<span className="font-mono text-xs truncate text-slate-700 dark:text-slate-300">
{zielPfad}
</span>
</div>
</div>
{/* Footer */}
<div className={`px-6 py-4 border-t transition-colors duration-300 ${theme === 'dark' ? 'border-slate-700' : 'border-slate-200'} flex justify-end gap-3`}>
<button
onClick={onClose}
className={`px-4 py-2 rounded-lg text-sm font-medium transition-colors ${theme === 'dark' ? 'text-slate-400 hover:bg-slate-700' : 'text-slate-600 hover:bg-slate-100'}`}
>
<div className="flex justify-end gap-3 pt-3 border-t border-slate-200 dark:border-slate-800">
<Button variant="secondary" onClick={onClose}>
Abbrechen
</button>
<button
onClick={handleSave}
className="px-4 py-2 rounded-lg bg-indigo-600 text-white text-sm font-medium hover:bg-indigo-700 transition-colors shadow-lg shadow-indigo-500/30"
>
</Button>
<Button variant="amber" onClick={handleSave}>
Rippen starten
</button>
</div>
</Button>
</div>
</div>
</Modal>
)
}
+193 -87
View File
@@ -1,17 +1,17 @@
import { useState, useEffect } from 'react'
import { HardDrive, Plus, Trash2, CheckCircle, AlertCircle, RefreshCw, Folder, File, ArrowUp, FolderPlus } from 'lucide-react'
import { HardDrive, Plus, Trash2, CheckCircle, AlertCircle, AlertTriangle, RefreshCw, Wrench, Folder, File, ArrowUp, FolderPlus } from 'lucide-react'
import { api } from '../lib/api'
import { useDarkMode } from '../context/ThemeContext'
import { useToast } from '../context/ToastContext'
// Netzwerk-Speicherziele (NAS/PC-Freigaben) direkt aus dem UI einhängen —
// jedes Ziel erscheint danach in der Ziel-Auswahl beim Rippen.
import { Card, CardHeader, CardTitle, CardContent } from './ui/Card'
import { Button } from './ui/Button'
import { Input, Select } from './ui/Input'
interface Mount {
name: string
type: string
source: string
mounted: boolean
reachable?: boolean
has_credentials: boolean
}
@@ -41,7 +41,7 @@ export default function StorageMounts() {
const [browseDirs, setBrowseDirs] = useState<{ name: string, path: string }[]>([])
const [browseFiles, setBrowseFiles] = useState<{ name: string, size_mb: number | null }[]>([])
const [neuerOrdner, setNeuerOrdner] = useState('')
const { theme } = useDarkMode()
const [browserOffen, setBrowserOffen] = useState(false)
const { toast } = useToast()
const browsen = async (pfad: string) => {
@@ -71,12 +71,12 @@ export default function StorageMounts() {
const laden = async (manuell = false) => {
try {
const [m, t] = await Promise.all([
const [m, t] = await Promise.allSettled([
api.get('/storage-mounts'),
api.get('/storage-targets'),
])
setMounts(m.data)
setTargets(t.data)
if (m.status === 'fulfilled') setMounts(m.value.data || [])
if (t.status === 'fulfilled') setTargets(t.value.data || [])
if (manuell) toast('success', 'Speicherziele aktualisiert')
} catch {
if (manuell) toast('error', 'Speicherziele konnten nicht geladen werden')
@@ -150,35 +150,51 @@ export default function StorageMounts() {
}
}
const feld = `w-full px-3 py-2 border rounded-lg focus:ring-2 focus:ring-indigo-500 focus:border-transparent ${theme === 'dark' ? 'bg-slate-800 border-slate-600 text-slate-200' : 'bg-white border-slate-300 text-slate-900'}`
const reparieren = async (mountName: string) => {
setBusy(true)
try {
const r = await api.post(`/storage-mounts/${mountName}/repair`)
toast(r.data.writable ? 'success' : 'error',
r.data.writable ? `${mountName}" neu verbunden` : `${mountName}" verbunden, aber nur lesbar`)
laden()
} catch (e: any) {
toast('error', e?.response?.data?.detail || 'Reparatur fehlgeschlagen — NAS erreichbar?')
} finally {
setBusy(false)
}
}
return (
<div className="space-y-6">
{/* Vorhandene Ziele */}
<div>
<div className="flex items-center justify-between mb-3">
<h3 className={`font-medium ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>Verfügbare Ziele</h3>
<button onClick={() => laden(true)} title="Ziele neu laden" className={`p-1.5 rounded ${theme === 'dark' ? 'hover:bg-slate-700 text-slate-400' : 'hover:bg-slate-100 text-slate-500'}`}>
<Card>
<CardHeader>
<CardTitle className="flex items-center gap-2">
<HardDrive size={20} className="text-amber-500" />
<span>Verfügbare Ziele</span>
</CardTitle>
<Button variant="ghost" size="sm" onClick={() => laden(true)} title="Ziele neu laden">
<RefreshCw size={16} />
</button>
</div>
</Button>
</CardHeader>
<CardContent>
{targets.length === 0 ? (
<p className={`text-sm ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>Noch keine Unterordner in /app/media sie entstehen beim ersten Rip oder Mount.</p>
<p className="text-sm text-slate-500 dark:text-slate-400">Noch keine Unterordner in /app/media sie entstehen beim ersten Rip oder Mount.</p>
) : (
<div className="space-y-2">
<div className="space-y-2.5">
{targets.map(t => (
<div key={t.path} className={`flex items-center justify-between p-3 rounded-lg ${theme === 'dark' ? 'bg-slate-800' : 'bg-slate-50'}`}>
<div key={t.path} className="flex items-center justify-between p-3.5 rounded-xl border border-slate-200/80 dark:border-slate-800 bg-slate-50 dark:bg-slate-950/80">
<div className="flex items-center gap-3">
<HardDrive size={18} className={t.is_mount ? 'text-emerald-500' : theme === 'dark' ? 'text-slate-500' : 'text-slate-400'} />
<HardDrive size={18} className={t.is_mount ? 'text-amber-500' : 'text-slate-400 dark:text-slate-500'} />
<div>
<span className={`text-sm font-medium ${theme === 'dark' ? 'text-slate-200' : 'text-slate-800'}`}>{t.name}</span>
<span className={`text-xs ml-2 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
<span className="text-sm font-medium text-slate-900 dark:text-slate-200">{t.name}</span>
<span className="text-xs ml-2 text-slate-500 dark:text-slate-400">
{t.is_mount ? 'Netzwerk-Mount' : 'lokal'}{t.free_gb != null ? ` · ${t.free_gb} GB frei` : ''}
</span>
</div>
</div>
{mounts.some(m => m.name === t.name) && (
<button onClick={() => entfernen(t.name)} disabled={busy} className="p-1.5 rounded text-rose-500 hover:bg-rose-500/10">
<button onClick={() => entfernen(t.name)} disabled={busy} className="p-1.5 rounded-lg text-rose-500 hover:bg-rose-500/10 transition-colors">
<Trash2 size={16} />
</button>
)}
@@ -186,61 +202,129 @@ export default function StorageMounts() {
))}
</div>
)}
</div>
</CardContent>
</Card>
{/* Lokale Ordner durchsuchen + anlegen */}
<div className={`rounded-lg border overflow-hidden ${theme === 'dark' ? 'border-slate-700' : 'border-slate-200'}`}>
<div className={`flex items-center gap-2 px-3 py-2 border-b ${theme === 'dark' ? 'border-slate-700 bg-slate-900' : 'border-slate-200 bg-slate-50'}`}>
{/* Netzwerk-Mounts mit Status zeigt AUCH tote/getrennte Mounts, damit
man sie reparieren oder entfernen kann (Bug 24.07.: ein toter NAS-Mount
verschwand aus Verfügbare Ziele" und ließ sich nicht neu anlegen). */}
{mounts.length > 0 && (
<Card>
<CardHeader>
<CardTitle className="flex items-center gap-2">
<HardDrive size={20} className="text-amber-500" />
<span>Netzwerk-Mounts</span>
</CardTitle>
</CardHeader>
<CardContent>
<div className="space-y-2.5">
{mounts.map(m => {
const aktiv = m.mounted && m.reachable !== false
const tot = m.mounted && m.reachable === false
return (
<div key={m.name} className="flex items-center justify-between gap-3 p-3.5 rounded-xl border border-slate-200/80 dark:border-slate-800 bg-slate-50 dark:bg-slate-950/80">
<div className="flex items-center gap-3 min-w-0">
{aktiv
? <CheckCircle size={18} className="text-emerald-500 flex-shrink-0" />
: tot
? <AlertTriangle size={18} className="text-amber-500 flex-shrink-0" />
: <AlertCircle size={18} className="text-slate-400 flex-shrink-0" />}
<div className="min-w-0">
<span className="text-sm font-medium text-slate-900 dark:text-slate-200">{m.name}</span>
<span className="text-xs ml-2 font-mono text-slate-500 dark:text-slate-400">{m.source}</span>
<p className={`text-xs ${aktiv ? 'text-emerald-600 dark:text-emerald-400' : tot ? 'text-amber-600 dark:text-amber-400' : 'text-slate-500 dark:text-slate-400'}`}>
{aktiv ? 'aktiv & erreichbar' : tot ? 'verbunden, aber NICHT erreichbar (NAS aus/weg?)' : 'getrennt'}
</p>
</div>
</div>
<div className="flex items-center gap-1.5 flex-shrink-0">
{!aktiv && (
<Button variant="secondary" size="sm" onClick={() => reparieren(m.name)} disabled={busy} title="Neu verbinden (gespeicherte Zugangsdaten)">
<Wrench size={14} /> Reparieren
</Button>
)}
<button onClick={() => entfernen(m.name)} disabled={busy} className="p-1.5 rounded-lg text-rose-500 hover:bg-rose-500/10 transition-colors" title="Entfernen">
<Trash2 size={16} />
</button>
</div>
</div>
)
})}
</div>
</CardContent>
</Card>
)}
{/* Ordner-Verwaltung */}
<Card>
<button
onClick={() => setBrowserOffen(!browserOffen)}
className="w-full flex items-center justify-between p-6 text-left transition-colors hover:bg-slate-50/50 dark:hover:bg-slate-800/30"
>
<div>
<h3 className="text-sm font-semibold text-slate-900 dark:text-slate-100">
Ordner-Verwaltung (optional)
</h3>
<p className="text-xs mt-0.5 text-slate-500 dark:text-slate-400">
Unterordner in der Ablage anschauen und neue anlegen z. B. anime" oder „doku".
</p>
</div>
<span className="text-xs flex-shrink-0 ml-3 text-amber-600 dark:text-amber-400 font-medium">
{browserOffen ? 'zuklappen ▲' : 'aufklappen ▼'}
</span>
</button>
{browserOffen && (
<div className="border-t border-slate-200/80 dark:border-slate-800/80">
<div className="flex items-center gap-2 px-4 py-2.5 bg-slate-50 dark:bg-slate-950/90 border-b border-slate-200/80 dark:border-slate-800">
<button
onClick={() => browseParent && browsen(browseParent)}
disabled={!browseParent}
className={`p-1 rounded disabled:opacity-30 ${theme === 'dark' ? 'hover:bg-slate-700 text-slate-400' : 'hover:bg-slate-200 text-slate-500'}`}
className="p-1.5 rounded-lg disabled:opacity-30 hover:bg-slate-200 dark:hover:bg-slate-800 text-slate-500 dark:text-slate-400 transition-colors"
title="Ordner hoch"
>
<ArrowUp size={16} />
</button>
<span className={`text-xs font-mono truncate flex-1 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>{browsePath}</span>
<span className="text-xs font-mono truncate flex-1 text-slate-500 dark:text-slate-400">{browsePath}</span>
<input
value={neuerOrdner}
onChange={e => setNeuerOrdner(e.target.value)}
placeholder="neuer-ordner"
className={`w-32 px-2 py-1 text-xs border rounded ${theme === 'dark' ? 'bg-slate-800 border-slate-600 text-slate-200' : 'bg-white border-slate-300 text-slate-900'}`}
className="w-36 px-2.5 py-1 text-xs border rounded-lg bg-white dark:bg-slate-900 border-slate-200 dark:border-slate-700 text-slate-900 dark:text-slate-100 focus:outline-none focus:ring-2 focus:ring-amber-500/50"
/>
<button
onClick={ordnerAnlegen}
disabled={!neuerOrdner}
className={`p-1.5 rounded disabled:opacity-30 text-indigo-500 ${theme === 'dark' ? 'hover:bg-slate-700' : 'hover:bg-slate-200'}`}
className="p-1.5 rounded-lg disabled:opacity-30 text-amber-500 hover:bg-amber-500/10 transition-colors"
title="Ordner anlegen"
>
<FolderPlus size={16} />
</button>
</div>
<div className="max-h-36 overflow-y-auto">
<div className="max-h-44 overflow-y-auto p-2">
{browseDirs.length === 0 && browseFiles.length === 0 ? (
<p className={`text-xs px-3 py-3 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>Ordner ist leer</p>
<p className="text-xs p-3 text-slate-400 dark:text-slate-500">Ordner ist leer</p>
) : (
<>
{browseDirs.map(d => (
<button
key={d.path}
onClick={() => browsen(d.path)}
className={`w-full flex items-center gap-2 px-3 py-2 text-sm text-left transition-colors ${theme === 'dark' ? 'text-slate-300 hover:bg-slate-700' : 'text-slate-700 hover:bg-slate-100'}`}
className="w-full flex items-center gap-2 px-3 py-2 text-sm rounded-lg text-left transition-colors text-slate-700 dark:text-slate-300 hover:bg-slate-100 dark:hover:bg-slate-800"
>
<Folder size={15} className={theme === 'dark' ? 'text-slate-500' : 'text-slate-400'} />
<Folder size={15} className="text-slate-400 dark:text-slate-500" />
{d.name}
</button>
))}
{/* Dateien mit anzeigen (grau, nicht klickbar) vorher wirkte
z. B. der bluray-Ordner leer", obwohl die MKVs drinlagen */}
{browseFiles.map(f => (
<div
key={f.name}
className={`flex items-center gap-2 px-3 py-1.5 text-sm ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}
className="flex items-center gap-2 px-3 py-1.5 text-sm text-slate-400 dark:text-slate-500"
>
<File size={14} className="flex-shrink-0" />
<span className="truncate">{f.name}</span>
{f.size_mb != null && (
<span className="ml-auto text-xs flex-shrink-0">
<span className="ml-auto text-xs flex-shrink-0 font-mono">
{f.size_mb >= 1024 ? `${(f.size_mb / 1024).toFixed(1)} GB` : `${f.size_mb} MB`}
</span>
)}
@@ -250,89 +334,111 @@ export default function StorageMounts() {
)}
</div>
</div>
)}
</Card>
{/* Neues Netzwerk-Ziel */}
<div className={`rounded-lg p-4 border ${theme === 'dark' ? 'border-slate-700 bg-slate-800/50' : 'border-slate-200 bg-slate-50'}`}>
<h3 className={`font-medium mb-3 flex items-center gap-2 ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>
<Plus size={18} className="text-indigo-500" /> Netzwerk-Ziel hinzufügen
</h3>
<div className="grid grid-cols-1 md:grid-cols-2 gap-3">
<div>
<label className={`block text-xs font-medium mb-1 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>Name (klein, ohne Leerzeichen)</label>
<input value={name} onChange={e => setName(e.target.value.toLowerCase())} className={feld} placeholder="nas-filme" />
</div>
<div>
<label className={`block text-xs font-medium mb-1 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>Typ</label>
<select value={typ} onChange={e => setTyp(e.target.value as 'nfs' | 'cifs')} className={feld}>
<Card>
<CardHeader>
<CardTitle className="flex items-center gap-2">
<Plus size={20} className="text-amber-500" />
<span>Netzwerk-Ziel hinzufügen</span>
</CardTitle>
</CardHeader>
<CardContent className="space-y-4">
<div className="grid grid-cols-1 md:grid-cols-2 gap-4">
<Input
label="Name (klein, ohne Leerzeichen)"
value={name}
onChange={e => setName(e.target.value.toLowerCase())}
placeholder="nas-filme"
/>
<Select
label="Typ"
value={typ}
onChange={e => setTyp(e.target.value as 'nfs' | 'cifs')}
>
<option value="nfs">NFS (NAS/Linux)</option>
<option value="cifs">SMB/CIFS (Windows-Freigabe, NAS)</option>
</select>
</div>
</Select>
{typ === 'nfs' ? (
<div className="md:col-span-2">
<label className={`block text-xs font-medium mb-1 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>
Quelle (host:/export/pfad)
</label>
<input value={source} onChange={e => setSource(e.target.value)} className={feld} placeholder="192.168.1.10:/volume1/filme" />
<Input
label="Quelle (host:/export/pfad)"
value={source}
onChange={e => setSource(e.target.value)}
placeholder="192.168.1.10:/volume1/filme"
/>
</div>
) : (
<>
<div className="md:col-span-2">
<label className={`block text-xs font-medium mb-1 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>
Rechner (dein PC oder NAS Name oder IP)
</label>
<input value={host} onChange={e => setHost(e.target.value)} className={feld} placeholder="192.168.178.20 oder TOBIS-PC" />
<Input
label="Rechner (dein PC oder NAS — Name oder IP)"
value={host}
onChange={e => setHost(e.target.value)}
placeholder="z. B. 192.168.1.20 oder MEIN-NAS"
/>
</div>
{/* Zugangsdaten VOR der Freigaben-Abfrage (Befund 24.07.):
Windows/NAS lehnen Gast-Abfragen fast immer mit
ACCESS_DENIED ab ohne Benutzer/Passwort scheiterte der
Knopf darunter scheinbar grundlos. */}
<div>
<label className={`block text-xs font-medium mb-1 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>Benutzer</label>
<input value={username} onChange={e => setUsername(e.target.value)} className={feld} autoComplete="off" placeholder="Freigabe-Benutzer" />
</div>
<div>
<label className={`block text-xs font-medium mb-1 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>Passwort</label>
<input type="password" value={password} onChange={e => setPassword(e.target.value)} className={feld} autoComplete="new-password" />
</div>
<p className={`md:col-span-2 text-xs -mt-1 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
Windows-PCs und die meisten NAS verlangen Benutzer + Passwort ohne Angaben
versucht Rippy einen Gast-Zugriff, der meist mit Zugriff verweigert" endet.
<Input
label="Benutzer"
value={username}
onChange={e => setUsername(e.target.value)}
autoComplete="off"
placeholder="Freigabe-Benutzer"
/>
<Input
label="Passwort"
type="password"
value={password}
onChange={e => setPassword(e.target.value)}
autoComplete="new-password"
/>
<p className="md:col-span-2 text-xs text-slate-500 dark:text-slate-400">
Windows-PCs und die meisten NAS verlangen Benutzer + Passwort ohne Angaben versucht Rippy einen Gast-Zugriff.
</p>
<div className="md:col-span-2">
<button
<Button
variant="secondary"
size="sm"
onClick={freigabenAuflisten}
disabled={!host || sharesBusy}
className={`px-4 py-2 rounded-lg text-sm font-medium transition-colors disabled:opacity-40 ${theme === 'dark' ? 'bg-slate-700 text-indigo-300 hover:bg-slate-600' : 'bg-slate-200 text-indigo-700 hover:bg-slate-300'}`}
>
{sharesBusy ? 'Suche…' : 'Freigaben auflisten'}
</button>
</Button>
</div>
{shares.length > 0 && (
<div className="md:col-span-2">
<label className={`block text-xs font-medium mb-1 ${theme === 'dark' ? 'text-slate-400' : 'text-slate-500'}`}>Freigabe wählen</label>
<select value={selectedShare} onChange={e => setSelectedShare(e.target.value)} className={feld}>
<Select
label="Freigabe wählen"
value={selectedShare}
onChange={e => setSelectedShare(e.target.value)}
>
{shares.map(s => <option key={s} value={s}>{s}</option>)}
</select>
</Select>
</div>
)}
</>
)}
</div>
<button
<Button
variant="amber"
onClick={hinzufuegen}
disabled={busy || !name || (typ === 'nfs' ? !source : !(host && selectedShare))}
className="mt-4 px-4 py-2 rounded-lg bg-indigo-600 text-white text-sm font-medium hover:bg-indigo-700 transition-colors disabled:opacity-40"
>
{busy ? 'Hänge ein…' : 'Einhängen & speichern'}
</button>
</Button>
{feedback && (
<p className={`mt-3 text-sm flex items-center gap-2 ${feedback.startsWith('✓') ? 'text-emerald-500' : 'text-rose-500'}`}>
<p className={`text-sm flex items-center gap-2 font-medium ${feedback.startsWith('✓') ? 'text-emerald-500' : 'text-rose-500'}`}>
{feedback.startsWith('✓') ? <CheckCircle size={16} /> : <AlertCircle size={16} />}
{feedback}
</p>
)}
</div>
</CardContent>
</Card>
</div>
)
}
+208 -44
View File
@@ -1,28 +1,40 @@
import { useState, useEffect } from 'react'
import { Server, RefreshCw, Copy, CheckCircle } from 'lucide-react'
import { Server, RefreshCw, Copy, CheckCircle, Trash2, Download } from 'lucide-react'
import { api } from '../lib/api'
import { useDarkMode } from '../context/ThemeContext'
import { simdWarnung } from '../lib/encoder'
import { useToast } from '../context/ToastContext'
// Worker-Verwaltung (Commander-Anforderung 23.07.): Welche Maschinen encoden,
// sind sie erreichbar, und wie bindet man eine neue an? Ein Worker "installiert
// sich" über einen Copy-Paste-Befehl auf der Zielmaschine — danach taucht er
// hier automatisch auf und zieht sich Kompressions-Jobs aus der Warteschlange.
import { Card, CardHeader, CardTitle, CardContent } from './ui/Card'
import { Button } from './ui/Button'
import { Input } from './ui/Input'
import { useStrom } from '../lib/useEventStream'
interface WorkerInfo {
name: string
encoders: string[]
last_seen?: string
online?: boolean
info?: {
hostname?: string
ip?: string
makemkv?: string
handbrake?: string
cpu_modell?: string
cpu_kerne?: string
cpu_simd?: string
handbrake_encoder?: string
rippy_version?: string
}
}
const ENCODER_LABELS: Record<string, string> = {
'cpu-x264': 'CPU · H.264',
'cpu-x265': 'CPU · H.265',
'cpu-av1': 'CPU · AV1 (SVT)',
'vaapi': 'GPU · VAAPI (AMD/Intel)',
'nvenc': 'GPU · NVENC (NVIDIA)',
}
function relativeZeit(iso?: string): string {
if (!iso) return 'nie'
const sekunden = Math.floor((Date.now() - new Date(iso).getTime()) / 1000)
@@ -33,29 +45,65 @@ function relativeZeit(iso?: string): string {
export default function WorkerVerwaltung() {
const [workers, setWorkers] = useState<WorkerInfo[]>([])
const [serverVersion, setServerVersion] = useState<string>('dev')
const [kopiert, setKopiert] = useState(false)
const { theme } = useDarkMode()
const [variante, setVariante] = useState<'linux' | 'windows'>('linux')
// BEWUSST leer: kein window.location.hostname-Default. Der füllte früher
// die Adresse, über die man das UI geöffnet hat (z. B. den eigenen PC hinter
// einem Proxy/Forward) — und die ist NICHT zwingend die direkte LAN-IP der
// Rippy-Maschine, die der Worker für Redis/Postgres braucht. Lieber bewusst
// eintragen lassen als eine falsche Adresse vorgaukeln.
const [rippyHost, setRippyHost] = useState('')
const { toast } = useToast()
const strom = useStrom()
// Für die Befehle: leeres Feld → sichtbarer Platzhalter (Befehl ist dann
// erkennbar unvollständig, statt still auf die falsche Adresse zu zeigen).
const hostFuerBefehl = rippyHost || '<RIPPY-IP>'
const siehtOeffentlichAus =
rippyHost !== '' &&
!/^(\d{1,3}\.){3}\d{1,3}$/.test(rippyHost) &&
!rippyHost.endsWith('.local') &&
rippyHost !== 'localhost' &&
rippyHost.includes('.')
const laden = (manuell = false) => {
api.get('/capabilities')
.then(r => {
setWorkers(r.data.workers || [])
if (r.data.server_version) setServerVersion(r.data.server_version)
if (manuell) toast('success', 'Worker-Liste aktualisiert')
})
.catch(() => { if (manuell) toast('error', 'Worker-Liste konnte nicht geladen werden') })
}
useEffect(() => {
laden()
const interval = setInterval(laden, 15000)
return () => clearInterval(interval)
}, [])
// Die Worker-Liste kommt aus dem Live-Strom. /capabilities wird nur noch
// EINMAL geholt — dort steht ausser der Liste die Server-Version, und die
// aendert sich nur beim Deploy. Vorher lief der Abruf alle 15 s.
useEffect(() => { laden() }, [])
const rippyHost = window.location.hostname
const installBefehl = [
useEffect(() => {
if (strom.workers.length || strom.verbunden) {
setWorkers(strom.workers as WorkerInfo[])
}
}, [strom.workers, strom.verbunden])
const installBefehl = variante === 'linux'
? [
`git clone <rippy-repo-url> rippy && cd rippy`,
`RIPPY_HOST=${rippyHost} docker compose -f deploy/remote-transcode-worker.yml up -d --build`,
`RIPPY_HOST=${hostFuerBefehl} WORKER_NAME=mein-pc \\`,
` docker compose -f deploy/remote-transcode-worker.yml up -d --build`,
].join('\n')
: [
// Standard-Ziel ist "C:\Program Files\Rippy Worker" - dorthin darf nur
// ein Administrator schreiben, deshalb der Hinweis direkt im Befehl.
// Die .exe fragt selbst per UAC; hier muss die Konsole erhöht sein.
`# PowerShell als Administrator starten (Standard-Ziel: Programme)`,
`iwr http://${hostFuerBefehl}/api/worker-setup/windows -OutFile install-rippy-worker.ps1`,
`powershell -ExecutionPolicy Bypass -File .\\install-rippy-worker.ps1 \``,
` -RippyHost ${hostFuerBefehl} -WorkerName mein-pc`,
`# Ohne Adminrechte: -InstallDir "$env:LOCALAPPDATA\\Rippy Worker" anhaengen`,
].join('\n')
const kopieren = () => {
@@ -65,71 +113,187 @@ export default function WorkerVerwaltung() {
})
}
// Fertige Installer-.exe (Rippy-Icon, kein Konsolenfenster) direkt laden.
// Generisch — die GUI fragt die Rippy-Adresse selbst ab.
const exeHerunterladen = () => {
const a = document.createElement('a')
a.href = '/api/worker-setup/windows-exe'
a.download = 'RippyWorkerSetup.exe'
document.body.appendChild(a); a.click(); a.remove()
toast('success', 'RippyWorkerSetup.exe wird heruntergeladen — doppelklicken zum Installieren')
}
return (
<div className="space-y-6">
{/* Verbundene Worker */}
<div>
<div className="flex items-center justify-between mb-3">
<h3 className={`font-medium ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>Verbundene Worker</h3>
<button onClick={() => laden(true)} title="Worker neu laden" className={`p-1.5 rounded ${theme === 'dark' ? 'hover:bg-slate-700 text-slate-400' : 'hover:bg-slate-100 text-slate-500'}`}>
<Card>
<CardHeader>
<CardTitle className="flex items-center gap-2">
<Server size={20} className="text-amber-500" />
<span>Verbundene Worker</span>
</CardTitle>
<Button variant="ghost" size="sm" onClick={() => laden(true)} title="Worker neu laden">
<RefreshCw size={16} />
</button>
</div>
</Button>
</CardHeader>
<CardContent>
{workers.length === 0 ? (
<p className={`text-sm ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>Noch kein Worker gemeldet.</p>
<p className="text-sm text-slate-500 dark:text-slate-400">Noch kein Worker gemeldet.</p>
) : (
<div className="space-y-2">
<div className="space-y-2.5">
{workers.map(w => (
<div key={w.name} className={`flex items-center justify-between p-3 rounded-lg ${theme === 'dark' ? 'bg-slate-800' : 'bg-slate-50'}`}>
<div key={w.name} className="flex items-center justify-between p-3.5 rounded-xl border border-slate-200/80 dark:border-slate-800 bg-slate-50 dark:bg-slate-950/80">
<div className="flex items-center gap-3 min-w-0">
<span
className={`w-2.5 h-2.5 rounded-full flex-shrink-0 ${w.online ? 'bg-emerald-500' : 'bg-rose-500'}`}
className={`w-2.5 h-2.5 rounded-full flex-shrink-0 ${w.online ? 'bg-emerald-500 shadow-sm shadow-emerald-500/50' : 'bg-rose-500'}`}
title={w.online ? 'erreichbar (Ping OK)' : 'nicht erreichbar'}
/>
<Server size={18} className={theme === 'dark' ? 'text-slate-400' : 'text-slate-500'} />
<Server size={18} className="text-slate-400 dark:text-slate-500" />
<div className="min-w-0">
<p className={`text-sm font-mono truncate ${theme === 'dark' ? 'text-slate-200' : 'text-slate-800'}`}>{w.name}</p>
<p className={`text-xs ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
<p className="text-sm font-medium truncate text-slate-900 dark:text-slate-200">{w.name}</p>
<p className="text-xs text-slate-500 dark:text-slate-400">
{w.online ? 'online' : 'offline'} · Lebenszeichen {relativeZeit(w.last_seen)}
{w.info?.ip ? ` · IP ${w.info.ip}` : ''}
{w.info?.hostname && w.info.hostname !== w.name ? ` · ID ${w.info.hostname}` : ''}
</p>
{w.info?.rippy_version && (
<p className={`text-xs ${w.info.rippy_version !== serverVersion ? 'text-rose-500 font-semibold' : 'text-slate-500 dark:text-slate-400'}`}>
Version {w.info.rippy_version} {w.info.rippy_version !== serverVersion ? `(Veraltet! Server hat ${serverVersion})` : ''}
</p>
)}
{(w.info?.cpu_kerne || w.info?.cpu_simd) && (
<p className="text-xs text-slate-500 dark:text-slate-400" title={w.info?.cpu_modell || ''}>
{w.info?.cpu_kerne ? `${w.info.cpu_kerne} Kerne` : ''}
{w.info?.cpu_kerne && w.info?.cpu_simd ? ' · ' : ''}
{w.info?.cpu_simd ? `Vektorbefehle ${w.info.cpu_simd}` : ''}
</p>
)}
{simdWarnung(w.info?.cpu_simd) && (
<p className="mt-1 text-xs text-amber-600 dark:text-amber-400 max-w-xl">
{simdWarnung(w.info?.cpu_simd)}
</p>
)}
</div>
</div>
<div className="flex items-center gap-2">
<div className="flex flex-wrap gap-1 justify-end">
{w.encoders.map(e => (
<span key={e} className={`text-xs px-2 py-0.5 rounded ${e.startsWith('cpu') ? (theme === 'dark' ? 'bg-slate-700 text-slate-300' : 'bg-slate-200 text-slate-600') : 'bg-emerald-600/20 text-emerald-500 font-medium'}`}>
<span key={e} className={`text-xs px-2.5 py-0.5 rounded-md font-medium border ${
e.startsWith('cpu')
? 'bg-slate-200/80 dark:bg-slate-800 text-slate-700 dark:text-slate-300 border-slate-300 dark:border-slate-700'
: 'bg-emerald-500/15 text-emerald-600 dark:text-emerald-400 border-emerald-500/30'
}`}>
{ENCODER_LABELS[e] || e}
</span>
))}
</div>
{!w.online && (
<button
onClick={() => {
api.delete(`/workers/${encodeURIComponent(w.name)}`)
.then(() => { toast('success', `${w.name}" entfernt — ein aktiver Worker meldet sich binnen 1 min zurück`); laden() })
.catch(() => toast('error', 'Entfernen fehlgeschlagen'))
}}
title="Verwaisten Eintrag entfernen"
className="p-1.5 rounded-lg text-rose-500 hover:bg-rose-500/10 transition-colors"
>
<Trash2 size={14} />
</button>
)}
</div>
</div>
))}
</div>
)}
</div>
</CardContent>
</Card>
{/* Neue Maschine anbinden */}
<div className={`rounded-lg p-4 border ${theme === 'dark' ? 'border-slate-700 bg-slate-800/50' : 'border-slate-200 bg-slate-50'}`}>
<h3 className={`font-medium mb-1 ${theme === 'dark' ? 'text-slate-100' : 'text-slate-900'}`}>Maschine als Encoding-Worker anbinden</h3>
<p className={`text-xs mb-3 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
Auf der Zielmaschine (Linux mit Docker, oder Windows mit Docker Desktop) diesen
Befehl ausführen der Worker verbindet sich, taucht oben in der Liste auf und
übernimmt ab dann automatisch Kompressions-Jobs. GPU vorhanden? Wird erkannt
und angezeigt. Voraussetzung: die Maschine erreicht diesen Rippy-Host im Netz.
<Card>
<CardHeader>
<CardTitle>Maschine als Encoding-Worker anbinden</CardTitle>
</CardHeader>
<CardContent className="space-y-4">
<div className="max-w-md">
<Input
label="LAN-IP der Rippy-Maschine (Docker-Host)"
value={rippyHost}
onChange={e => setRippyHost(e.target.value.trim())}
placeholder="z. B. 192.168.1.10"
/>
<p className="text-xs mt-2 text-slate-500 dark:text-slate-400">
Die IP der Maschine, auf der <strong>Rippy selbst</strong> (Docker) läuft meist deine
Server-/NAS-VM. <strong>Nicht</strong> die IP des PCs, auf dem der Worker läuft, und auch
dann diese direkte LAN-IP eintragen, wenn du dieses UI über eine andere Adresse
(Domain/Proxy/Portweiterleitung) geöffnet hast. Der Worker spricht Redis/Postgres direkt
an (Ports 6379/5432) das klappt nur mit der echten LAN-IP im Heimnetz.
</p>
<div className={`relative rounded-lg p-3 font-mono text-xs whitespace-pre overflow-x-auto ${theme === 'dark' ? 'bg-slate-950 text-slate-300' : 'bg-slate-900 text-slate-200'}`}>
{siehtOeffentlichAus && (
<p className="text-xs mt-2 p-3 rounded-xl bg-amber-500/10 border border-amber-500/20 text-amber-700 dark:text-amber-300">
Das sieht nach einer externen Domain aus (Reverse-Proxy) die geht nicht. Bitte die
<strong> LAN-IP</strong> der Rippy-Maschine eintragen die beginnt im Heimnetz
fast immer mit 192.168., 10. oder 172.16.172.31.
</p>
)}
</div>
<div className="flex gap-2">
{([['linux', '🐧 Linux (Docker)'], ['windows', '🪟 Windows (nativ, ohne Docker)']] as const).map(([wert, label]) => (
<Button
key={wert}
variant={variante === wert ? 'amber' : 'secondary'}
size="sm"
onClick={() => setVariante(wert)}
>
{label}
</Button>
))}
</div>
{/* Windows: fertige .exe als Haupt-Weg (Doppelklick, Icon, kein Konsolenfenster) */}
{variante === 'windows' && (
<div className="rounded-xl p-4 border border-amber-500/30 bg-amber-500/5 space-y-2">
<p className="text-sm text-slate-700 dark:text-slate-300">
<strong>Einfachster Weg:</strong> Installer (.exe) herunterladen, doppelklicken,
im Fenster Adresse + Name eintragen, Installieren". Kein Konsolenfenster.
Braucht nur Python 3.10+ auf dem PC kein Docker, kein git.
</p>
<Button variant="amber" onClick={exeHerunterladen}>
<Download size={16} /> Installer herunterladen (.exe)
</Button>
<p className="text-xs text-slate-700 dark:text-slate-300">
Im Installer-Fenster als Rippy-Adresse eintragen: <code className="font-semibold">{rippyHost.trim() || '<LAN-IP der Rippy-Maschine>'}</code>
</p>
<p className="text-xs text-slate-500 dark:text-slate-400">
Windows warnt beim ersten Start evtl. (Windows hat Ihren PC geschützt", unbekannter Herausgeber)
Weitere Informationen" → „Trotzdem ausführen". Die .exe holt Worker-Code und HandBrake nur von
deiner Rippy-Maschine bzw. dem offiziellen HandBrake-Release.
</p>
</div>
)}
<p className="text-xs text-slate-500 dark:text-slate-400">
{variante === 'linux'
? 'Auf der Linux-Maschine (mit Docker) ausführen — WORKER_NAME frei wählen, unter dem Namen taucht sie oben auf und übernimmt Kompressions-Jobs. GPU wird erkannt und angezeigt.'
: 'Alternativ (für Profis) per PowerShell-Befehl:'}
</p>
<div className="relative rounded-xl p-4 font-mono text-xs whitespace-pre overflow-x-auto bg-slate-900 text-slate-200 border border-slate-800">
{installBefehl}
<button
onClick={kopieren}
className="absolute top-2 right-2 p-1.5 rounded bg-slate-700 text-slate-300 hover:bg-slate-600"
className="absolute top-3 right-3 p-1.5 rounded-lg bg-slate-800 text-slate-300 hover:bg-slate-700 hover:text-white transition-colors"
title="Kopieren"
>
{kopiert ? <CheckCircle size={14} className="text-emerald-400" /> : <Copy size={14} />}
{kopiert ? <CheckCircle size={15} className="text-emerald-400" /> : <Copy size={15} />}
</button>
</div>
<p className={`text-xs mt-2 ${theme === 'dark' ? 'text-slate-500' : 'text-slate-400'}`}>
Eine geführte Ein-Klick-Installation (SSH) ist als Ausbaustufe geplant.
<p className="text-xs text-slate-500 dark:text-slate-400">
Beide Varianten bedienen nur die Kompressions-Queue gerippt wird immer hier, wo das Laufwerk hängt.
</p>
</div>
</CardContent>
</Card>
</div>
)
}
+42
View File
@@ -0,0 +1,42 @@
import { Disc } from 'lucide-react'
import { STATUS_STYLES, DISC_TYPE_STYLES } from '../../lib/design'
interface StatusBadgeProps {
status: string
className?: string
}
export function StatusBadge({ status, className = '' }: StatusBadgeProps) {
const config = STATUS_STYLES[status as keyof typeof STATUS_STYLES] || {
badge: 'bg-slate-500/15 text-slate-400 border-slate-500/30',
label: status,
}
return (
<span className={`inline-flex items-center px-2.5 py-0.5 rounded-full text-xs font-medium border ${config.badge} ${className}`}>
{config.label}
</span>
)
}
interface TypeBadgeProps {
type: string
className?: string
}
export function TypeBadge({ type, className = '' }: TypeBadgeProps) {
// Ein fehlender Typ darf kein Absturz sein. Am 29.08.2026 hat genau diese
// Annahme (an anderer Stelle) die ganze Oberflaeche geleert: Ein frisch
// angelegter Job kommt ueber den Ereignisstrom ohne `type` an.
const config = DISC_TYPE_STYLES[type as keyof typeof DISC_TYPE_STYLES] || {
badge: 'bg-slate-500/15 text-slate-400 border-slate-500/30',
label: type ? type.toUpperCase() : 'DISC',
}
return (
<span className={`inline-flex items-center gap-1.5 px-2.5 py-1 rounded-md text-xs font-medium border ${config.badge} ${className}`}>
<Disc size={13} />
{config.label}
</span>
)
}
+43
View File
@@ -0,0 +1,43 @@
import { ButtonHTMLAttributes, ReactNode } from 'react'
interface ButtonProps extends ButtonHTMLAttributes<HTMLButtonElement> {
variant?: 'primary' | 'secondary' | 'ghost' | 'danger' | 'amber'
size?: 'sm' | 'md' | 'lg'
children: ReactNode
className?: string
}
export function Button({
variant = 'primary',
size = 'md',
children,
className = '',
disabled,
...props
}: ButtonProps) {
const base = 'inline-flex items-center justify-center font-medium rounded-xl transition-all duration-200 focus:outline-none focus:ring-2 focus:ring-offset-2 disabled:opacity-50 disabled:cursor-not-allowed active:scale-[0.98]'
const variants = {
primary: 'bg-indigo-600 hover:bg-indigo-500 text-white shadow-lg shadow-indigo-500/25 dark:shadow-indigo-900/40 focus:ring-indigo-500',
amber: 'bg-gradient-to-r from-amber-500 to-amber-600 hover:from-amber-400 hover:to-amber-500 text-slate-950 font-semibold shadow-lg shadow-amber-500/20 focus:ring-amber-500',
secondary: 'bg-slate-100 dark:bg-slate-800/80 hover:bg-slate-200 dark:hover:bg-slate-700/80 text-slate-700 dark:text-slate-200 border border-slate-200 dark:border-slate-700/80 focus:ring-slate-400',
ghost: 'bg-transparent hover:bg-slate-100 dark:hover:bg-slate-800/60 text-slate-600 dark:text-slate-300 focus:ring-slate-400',
danger: 'bg-rose-600/90 hover:bg-rose-500 text-white shadow-lg shadow-rose-500/20 focus:ring-rose-500',
}
const sizes = {
sm: 'px-2.5 py-1.5 text-xs gap-1.5',
md: 'px-4 py-2 text-sm gap-2',
lg: 'px-5 py-2.5 text-base gap-2.5',
}
return (
<button
className={`${base} ${variants[variant]} ${sizes[size]} ${className}`}
disabled={disabled}
{...props}
>
{children}
</button>
)
}
+51
View File
@@ -0,0 +1,51 @@
import { ReactNode } from 'react'
interface CardProps {
children: ReactNode
className?: string
glow?: boolean
onClick?: () => void
}
export function Card({ children, className = '', glow = false, onClick }: CardProps) {
return (
<div
onClick={onClick}
className={`rounded-2xl transition-all duration-300 relative overflow-hidden ${
glow
? 'glass-panel-amber'
: 'bg-white/90 dark:bg-slate-900/80 backdrop-blur-xl border border-slate-200/80 dark:border-slate-800/80 shadow-xl shadow-black/10'
} text-slate-900 dark:text-slate-100 ${
onClick ? 'cursor-pointer hover:border-slate-300 dark:hover:border-slate-700 hover:shadow-2xl hover:-translate-y-0.5' : ''
} ${className}`}
>
{/* Top subtle highlight line for 3D glass depth */}
<div className="absolute top-0 inset-x-0 h-px bg-gradient-to-r from-transparent via-white/20 dark:via-white/10 to-transparent pointer-events-none" />
{children}
</div>
)
}
export function CardHeader({ children, className = '' }: { children: ReactNode; className?: string }) {
return (
<div className={`px-6 py-4 border-b border-slate-200/80 dark:border-slate-800/80 flex items-center justify-between ${className}`}>
{children}
</div>
)
}
export function CardTitle({ children, className = '' }: { children: ReactNode; className?: string }) {
return (
<h2 className={`text-lg font-bold tracking-tight text-slate-900 dark:text-slate-100 ${className}`}>
{children}
</h2>
)
}
export function CardContent({ children, className = '' }: { children: ReactNode; className?: string }) {
return (
<div className={`p-6 ${className}`}>
{children}
</div>
)
}
+85
View File
@@ -0,0 +1,85 @@
import { InputHTMLAttributes, SelectHTMLAttributes, ReactNode } from 'react'
interface InputProps extends InputHTMLAttributes<HTMLInputElement> {
label?: string
error?: string
className?: string
}
export function Input({ label, error, className = '', ...props }: InputProps) {
return (
<div className="space-y-1.5 w-full">
{label && (
<label className="block text-xs font-medium text-slate-700 dark:text-slate-300">
{label}
</label>
)}
<input
className={`w-full px-3.5 py-2 rounded-xl text-sm border bg-white dark:bg-slate-900/90 text-slate-900 dark:text-slate-100 border-slate-200 dark:border-slate-700/80 focus:outline-none focus:ring-2 focus:ring-amber-500/50 focus:border-amber-500 transition-colors duration-200 placeholder:text-slate-400 dark:placeholder:text-slate-600 ${
error ? 'border-rose-500 ring-rose-500/20' : ''
} ${className}`}
{...props}
/>
{error && <p className="text-xs text-rose-500">{error}</p>}
</div>
)
}
interface SelectProps extends SelectHTMLAttributes<HTMLSelectElement> {
label?: string
children: ReactNode
className?: string
}
export function Select({ label, children, className = '', ...props }: SelectProps) {
return (
<div className="space-y-1.5 w-full">
{label && (
<label className="block text-xs font-medium text-slate-700 dark:text-slate-300">
{label}
</label>
)}
<select
className={`w-full px-3.5 py-2 rounded-xl text-sm border bg-white dark:bg-slate-900/90 text-slate-900 dark:text-slate-100 border-slate-200 dark:border-slate-700/80 focus:outline-none focus:ring-2 focus:ring-amber-500/50 focus:border-amber-500 transition-colors duration-200 ${className}`}
{...props}
>
{children}
</select>
</div>
)
}
interface ToggleProps {
checked: boolean
onChange: (checked: boolean) => void
label?: string
description?: string
disabled?: boolean
}
export function Toggle({ checked, onChange, label, description, disabled }: ToggleProps) {
return (
<div className="flex items-center justify-between py-2">
{(label || description) && (
<div className="space-y-0.5">
{label && <span className="text-sm font-medium text-slate-900 dark:text-slate-100">{label}</span>}
{description && <p className="text-xs text-slate-500 dark:text-slate-400">{description}</p>}
</div>
)}
<button
type="button"
disabled={disabled}
onClick={() => onChange(!checked)}
className={`relative inline-flex h-6 w-11 flex-shrink-0 cursor-pointer rounded-full border-2 border-transparent transition-colors duration-200 ease-in-out focus:outline-none focus:ring-2 focus:ring-amber-500 focus:ring-offset-2 ${
checked ? 'bg-amber-500' : 'bg-slate-200 dark:bg-slate-700'
} ${disabled ? 'opacity-50 cursor-not-allowed' : ''}`}
>
<span
className={`pointer-events-none inline-block h-5 w-5 transform rounded-full bg-white shadow ring-0 transition duration-200 ease-in-out ${
checked ? 'translate-x-5' : 'translate-x-0'
}`}
/>
</button>
</div>
)
}
+76
View File
@@ -0,0 +1,76 @@
import { ReactNode, useEffect } from 'react'
import { createPortal } from 'react-dom'
import { X } from 'lucide-react'
interface ModalProps {
isOpen: boolean
onClose: () => void
title?: string
children: ReactNode
maxWidth?: 'sm' | 'md' | 'lg' | 'xl' | '2xl' | '4xl'
}
export function Modal({ isOpen, onClose, title, children, maxWidth = 'lg' }: ModalProps) {
useEffect(() => {
const handleKeyDown = (e: KeyboardEvent) => {
if (e.key === 'Escape') onClose()
}
if (isOpen) {
document.body.style.overflow = 'hidden'
window.addEventListener('keydown', handleKeyDown)
}
return () => {
document.body.style.overflow = 'unset'
window.removeEventListener('keydown', handleKeyDown)
}
}, [isOpen, onClose])
if (!isOpen) return null
const maxWidening = {
sm: 'max-w-sm',
md: 'max-w-md',
lg: 'max-w-lg',
xl: 'max-w-xl',
'2xl': 'max-w-2xl',
'4xl': 'max-w-4xl',
}
// WICHTIG (Befund 25.07.2026): Der Dialog wird per Portal direkt an
// document.body gehängt statt dort zu bleiben, wo er im Baum steht.
// Grund: `.glass-panel` in index.css setzt `backdrop-filter: blur(16px)`,
// und ein Element mit backdrop-filter wird zum Bezugsrahmen für
// `position: fixed` seiner Nachfahren. Ein Modal INNERHALB einer Card war
// damit nicht mehr am Fenster ausgerichtet, sondern an der Card — es klebte
// im Panel und wurde am Rand abgeschnitten (gemeldet für „Rippen starten"
// im Laufwerke-Tab). Das Portal löst das für ALLE Dialoge auf einmal.
return createPortal(
<div className="fixed inset-0 z-50 flex items-center justify-center p-4 overflow-y-auto">
{/* Glass Backdrop */}
<div
className="fixed inset-0 bg-slate-950/70 backdrop-blur-md transition-opacity duration-300 animate-in fade-in"
onClick={onClose}
/>
{/* Modal Dialog */}
<div className={`relative w-full ${maxWidening[maxWidth]} bg-white dark:bg-slate-900 rounded-2xl border border-slate-200 dark:border-slate-800 shadow-2xl shadow-black/40 overflow-hidden z-10 animate-in zoom-in-95 duration-200`}>
{title && (
<div className="flex items-center justify-between px-6 py-4 border-b border-slate-200 dark:border-slate-800 bg-slate-50/50 dark:bg-slate-900/50">
<h3 className="text-lg font-semibold text-slate-900 dark:text-slate-100">{title}</h3>
<button
onClick={onClose}
className="p-1.5 rounded-lg text-slate-400 hover:text-slate-600 dark:hover:text-slate-200 hover:bg-slate-100 dark:hover:bg-slate-800 transition-colors"
>
<X size={18} />
</button>
</div>
)}
<div className="p-6">
{children}
</div>
</div>
</div>,
document.body,
)
}
@@ -0,0 +1,19 @@
import { ReactNode } from 'react'
interface PageHeaderProps {
title: string
subtitle?: string
action?: ReactNode
}
export function PageHeader({ title, subtitle, action }: PageHeaderProps) {
return (
<div className="flex flex-col sm:flex-row sm:items-center sm:justify-between gap-4 mb-8">
<div>
<h1 className="text-3xl font-bold tracking-tight text-slate-900 dark:text-slate-100">{title}</h1>
{subtitle && <p className="mt-1 text-sm text-slate-500 dark:text-slate-400">{subtitle}</p>}
</div>
{action && <div>{action}</div>}
</div>
)
}
@@ -0,0 +1,56 @@
interface RadialProgressProps {
progress: number
size?: number
strokeWidth?: number
label?: string
status?: string
}
export function RadialProgress({ progress, size = 80, strokeWidth = 7, label, status }: RadialProgressProps) {
const radius = (size - strokeWidth) / 2
const circumference = radius * 2 * Math.PI
const strokeDashoffset = circumference - (progress / 100) * circumference
const isComplete = progress === 100
return (
<div className="relative inline-flex items-center justify-center">
<svg width={size} height={size} className="transform -rotate-90">
{/* Background track */}
<circle
cx={size / 2}
cy={size / 2}
r={radius}
stroke="currentColor"
strokeWidth={strokeWidth}
className="text-slate-800 dark:text-slate-800/80 fill-none"
/>
{/* Progress track */}
<circle
cx={size / 2}
cy={size / 2}
r={radius}
stroke="url(#progressGradient)"
strokeWidth={strokeWidth}
strokeDasharray={circumference}
strokeDashoffset={strokeDashoffset}
strokeLinecap="round"
className="fill-none transition-all duration-500 ease-out"
/>
<defs>
<linearGradient id="progressGradient" x1="0%" y1="0%" x2="100%" y2="100%">
<stop offset="0%" stopColor={isComplete ? '#10b981' : '#f59e0b'} />
<stop offset="50%" stopColor={isComplete ? '#059669' : '#6366f1'} />
<stop offset="100%" stopColor={isComplete ? '#34d399' : '#a855f7'} />
</linearGradient>
</defs>
</svg>
<div className="absolute flex flex-col items-center justify-center text-center">
<span className="text-sm font-bold font-mono text-slate-900 dark:text-slate-100 tracking-tighter">
{progress}%
</span>
{label && <span className="text-[9px] uppercase tracking-wider text-slate-400">{label}</span>}
</div>
</div>
)
}
+5 -23
View File
@@ -1,43 +1,25 @@
import { createContext, useContext, useEffect, useState, ReactNode } from 'react'
type Theme = 'light' | 'dark'
import { createContext, useContext, useEffect, ReactNode } from 'react'
interface ThemeContextType {
theme: Theme
theme: 'dark'
toggleTheme: () => void
}
const ThemeContext = createContext<ThemeContextType | undefined>(undefined)
export function ThemeProvider({ children }: { children: ReactNode }) {
const [theme, setTheme] = useState<Theme>('light')
useEffect(() => {
const savedTheme = localStorage.getItem('theme')
const prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches
if (savedTheme === 'dark' || (!savedTheme && prefersDark)) {
setTheme('dark')
document.documentElement.classList.add('dark')
} else {
setTheme('light')
document.documentElement.classList.remove('dark')
}
localStorage.setItem('theme', 'dark')
}, [])
const toggleTheme = () => {
const newTheme = theme === 'dark' ? 'light' : 'dark'
setTheme(newTheme)
localStorage.setItem('theme', newTheme)
if (newTheme === 'dark') {
// 100% Dark Mode locked per Commander directive
document.documentElement.classList.add('dark')
} else {
document.documentElement.classList.remove('dark')
}
}
return (
<ThemeContext.Provider value={{ theme, toggleTheme }}>
<ThemeContext.Provider value={{ theme: 'dark', toggleTheme }}>
{children}
</ThemeContext.Provider>
)
+63 -49
View File
@@ -2,57 +2,17 @@
@tailwind components;
@tailwind utilities;
:root {
--bg-color: #f8fafc;
--bg-secondary: #f1f5f9;
--text-primary: #0f172a;
--text-secondary: #64748b;
--accent-color: #6366f1;
--accent-hover: #4f46e5;
--border-color: #e2e8f0;
--card-bg: #ffffff;
--input-bg: #ffffff;
--input-border: #e2e8f0;
--success-color: #22c55e;
--error-color: #ef4444;
@layer base {
body {
@apply m-0 bg-slate-950 text-slate-100 font-sans antialiased selection:bg-amber-500/30 selection:text-amber-300;
background-image:
radial-gradient(ellipse at 10% 0%, rgba(99, 102, 241, 0.08) 0%, transparent 50%),
radial-gradient(ellipse at 90% 100%, rgba(245, 158, 11, 0.06) 0%, transparent 50%);
background-attachment: fixed;
}
}
[data-theme="dark"] {
--bg-color: #0f172a;
--bg-secondary: #1e293b;
--text-primary: #f1f5f9;
--text-secondary: #94a3b8;
--accent-color: #818cf8;
--accent-hover: #6366f1;
--border-color: #334155;
--card-bg: #1e293b;
--input-bg: #0f172a;
--input-border: #334155;
}
* {
transition: background-color 0.3s ease, color 0.3s ease, border-color 0.3s ease;
}
body {
margin: 0;
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', 'Roboto', 'Oxygen',
'Ubuntu', 'Cantarell', 'Fira Sans', 'Droid Sans', 'Helvetica Neue',
sans-serif;
-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;
background-color: var(--bg-color);
color: var(--text-primary);
}
code {
font-family: source-code-pro, Menlo, Monaco, Consolas, 'Courier New',
monospace;
background-color: var(--bg-secondary);
color: var(--text-primary);
}
/* Toast-Einflug (ToastContext): von rechts reinploppen */
/* Toast Einflug */
@keyframes toast-rein {
from {
opacity: 0;
@@ -67,3 +27,57 @@ code {
.toast-rein {
animation: toast-rein 0.25s ease-out;
}
/* Subtile Disc-Rotation für Cinematic Spotlight */
@keyframes disc-spin {
from {
transform: rotate(0deg);
}
to {
transform: rotate(360deg);
}
}
.animate-disc-spin {
animation: disc-spin 12s linear infinite;
}
@keyframes pulse-slow {
0%, 100% { opacity: 0.4; }
50% { opacity: 0.9; }
}
.animate-pulse-slow {
animation: pulse-slow 3s ease-in-out infinite;
}
/* Custom Glass & Shimmer Effects */
.glass-panel {
background: rgba(15, 23, 42, 0.75);
backdrop-filter: blur(16px);
-webkit-backdrop-filter: blur(16px);
border: 1px solid rgba(255, 255, 255, 0.08);
}
.glass-panel-amber {
background: linear-gradient(135deg, rgba(245, 158, 11, 0.12) 0%, rgba(15, 23, 42, 0.85) 100%);
backdrop-filter: blur(16px);
border: 1px solid rgba(245, 158, 11, 0.25);
box-shadow: 0 0 35px -5px rgba(245, 158, 11, 0.15);
}
/* Metallic Disc Texture Gradient */
.disc-texture {
background: conic-gradient(
from 0deg,
#1e293b 0deg,
#475569 45deg,
#1e293b 90deg,
#64748b 135deg,
#1e293b 180deg,
#475569 225deg,
#1e293b 270deg,
#64748b 315deg,
#1e293b 360deg
);
}
+6 -1
View File
@@ -4,4 +4,9 @@ import axios from 'axios'
// den api-Container weiter. Vorher stand in vier Dateien http://localhost:8000
// hartkodiert: vom PC aus fragte der Browser damit den PC SELBST nach
// Laufwerken und Jobs — deshalb blieb das UI immer leer.
export const api = axios.create({ baseURL: '/api' })
// Zeitgrenze, damit ein hängender Aufruf nicht ewig offen bleibt und sich die
// Abfragen des 4-Sekunden-Takts stapeln (Befund 26.07.2026: axios wartet ohne
// `timeout` unbegrenzt). 20 s sind reichlich für jeden Endpunkt — die
// langsamsten sind der Update-Check und der Titel-Scan-Start, alles andere
// antwortet in Millisekunden.
export const api = axios.create({ baseURL: '/api', timeout: 20000 })
+96
View File
@@ -0,0 +1,96 @@
// Centralized Design System & Style Tokens for Rippy (Cinematic Cinema OS)
export const STATUS_STYLES = {
pending: {
badge: 'bg-amber-500/15 text-amber-600 dark:text-amber-400 border-amber-500/30',
label: 'Wartend',
},
processing: {
badge: 'bg-sky-500/15 text-sky-600 dark:text-sky-400 border-sky-500/30 animate-pulse',
label: 'Rippen',
},
transcoding: {
badge: 'bg-purple-500/15 text-purple-600 dark:text-purple-400 border-purple-500/30',
label: 'Komprimieren',
},
canceling: {
badge: 'bg-orange-500/15 text-orange-600 dark:text-orange-400 border-orange-500/30',
label: 'Wird abgebrochen…',
},
completed: {
badge: 'bg-emerald-500/15 text-emerald-600 dark:text-emerald-400 border-emerald-500/30',
label: 'Fertig',
},
failed: {
badge: 'bg-rose-500/15 text-rose-600 dark:text-rose-400 border-rose-500/30',
label: 'Fehler',
},
} as const
export const DISC_TYPE_STYLES = {
cd: {
badge: 'bg-indigo-500/15 text-indigo-600 dark:text-indigo-400 border-indigo-500/30',
aura: 'from-indigo-500/20 via-indigo-900/10 to-transparent',
glow: 'shadow-[0_0_20px_-5px_rgba(99,102,241,0.2)]',
label: 'CD',
},
dvd: {
badge: 'bg-purple-500/15 text-purple-600 dark:text-purple-400 border-purple-500/30',
aura: 'from-purple-500/20 via-purple-900/10 to-transparent',
glow: 'shadow-[0_0_20px_-5px_rgba(168,85,247,0.2)]',
label: 'DVD',
},
bluray: {
badge: 'bg-sky-500/15 text-sky-600 dark:text-sky-400 border-sky-500/30',
aura: 'from-sky-500/20 via-sky-900/10 to-transparent',
glow: 'shadow-[0_0_20px_-5px_rgba(14,165,233,0.2)]',
label: 'BLU-RAY',
},
uhd: {
badge: 'bg-amber-500/20 text-amber-700 dark:text-amber-300 border-amber-500/40 font-semibold shadow-sm shadow-amber-500/20',
aura: 'from-amber-500/25 via-amber-900/15 to-transparent',
glow: 'shadow-[0_0_25px_-5px_rgba(245,158,11,0.25)]',
label: '4K UHD',
},
} as const
export const LOG_LEVEL_STYLES = {
INFO: {
color: 'text-sky-600 dark:text-sky-400',
bg: 'bg-sky-500/10',
border: 'border-sky-500/20',
},
WARNING: {
color: 'text-amber-600 dark:text-amber-400',
bg: 'bg-amber-500/10',
border: 'border-amber-500/20',
},
ERROR: {
color: 'text-rose-600 dark:text-rose-400',
bg: 'bg-rose-500/10',
border: 'border-rose-500/20',
},
DEBUG: {
color: 'text-slate-500 dark:text-slate-400',
bg: 'bg-slate-500/10',
border: 'border-slate-500/20',
},
} as const
// Encoder-Backends, wie worker/caps.py sie meldet. Hardware wird seit
// 25.07.2026 nach FAMILIE unterschieden (nvenc/qsv/vce/vaapi) — vorher landete
// eine AMD-Karte unter dem Intel-Namen „vaapi", und AV1 in Hardware war gar
// nicht sichtbar, obwohl es die beste Kombination aus Tempo und Größe ist.
export const ENCODER_BADGES: Record<string, { label: string; highlight: boolean }> = {
'cpu-x264': { label: 'H.264 (CPU)', highlight: false },
'cpu-x265': { label: 'H.265 (CPU)', highlight: false },
'cpu-av1': { label: 'AV1 (CPU)', highlight: false },
'nvenc': { label: 'NVENC ⚡ (NVIDIA)', highlight: true },
'nvenc-av1': { label: 'AV1 · NVENC ⚡', highlight: true },
'qsv': { label: 'QuickSync ⚡ (Intel)', highlight: true },
'qsv-av1': { label: 'AV1 · QuickSync ⚡', highlight: true },
'vce': { label: 'VCE ⚡ (AMD)', highlight: true },
'vce-av1': { label: 'AV1 · VCE ⚡', highlight: true },
'vaapi': { label: 'VAAPI ⚡', highlight: true },
'vaapi-av1': { label: 'AV1 · VAAPI ⚡', highlight: true },
}
+219
View File
@@ -0,0 +1,219 @@
// Encoder-Fähigkeiten eines Workers in Klartext übersetzen.
//
// Befund 25.07.2026: Die Rippy-VM lief auf dem generischen QEMU-CPU-Modell
// („QEMU Virtual CPU version 2.5+") und hatte deshalb kein AVX2, nur sse4_2.
// x265 lebt von diesen Vektorbefehlen — ein 4K-Encode brauchte dort gemessene
// 28-55 Stunden, und nirgends im UI war das zu sehen. Der Worker meldet die
// Angaben seit dieser Runde selbst (worker/caps.py), hier werden sie gedeutet.
// Stufen, mit denen Software-Encoding brauchbar schnell ist.
export const SIMD_SCHNELL = ['avx512f', 'avx2']
/**
* Warnt, wenn die CPU dieses Workers zu schwach für Software-Encoding ist.
* Gibt null zurück, wenn alles in Ordnung ist ODER die Stufe unbekannt ist
* lieber nichts sagen als etwas Falsches behaupten.
*/
export function simdWarnung(simd?: string): string | null {
if (!simd || simd === 'unbekannt') return null
if (SIMD_SCHNELL.includes(simd)) return null
return `Diese CPU kann nur ${simd} (kein AVX2) — Software-Encoding ist hier `
+ 'sehr langsam. Bei einer virtuellen Maschine hilft es meist, den '
+ 'CPU-Typ auf "host" zu stellen; sonst besser einen Worker mit '
+ 'Hardware-Encoder wählen.'
}
// Reservierter Wert im Preset-Feld: „diesen Disc-Typ NICHT komprimieren".
// Muss mit ripping.PRESET_KEINE im Worker übereinstimmen — es gibt kein
// geteiltes Paket zwischen UI und Worker, deshalb steht der Wert hier nochmal.
export const PRESET_KEINE = 'keine'
interface WorkerFuerBewertung {
encoders?: string[]
info?: { cpu_simd?: string }
}
// --- Sprachnamen für die Auswahl vor dem Rip ---------------------------------
//
// MakeMKV liefert die Namen auf ENGLISCH („German", „Japanese") und für Spuren
// ohne Sprach-Kennzeichnung „Undetermined". Beides an der Akira-Blu-ray gemessen
// (26.07.2026): Ton deu 4×, jpn 2×, und 4× — die „und"-Spuren sind typischerweise
// Audiokommentare, die kein Sprachfeld tragen.
//
// „Undetermined" versteht ein Nicht-Entwickler nicht, und der Commander liest
// alles auf Deutsch (AGENTS Grundregel 4). Unbekannte Codes behalten MakeMKVs
// Namen — geraten wird nichts.
const SPRACHNAMEN: Record<string, string> = {
und: 'Ohne Sprachangabe',
deu: 'Deutsch', ger: 'Deutsch',
eng: 'Englisch',
jpn: 'Japanisch',
fra: 'Französisch', fre: 'Französisch',
spa: 'Spanisch',
ita: 'Italienisch',
nld: 'Niederländisch', dut: 'Niederländisch',
rus: 'Russisch',
kor: 'Koreanisch',
zho: 'Chinesisch', chi: 'Chinesisch',
pol: 'Polnisch',
tur: 'Türkisch',
ces: 'Tschechisch', cze: 'Tschechisch',
por: 'Portugiesisch',
swe: 'Schwedisch',
dan: 'Dänisch',
nor: 'Norwegisch',
fin: 'Finnisch',
hun: 'Ungarisch',
ara: 'Arabisch',
mul: 'Mehrsprachig',
}
/** Sprachname auf Deutsch — sonst der Name, den MakeMKV geliefert hat. */
export function sprachName(lang: string, makemkvName?: string): string {
return SPRACHNAMEN[(lang || '').toLowerCase()] || makemkvName || lang || '?'
}
// --- Erreicht ein EXTERNER Worker die Pfade? ---------------------------------
//
// Befund 26.07.2026, live am Job 95afdc89: Das Routing an den Windows-PC des
// Commanders funktionierte einwandfrei — der Worker nahm die Aufgabe an und
// lehnte sie 182 ms später ab, weil `/app/media/...` Pfade INNERHALB des
// Rippy-Containers sind. Ohne RIPPY_PATH_MAP sieht ein externer Worker sie nie.
// Auffallen durfte das nicht erst nach einer Stunde Rip, sondern hier.
interface WorkerFuerPfadPruefung {
name: string
node?: string | null
info?: { extern?: string, pfad_map?: string }
}
/**
* Deckt `RIPPY_PATH_MAP` diesen Container-Pfad ab? Gleiche Regel wie
* `pfad_lokal()` im Worker (docker/worker/tasks.py): Paare `quelle=ziel`,
* getrennt durch `;`, Treffer per Präfix.
*/
export function pfadAbgedeckt(pfad: string, mapping: string): boolean {
if (!pfad || !mapping) return false
return mapping.split(';').some(paar => {
const quelle = paar.split('=', 1)[0]
return !!quelle && pfad.startsWith(quelle)
})
}
/**
* Namen der Speicherziele, die dieser Worker über sein Mapping erreicht.
* Aus /app/media/rippy=\\NAS\rippy" wird ["rippy"].
*/
export function freigabenAusMapping(mapping?: string): string[] {
return (mapping || '').split(';')
.map(p => p.split('=', 1)[0])
.filter(Boolean)
.map(p => p.replace(/^\/app\/media\//, ''))
.filter(n => n && !n.includes('/'))
}
/**
* Warnt, BEVOR gerippt wird, wenn der gewählte Encoder die Pfade nicht
* erreichen kann. null = alles in Ordnung (oder der Worker läuft im Container,
* dann gibt es nichts zu übersetzen).
*
* `arbeitsPfad` leer heißt: Container-Standard /app/temp/raw ein Docker-Volume,
* an das ein externer Worker grundsätzlich nicht herankommt.
*/
export function externWarnung(
worker: WorkerFuerPfadPruefung | undefined,
zielPfad: string,
arbeitsPfad: string,
): string | null {
if (!worker || worker.info?.extern !== 'ja') return null
const mapping = (worker.info?.pfad_map || '').trim()
if (!mapping) {
return `${worker.name}" läuft auf einer anderen Maschine und hat keine `
+ 'Pfad-Übersetzung (RIPPY_PATH_MAP). Er kann die Rohdaten deshalb nicht '
+ 'finden und würde sofort abbrechen. Abhilfe: den Windows-Installer erneut '
+ 'ausführen — er holt den Wert jetzt selbst von Rippy. Bis dahin besser '
+ '„Automatisch" wählen.'
}
if (!arbeitsPfad) {
return `${worker.name}" arbeitet auf einer anderen Maschine. Das `
+ 'Arbeitsverzeichnis steht auf der Container-Platte (/app/temp) — die ist '
+ 'von außen nicht erreichbar. Oben eine Netzwerk-Freigabe als '
+ 'Arbeitsverzeichnis wählen.'
}
const zielFehlt = !pfadAbgedeckt(zielPfad, mapping)
const arbeitFehlt = !pfadAbgedeckt(arbeitsPfad, mapping)
if (!zielFehlt && !arbeitFehlt) return null
/*
* Die Meldung muss sagen, WAS ZU TUN IST nicht nur, was klemmt.
*
* Commander-Rückmeldung 26.07.2026: Das ist ja quatsch. Mein PC hat das Ziel
* als Worker direkt auf dem PC eingebunden." Er hatte die Freigabe wirklich
* als Netzlaufwerk gemountet nur war das ARBEITSVERZEICHNIS darauf gelegt
* und die ABLAGE nicht. Das Ziel lag weiter auf der VM-Platte
* (/app/media/movies), und dorthin kommt sein PC nicht.
*
* Die alte Meldung war sachlich richtig und trotzdem unbrauchbar: Sie nannte
* den Container-Pfad und die Mapping-Zeichenkette, also genau die zwei Dinge,
* die ein Nicht-Entwickler nicht deuten kann. Jetzt steht der Handgriff drin,
* inklusive des Namens der Freigabe, die dieser Worker wirklich erreicht.
*/
const freigabe = freigabenAusMapping(mapping)[0] || ''
const teile: string[] = []
if (zielFehlt) {
teile.push(`Die Ablage (${zielPfad}) liegt nicht auf der Freigabe.`)
if (freigabe) {
teile.push(`Abhilfe: Einstellungen → Ripping → „Ablage" auf `
+ `${freigabe}" stellen — das ist die Freigabe, die „${worker.name}" `
+ 'wirklich erreicht.')
}
}
if (arbeitFehlt) {
teile.push(`Das Arbeitsverzeichnis (${arbeitsPfad || 'Container-Platte'}) `
+ 'liegt nicht auf der Freigabe — oben umstellen.')
}
teile.push('Ohne das scheitert die Kompression (die Rohdaten bleiben erhalten).')
return teile.join(' ')
}
/**
* Dasselbe Risiko bei Automatisch": dort nimmt die geteilte Queue den ersten
* freien Worker auch einen externen, der die Pfade nicht erreicht. Nennt die
* betroffenen Namen, damit man gezielt einen anderen wählt.
*/
export function automatikWarnung(
workers: WorkerFuerPfadPruefung[] | undefined,
zielPfad: string,
arbeitsPfad: string,
): string | null {
const betroffen = (workers || [])
.filter(w => externWarnung(w, zielPfad, arbeitsPfad) !== null)
.map(w => w.name)
if (betroffen.length === 0) return null
return `Bei „Automatisch" nimmt die Aufgabe der erste freie Worker — das kann `
+ `${betroffen.join(', ')} sein, und dort scheitert sie an den Pfaden. `
+ 'Wähle oben gezielt eine Maschine, die die Freigabe erreicht — oder rüste '
+ 'die Pfad-Übersetzung nach (Windows-Installer erneut ausführen).'
}
/**
* Kann von den gemeldeten Workern KEINER 4K in Software brauchbar schnell
* encodieren? Wahr nur, wenn das auch belegt ist: mindestens ein Worker hat
* eine bekannte SIMD-Stufe, und keiner erreicht AVX2 und keiner hat einen
* Hardware-Encoder, der die Frage sowieso erledigt.
*
* Bei unbekannter Stufe (z. B. Windows-Worker, dort gibt es kein
* /proc/cpuinfo) wird NICHT gewarnt. Lieber schweigen als falsch warnen.
*/
export function schwacheEncoderCpu(workers?: WorkerFuerBewertung[]): boolean {
const liste = workers || []
if (liste.length === 0) return false
const hardware = liste.some(w => (w.encoders || []).some(e => !e.startsWith('cpu')))
if (hardware) return false
const bekannte = liste
.map(w => w.info?.cpu_simd)
.filter((s): s is string => !!s && s !== 'unbekannt')
if (bekannte.length === 0) return false
return !bekannte.some(s => SIMD_SCHNELL.includes(s))
}

Some files were not shown because too many files have changed in this diff Show More