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>
This commit is contained in:
Hitonabi
co-authored by
Claude Opus 5
Claude Opus 5
parent
a5e64f8e56
commit
66642b8d93
@@ -0,0 +1,133 @@
|
||||
/*
|
||||
* Worauf läuft Rippy — und was kann dieser Betrieb überhaupt?
|
||||
*
|
||||
* ## Der Befund des Commanders (28.08.2026)
|
||||
*
|
||||
* Im Windows-Fenster stand auf der Server-Status-Kachel:
|
||||
*
|
||||
* Worker erreichbar: 0 von 1
|
||||
* Kein Worker antwortet — ohne ihn läuft kein Rip. Prüfen: docker compose ps
|
||||
* Container-Platte: unbekannt
|
||||
* Freigaben: keine eingehängt
|
||||
*
|
||||
* Kein Satz davon ergibt auf einem Windows-PC einen Sinn. Es gibt keinen
|
||||
* Container, kein `docker compose`, keinen zweiten Worker — Rippy rippt dort
|
||||
* selbst. Sein Urteil: „Du hast ja quasi nur rippy genommen und die docker
|
||||
* installation für Windows gebaut."
|
||||
*
|
||||
* ## Warum ein Provider und kein Abruf je Seite
|
||||
*
|
||||
* Dieselbe Begründung wie beim Ereignis-Strom nebenan: Vier Seiten, die
|
||||
* dasselbe abfragen, sind vier Abrufe — und vier Gelegenheiten, dass eine
|
||||
* davon einen anderen Stand hat als die anderen. Der Betrieb ändert sich zur
|
||||
* Laufzeit nicht; er wird EINMAL geholt.
|
||||
*
|
||||
* ## Warum die Vorgabe „Docker" ist
|
||||
*
|
||||
* Solange die Antwort noch unterwegs ist, muss irgendetwas gelten. Die
|
||||
* Docker-Annahme ist hier die richtige Vorgabe — sie zeigt MEHR, und ein kurz
|
||||
* zu viel angezeigter Bereich ist harmloser als ein Bedienelement, das für
|
||||
* einen Augenblick verschwindet und wieder auftaucht.
|
||||
*
|
||||
* Ein FEHLGESCHLAGENER Abruf ist etwas anderes als „noch unterwegs":
|
||||
* `geladen` bleibt dann false, und wer das wissen will, kann es abfragen. Ein
|
||||
* Verbindungsabriss ist keine Aussage über die Welt (siehe useEventStream).
|
||||
*/
|
||||
import { createContext, useContext, useEffect, useState, type ReactNode } from 'react'
|
||||
import { api } from './api'
|
||||
|
||||
export interface BetriebsFaehigkeiten {
|
||||
/** Gibt es andere Maschinen, die Jobs übernehmen? */
|
||||
externe_worker: boolean
|
||||
/** Kann Rippy Netzwerk-Freigaben selbst einhängen? */
|
||||
freigaben_einhaengen: boolean
|
||||
/** Sind Pfade wie /app/media überhaupt gemeint? */
|
||||
container_pfade: boolean
|
||||
/** Kann Rippy MakeMKV/HandBrake selbst beschaffen? */
|
||||
werkzeuge_verwalten: boolean
|
||||
}
|
||||
|
||||
export interface Betrieb {
|
||||
modus: 'standalone' | 'verteilt'
|
||||
plattform: 'windows' | 'linux' | 'macos'
|
||||
im_container: boolean
|
||||
kann: BetriebsFaehigkeiten
|
||||
/** Womit ein Ablage-Feld vorbelegt wird — je Betrieb ein anderer Ort. */
|
||||
ablage_vorgabe: string
|
||||
/** Der Befehl zum Nachsehen. LEER heißt: es gibt keinen, den der Nutzer
|
||||
* ausführen könnte — dann darf auch keiner dastehen. */
|
||||
hilfe_befehl: string
|
||||
/** Ist die Auskunft schon da? False heißt „noch unterwegs ODER nicht
|
||||
* erreichbar" — nicht „es gibt keinen Betrieb". */
|
||||
geladen: boolean
|
||||
}
|
||||
|
||||
const VORGABE: Betrieb = {
|
||||
modus: 'verteilt',
|
||||
plattform: 'linux',
|
||||
im_container: true,
|
||||
kann: {
|
||||
externe_worker: true,
|
||||
freigaben_einhaengen: true,
|
||||
container_pfade: true,
|
||||
werkzeuge_verwalten: false,
|
||||
},
|
||||
ablage_vorgabe: '/app/media',
|
||||
hilfe_befehl: 'docker compose -p rippy ps',
|
||||
geladen: false,
|
||||
}
|
||||
|
||||
const BetriebContext = createContext<Betrieb>(VORGABE)
|
||||
|
||||
export function BetriebProvider({ children }: { children: ReactNode }) {
|
||||
const [betrieb, setBetrieb] = useState<Betrieb>(VORGABE)
|
||||
|
||||
useEffect(() => {
|
||||
let abgemeldet = false
|
||||
api.get('/betrieb')
|
||||
.then(antwort => {
|
||||
const d = antwort.data
|
||||
// Nur übernehmen, was WIRKLICH ankommt. Ein halb gefülltes Objekt
|
||||
// hieße in JavaScript `undefined` — und `undefined` ist falsch, also
|
||||
// verschwände ein Bereich stillschweigend.
|
||||
if (abgemeldet || !d || !d.kann) return
|
||||
setBetrieb({
|
||||
modus: d.modus === 'verteilt' ? 'verteilt' : 'standalone',
|
||||
plattform: d.plattform || 'linux',
|
||||
im_container: !!d.im_container,
|
||||
kann: {
|
||||
externe_worker: !!d.kann.externe_worker,
|
||||
freigaben_einhaengen: !!d.kann.freigaben_einhaengen,
|
||||
container_pfade: !!d.kann.container_pfade,
|
||||
werkzeuge_verwalten: !!d.kann.werkzeuge_verwalten,
|
||||
},
|
||||
ablage_vorgabe: d.ablage_vorgabe || '',
|
||||
hilfe_befehl: d.hilfe_befehl || '',
|
||||
geladen: true,
|
||||
})
|
||||
})
|
||||
.catch(() => {
|
||||
// Nichts tun. Ein misslungener Abruf ist keine Aussage über den
|
||||
// Betrieb — die Vorgabe bleibt stehen, `geladen` bleibt false.
|
||||
})
|
||||
return () => { abgemeldet = true }
|
||||
}, [])
|
||||
|
||||
return <BetriebContext.Provider value={betrieb}>{children}</BetriebContext.Provider>
|
||||
}
|
||||
|
||||
export function useBetrieb(): Betrieb {
|
||||
return useContext(BetriebContext)
|
||||
}
|
||||
|
||||
/**
|
||||
* Kurzform für den häufigsten Fall: Läuft Rippy als eigenständige App
|
||||
* (Windows-Client oder Docker-All-in-One)?
|
||||
*
|
||||
* Bewusst NICHT „ist Windows": Ein Docker-All-in-One hat auch keinen zweiten
|
||||
* Worker. Wer nach der Plattform fragt, obwohl er die Fähigkeit meint, baut
|
||||
* die nächste falsche Annahme ein.
|
||||
*/
|
||||
export function useAlleinbetrieb(): boolean {
|
||||
return !useBetrieb().kann.externe_worker
|
||||
}
|
||||
@@ -123,6 +123,17 @@ export function EventStreamProvider({ children }: { children: ReactNode }) {
|
||||
devices: d.devices === undefined ? null : d.devices,
|
||||
workers: d.workers ?? [],
|
||||
logs: d.logs ?? [],
|
||||
// ⚠️ Server-Zustand MIT übernehmen (Befund 28.08.2026).
|
||||
//
|
||||
// Er stand hier nicht, obwohl der Schnappschuss ihn liefert — und
|
||||
// `system.status` kommt erst nach bis zu 15 Sekunden. Nach jedem
|
||||
// Neuladen stand deshalb „Platz für Rippy: unbekannt" auf dem
|
||||
// Bildschirm. Das sieht aus wie eine Auskunft und ist keine.
|
||||
//
|
||||
// `undefined` heißt weiterhin „nicht mitgeschickt": dann bleibt der
|
||||
// alte Stand, statt auf leer zu fallen.
|
||||
systemInfo: d.info !== undefined ? d.info : null,
|
||||
ablagen: d.ablagen !== undefined ? d.ablagen : null,
|
||||
verbunden: true,
|
||||
})
|
||||
})
|
||||
|
||||
Reference in New Issue
Block a user