HitonabiandClaude Opus 5
1a529f4e75
Ampel / ampel (push) Successful in 1m13s
Commander: „der ‚Disk wird gelesen' panel braucht eeeeewig. Der Rip ist bereits bei 30% und er liest immernoch." Genau so war es — und die Erkennung kam auch nie zum Ende. ## Warum `_auto_prescan` hatte GENAU EINE Absicherung: nicht zweimal gleichzeitig (`_laeuft`). Ob auf dem Laufwerk gerade ein Rip laeuft, hat es nie gefragt. Waehrend eines Rips haelt `makemkvcon` das Laufwerk. Ein zweites `makemkvcon info` daneben wartet, bis es seine Zeitgrenze erreicht (gemessen: eine Laufwerks-Abfrage braucht dann 14 s statt 5, der `info`-Aufruf laeuft in seine 120 s). Solange steht die Marke `_laeuft` — und damit das Panel, das ich heute frueh genau dafuer gebaut habe. Es gibt keinen Grund, waehrend eines Rips zu scannen: Das Laufwerk ist belegt, und **welche Disc drin ist, wissen wir bereits** — der Job laeuft ja auf ihr. ## Zwei Stellen, weil es zwei Wege hinein gibt 1. `_auto_prescan` bricht ab, wenn auf dem Geraet ein Job laeuft. Das verhindert jeden Scan, der NACH dem Rip-Start angestossen wird. 2. Der Job-Start raeumt eine haengende Marke weg. Ein Scan, der KURZ VORHER begann, haelt sie sonst bis zu seinem Ende fest. Verloren geht dabei nichts: Unter `_laeuft` steht nur der Platzhalter, und der laufende Scan traegt sein Ergebnis spaeter selbst nach. 880 Tests gruen, ruff sauber. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>