From 9d95c95d79a4380ab4d815c32a6d97268f395c59 Mon Sep 17 00:00:00 2001 From: Hitonabi Date: Fri, 28 Aug 2026 10:04:29 +0200 Subject: [PATCH] feat(drives): Windows-Treiber an echter Disc BEWIESEN MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- src/rippy/drives/test_cdrom.py | 16 ++++++++++++++++ src/rippy/drives/windows.py | 33 ++++++++++++++++++++++++++++----- 2 files changed, 44 insertions(+), 5 deletions(-) diff --git a/src/rippy/drives/test_cdrom.py b/src/rippy/drives/test_cdrom.py index b277fc7..53f18a1 100644 --- a/src/rippy/drives/test_cdrom.py +++ b/src/rippy/drives/test_cdrom.py @@ -54,3 +54,19 @@ def test_uhd_ab_schwelle(): def test_unbekannter_status(): assert classify(999, 5 * 1024**3) == "unknown" assert classify(0, 0) == "unknown" + + +# ── An echter Hardware gemessen ───────────────────────────────────────── +def test_gemessene_bd50_wird_als_bluray_eingeordnet(): + """Kein ausgedachter Wert: Am 28.08.2026 an einer echten BD-50 im + LG BU40N gemessen (IOCTL_DISK_GET_LENGTH_INFO unter Windows). + + Der Fall ist der interessanteste an der ganzen Zuordnung, weil er dicht + an der UHD-Schwelle liegt: 44,84 GiB gegen 55 GiB. Wer die Schwelle + senkt, macht aus jeder BD-50 eine „UHD" — und Rippy waehlte dann das + falsche Kompressions-Preset. + """ + gemessen = 48_149_364_736 # Bytes, echte BD-50 + assert gemessen / 1024**3 < 45 # 44,84 GiB + assert classify(CDS_DATA_1, gemessen) == "bluray" + assert gemessen < UHD_MIN_BYTES diff --git a/src/rippy/drives/windows.py b/src/rippy/drives/windows.py index d019079..eb8b8ce 100644 --- a/src/rippy/drives/windows.py +++ b/src/rippy/drives/windows.py @@ -61,11 +61,34 @@ nichts tut, wäre genau die Sorte Placebo, die in Etappe 19 aufgeräumt wurde. Die Konstante steht in `win_ioctl.py` — wer sie je benutzt, muss den Fehlschlag sichtbar machen. -**NOCH NICHT gemessen:** das Verhalten MIT eingelegter Disc — also die -Typ-Erkennung (DVD/BD/UHD über Größe) und der Auswurf einer wirklich -eingelegten Disc. Bei leerem Laufwerk meldet `CHECK_VERIFY2` vorher wie -nachher „kein Medium"; der Auswurf gilt damit zu Recht als geglückt, beweist -aber nicht, dass sich die Schublade bewegt hat. +**MIT EINGELEGTER DISC gemessen (28.08.2026, dasselbe Laufwerk, BD-50):** + + drive_status() -> 4 (CDS_DISC_OK), sofort + IOCTL_CDROM_DISK_TYPE -> Bytes 02 00 00 00 + = DATA_TRACK (0x2) + 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 wurde nicht am +Rückgabewert des Steuercodes festgemacht, sondern am ZUSTAND davor und +danach: Die Disc war drin (4) und ist danach draußen (1). Genau das, was in +v1 monatelang gefehlt hat — dort quittierte das ioctl Erfolg, die Schublade +blieb zu, und im Log stand „Disc ausgeworfen". + +Die 44,84 GiB prüfen nebenbei die Schwelle mit: Eine BD-50 liegt knapp unter +den 55 GiB, ab denen `cdrom.classify()` auf `uhd` geht — und wird korrekt als +`bluray` eingeordnet. + +**Damit gilt die Hardware-Schicht dieses Treibers als BEWIESEN**, nicht mehr +nur als gebaut. Offen bleibt allein die Ereignis-Erkennung +(`WM_DEVICECHANGE`) — die wird erst gebaut. """ import sys