rippy

Author	SHA1	Message	Date
HitonabiandClaude Fable 5	6f230cbd7f	fix(tests): Linux-only-Waechter pruefte die Welt vor `d3e86d2` 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 19:04:54 +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	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 Details 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 Details 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 Details 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 Details 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 Details 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 Details 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	e67138e9ca	feat(ui): Laufende Disc-Erkennung ist jetzt sichtbar Ampel / ampel (push) Successful in 1m26s Details 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	7b0c41ddfe	fix(ui): Datum 1.1.1970, Disc nicht erkannt, kein Abbrechen — eine Ursache je Fall Ampel / ampel (push) Successful in 1m16s Details 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 Details 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	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	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	678fe276f9	feat(windows): Arbeitsordner im Setup, Beta-Key auf Knopfdruck Ampel / ampel (push) Successful in 1m18s Details 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	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	be3fac53af	fix(prescan): makemkvcon ueber den Katalog suchen, nicht ueber shutil.which Ampel / ampel (push) Successful in 55s Details 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 Details 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	8e65411189	fix(windows): die Datenbank lag AUSSERHALB der Installation — daher fehlte Ampel / ampel (push) Failing after 54s Details 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	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	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	f4a8d77598	feat(windows): Rippy arbeitet eigenstaendig — Rippen, Werkzeuge, Fähigkeiten Ampel / ampel (push) Failing after 48s Details 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 Details 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 Details 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	3d7f3b1680	feat(drives): V2-4 (Teil 2) — main.py laedt unter Windows, Treiber gemessen Ampel / ampel (push) Failing after 46s Details 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	95705c8d88	feat(ui): V2-3 (Teil 2) — das UI haengt am Ereignis-Strom, Taktgeber raus Ampel / ampel (push) Successful in 47s Details 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	1fbe2cfc55	fix(test): Snapshot-Tests brauchten eine Datenbank — die Ampel hat keine Ampel / ampel (push) Successful in 40s Details 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 Details 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	7558be4854	fix: CRLF in gui.py wiederherstellen (Zeilenenden-Falle in V2-1) Ampel / ampel (push) Successful in 39s Details 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 Details 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	b98dc5eef5	refactor(core): V2-0 — gemeinsames Paket rippy statt drei Zwillingsdateien Ampel / ampel (push) Successful in 41s Details 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
Hitonabi	a14449ef85	fix(worker-ui): fix syntax error in gui.py and ruff error in test_verwaltung.py Ampel / ampel (push) Successful in 39s Details	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 Details	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 Details	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 Details	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 Details	2026-07-27 17:06:38 +02:00
Hitonabi	9b30c0a490	chore: remove obsolete test_verwaltung.py Ampel / ampel (push) Failing after 40s Details	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 Details	2026-07-27 17:00:52 +02:00
Hitonabi	a32a1bb075	fix: bare except in main.py Ampel / ampel (push) Failing after 38s Details	2026-07-27 16:56:36 +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	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 Details - 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 Details	2026-07-26 20:55:57 +02:00
HitonabiandClaude Opus 5	96c400f2f2	fix(worker): erster Film in einer neuen Ablage war immer unerreichbar Ampel / ampel (push) Failing after 30s Details 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	bfb13f44a5	fix(ui+api): das "Neuladen" war HTTP 429 - und "Neu" komprimierte immer Ampel / ampel (push) Successful in 30s Details 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 Details 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

1 2 3 4