Hitonabi
6a17af2118
Ampel / ampel (push) Successful in 28s
Loest die offene Frage aus dem Savepoint ("UHD gar nicht komprimieren?") und
nimmt dem Wizard die Falle, in die er bisher fuehrte.
## Kompression je Disc-Typ abwaehlbar
Bisher gab es nur den globalen Schalter transcodeEnabled: alles komprimieren
oder nichts. Wer 4K verlustfrei behalten und DVDs trotzdem schrumpfen wollte,
hatte keine Moeglichkeit - obwohl genau das die vernuenftige Einstellung fuer
diese Maschine ist (4K-HEVC = gemessene 28-55 h je Film ohne AVX2).
Jetzt kann das Preset eines Disc-Typs auf den Reservewert "keine" stehen, dann
bleibt die verlustfreie Datei aus dem Rip stehen. Neue reine Funktion
komprimieren_fuer(disc_type, einstellungen); der globale Schalter schlaegt
weiter alles. preset_fuer() ueberspringt den Reservewert bewusst und gibt ihn
NIE als Preset-Namen zurueck - sonst bekaeme HandBrake `--preset keine` und
wuerde scheitern. Wer ueber "Neu komprimieren" ausdruecklich doch komprimieren
will, bekommt so ein brauchbares Preset statt eines Fehlers.
Der Reservewert kollidiert mit keinem echten Namen: gegengeprueft gegen alle
90 Presets aus `HandBrakeCLI --preset-list` im Worker-Image. Bei der
Gelegenheit auch die fuenf im UI angebotenen Namen geprueft - alle echt.
## Der Wizard empfiehlt nach GEMESSENER Rechenleistung
Vorher stand H.265 als Standard drin. Auf einer CPU ohne AVX2 sind das ein bis
zwei Tage pro 4K-Film - genau der Lauf, der am 25.07.2026 abgebrochen werden
musste. Der Wizard hatte die Zahlen sogar schon vorliegen (/capabilities
meldet cpu_simd und cpu_kerne), nur benutzt hat er sie nicht.
Jetzt: schwache CPU -> 4K wird nicht komprimiert, Blu-ray/DVD gehen auf H.264
(schneller als H.265). Starke CPU oder Hardware-Encoder -> H.265 durchgehend.
Der Wizard schreibt dabei ALLE vier Preset-Felder, nicht nur das allgemeine -
vorher fiel 4K auf ein 1080p-Preset zurueck und die Aufloesung war weg.
Gewarnt wird nur, wenn es belegt ist: schwacheEncoderCpu() verlangt mindestens
einen Worker mit BEKANNTER SIMD-Stufe und keinen mit Hardware-Encoder. Ein
Windows-Worker meldet "unbekannt" (dort gibt es kein /proc/cpuinfo) - dann wird
geschwiegen statt falsch gewarnt. Auf Windows gegengeprueft: 16 Kerne und
CPU-Modell kommen korrekt durch, encoders ist ohne HandBrake leer.
## Weitere Wizard-Haerten
- Kasten "Was Rippy gerade sieht": Laufwerk, Worker (mit Kernen/SIMD), freier
Platz. Jede Zeile hat bei Problemen eine HANDLUNGSANWEISUNG statt nur eines
Kreuzes - kein Laufwerk, kein Worker und wenig Platz sind die drei Faelle, in
denen man vorher ratlos dastand.
- Laedt alle drei Quellen parallel (Promise.allSettled) und wiederholt im
5-s-Takt: beim ersten Start laeuft der Worker noch hoch, vorher stand dort
dauerhaft "Noch kein Worker gemeldet" ohne Aussicht.
- API-Keys sind SICHTBAR statt als Punkte: das sind kopierte Keys, keine
Passwoerter, und einen Tippfehler sieht man in Punkten nicht.
- Keys werden direkt nach dem Speichern geprueft (/metadata/status). Ein
falsch kopierter Key faellt sofort auf, statt erst beim ersten Rip als
"Unknown Disc" - mit der Wahl "Key korrigieren" oder "Trotzdem fertigstellen".
## Einstellungen -> Verarbeitung
Alle drei Preset-Auswahlen bekommen "Nicht komprimieren", und beim 4K-Feld
erscheint die AVX2-Warnung mit der gemessenen Zahl - aber nur, wenn die
Maschine sie wirklich braucht.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
56 lines
2.4 KiB
TypeScript
56 lines
2.4 KiB
TypeScript
// Encoder-Fähigkeiten eines Workers in Klartext übersetzen.
|
|
//
|
|
// Befund 25.07.2026: Die Rippy-VM lief auf dem generischen QEMU-CPU-Modell
|
|
// („QEMU Virtual CPU version 2.5+") und hatte deshalb kein AVX2, nur sse4_2.
|
|
// x265 lebt von diesen Vektorbefehlen — ein 4K-Encode brauchte dort gemessene
|
|
// 28-55 Stunden, und nirgends im UI war das zu sehen. Der Worker meldet die
|
|
// Angaben seit dieser Runde selbst (worker/caps.py), hier werden sie gedeutet.
|
|
|
|
// Stufen, mit denen Software-Encoding brauchbar schnell ist.
|
|
export const SIMD_SCHNELL = ['avx512f', 'avx2']
|
|
|
|
/**
|
|
* Warnt, wenn die CPU dieses Workers zu schwach für Software-Encoding ist.
|
|
* Gibt null zurück, wenn alles in Ordnung ist ODER die Stufe unbekannt ist —
|
|
* lieber nichts sagen als etwas Falsches behaupten.
|
|
*/
|
|
export function simdWarnung(simd?: string): string | null {
|
|
if (!simd || simd === 'unbekannt') return null
|
|
if (SIMD_SCHNELL.includes(simd)) return null
|
|
return `Diese CPU kann nur ${simd} (kein AVX2) — Software-Encoding ist hier `
|
|
+ 'sehr langsam. Bei einer virtuellen Maschine hilft es meist, den '
|
|
+ 'CPU-Typ auf "host" zu stellen; sonst besser einen Worker mit '
|
|
+ 'Hardware-Encoder wählen.'
|
|
}
|
|
|
|
// Reservierter Wert im Preset-Feld: „diesen Disc-Typ NICHT komprimieren".
|
|
// Muss mit ripping.PRESET_KEINE im Worker übereinstimmen — es gibt kein
|
|
// geteiltes Paket zwischen UI und Worker, deshalb steht der Wert hier nochmal.
|
|
export const PRESET_KEINE = 'keine'
|
|
|
|
interface WorkerFuerBewertung {
|
|
encoders?: string[]
|
|
info?: { cpu_simd?: string }
|
|
}
|
|
|
|
/**
|
|
* Kann von den gemeldeten Workern KEINER 4K in Software brauchbar schnell
|
|
* encodieren? Wahr nur, wenn das auch belegt ist: mindestens ein Worker hat
|
|
* eine bekannte SIMD-Stufe, und keiner erreicht AVX2 — und keiner hat einen
|
|
* Hardware-Encoder, der die Frage sowieso erledigt.
|
|
*
|
|
* Bei unbekannter Stufe (z. B. Windows-Worker, dort gibt es kein
|
|
* /proc/cpuinfo) wird NICHT gewarnt. Lieber schweigen als falsch warnen.
|
|
*/
|
|
export function schwacheEncoderCpu(workers?: WorkerFuerBewertung[]): boolean {
|
|
const liste = workers || []
|
|
if (liste.length === 0) return false
|
|
const hardware = liste.some(w => (w.encoders || []).some(e => !e.startsWith('cpu')))
|
|
if (hardware) return false
|
|
const bekannte = liste
|
|
.map(w => w.info?.cpu_simd)
|
|
.filter((s): s is string => !!s && s !== 'unbekannt')
|
|
if (bekannte.length === 0) return false
|
|
return !bekannte.some(s => SIMD_SCHNELL.includes(s))
|
|
}
|