f449c4ee34
Ampel / ampel (push) Successful in 28s
Richtigstellung des Vortags-Befunds. Dort stand, MakeMKVs Schluessel-Kanal
sei abgeschaltet. Das war FALSCH: die Herleitung stuetzte sich auf zwei
Hostnamen aus alten Forumsbeitraegen (hkdata.fairuse.org,
hkdata.crabdance.com), die zwar wirklich nicht mehr aufloesen, von MakeMKV
aber laengst nicht mehr benutzt werden. Aufgedeckt durch den Einwand des
Commanders, unter Windows ginge es sofort.
Gegenprobe mit demselben Laufwerk und derselben Disc (Akira UHD, MKB v76):
Linux (Worker) Windows
Verbindungen KEINE EINZIGE 185.84.108.20:443
Meldung 3338 nie "Downloading latest HK"
_private_data.tar 2048 B, 0 Keys 6,4 MB, 604 Keys
Disc volume key unknown TCOUNT:5, geht auf
Gegengeprueft mit leerem UND gefuelltem Speicher, mit und ohne --noscan,
mit dev:/dev/sr0 und disc:0, mit geloeschter update.conf. Linux fragt nie.
Die Meldungsvorlage "Downloading latest %1 to %2 ..." steckt sehr wohl im
Linux-Binary - sie loest nur nicht aus. Gleiches Symptom im MakeMKV-Forum,
seit Jahren offen (t=25782, t=34022). Der Dienst lebt; der Worker erreicht
185.84.108.20:443 sogar problemlos.
BEWIESEN: Nach Uebernahme des Windows-Schluesselspeichers oeffnet
makemkvcon auf der VM die Akira-UHD - "Operation successfully completed",
TCOUNT:5, fuenf Titel, identisch zum Windows-Ergebnis. Erster belegter
UHD-Disc-Zugriff auf der Rippy-Maschine.
- makemkv_daten.py (beide Zwillinge): zaehle_schluessel,
private_data_pruefen, schluesselspeicher_status, private_data_schreiben.
Die Pruefung lehnt einen Speicher OHNE hkd_*.bin ab - sonst laedt jemand
den leeren Vorrat einer frischen Installation hoch, nichts aendert sich,
und niemand versteht warum. Modulkopf komplett neu, inkl. der
Fehldiagnose als Warnung fuer spaeter.
- API: GET/POST /system/keystore. Der Rohkoerper der Anfrage IST die Datei
(binaer - JSON/Base64 waere Ballast, Multipart kann die API nicht).
Groessengrenze 64 MB = client_max_body_size in nginx.conf.
- UI: neuer Block "Disc-Schluessel fuer 4K-UHD" UEBER dem KEYDB-Block, mit
Schluessel-Anzahl, Upload und Anleitung fuer den Windows-Weg. KEYDB.cfg
ist jetzt als Notnagel beschriftet. Worker-Plakette zeigt die Anzahl;
0 heisst sichtbar "4K-UHD scheitert".
- tasks.py: UHD-Fehlertext sagt den Windows-Weg an und nennt die Anzahl
bekannter Schluessel dieses Workers.
- caps.py meldet schluessel je Worker.
- Alle Falschaussagen korrigiert: UI (3), Anleitung (2), README (3),
KONZEPT §8 + §10, Worker-Dockerfile, makemkv_key.py (dort stand "Den
AACS-Schluessel zieht MakeMKV via LibreDrive ohnehin selbst aus dem
Laufwerk" - gilt fuer Blu-ray, NICHT fuer UHD).
- SAVEPOINT v3.11, ROADMAP Etappe 18 (Etappe 17 mit Nachtrag), AGENTS.
Offen: voller UHD-Rip inkl. Transcode-E2E; und ob sich der Abruf unter
Linux doch anstossen laesst.
Quellen (AGENTS Regel D):
- Linux laedt keine Hashed Keys, gleiches Symptom:
https://forum.makemkv.com/forum/viewtopic.php?t=25782
https://forum.makemkv.com/forum/viewtopic.php?t=34022
- Schluessel als hkd_*.bin in _private_data.tar:
https://forum.makemkv.com/forum/viewtopic.php?t=32675
- Meldungsformat: https://www.makemkv.com/developers/usage.txt
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
206 lines
11 KiB
TypeScript
206 lines
11 KiB
TypeScript
import { ReactNode } from 'react'
|
|
import { Disc, Tv, HardDrive, Bell, Wrench, Cpu, Download, HelpCircle } from 'lucide-react'
|
|
import { PageHeader } from '../components/ui/PageHeader'
|
|
import { Card, CardHeader, CardTitle, CardContent } from '../components/ui/Card'
|
|
|
|
function Abschnitt({ icon: Icon, titel, children }: { icon: any, titel: string, children: ReactNode }) {
|
|
return (
|
|
<Card>
|
|
<CardHeader>
|
|
<CardTitle className="flex items-center gap-2.5">
|
|
<Icon size={20} className="text-amber-500" />
|
|
<span>{titel}</span>
|
|
</CardTitle>
|
|
</CardHeader>
|
|
<CardContent className="space-y-3 text-sm leading-relaxed text-slate-600 dark:text-slate-300">
|
|
{children}
|
|
</CardContent>
|
|
</Card>
|
|
)
|
|
}
|
|
|
|
export default function AnleitungPage() {
|
|
const fett = "font-semibold text-slate-100"
|
|
|
|
return (
|
|
<div className="space-y-6 max-w-6xl mx-auto">
|
|
<PageHeader
|
|
title="Anleitung & Hilfe"
|
|
subtitle="So funktioniert Rippy — vom Einlegen der Disc bis zum fertigen Film in deinem Media-Server"
|
|
/>
|
|
|
|
<Abschnitt icon={Disc} titel="Der normale Weg: Disc rein, fertig">
|
|
<p>
|
|
<span className={fett}>1. Disc einlegen.</span> Rippy erkennt sie automatisch (Titel, Poster,
|
|
Beschreibung) und zeigt sie oben im Dashboard. Stimmt der Titel nicht → „Nicht korrekt?"
|
|
klicken und den richtigen wählen — Rippy merkt sich das für diese Disc.
|
|
</p>
|
|
<p>
|
|
<span className={fett}>2. „Rippen starten"</span> und das Ziel wählen: 🎥 Filme, 📺 Serien,
|
|
🎵 Musik oder ein eigener Ordner (auch NAS-Freigaben). Optional: „Nur Hauptfilm" (längster
|
|
Titel) oder per <span className={fett}>„Disc scannen"</span> einzelne Titel an-/abwählen.
|
|
</p>
|
|
<p>
|
|
<span className={fett}>3. Warten.</span> Rippy sichert verlustfrei (MakeMKV) und komprimiert
|
|
danach auf Arbeitsgröße (HandBrake) — alle Tonspuren und Untertitel bleiben erhalten.
|
|
Fertige Jobs haben einen Download-Knopf; Klick auf den Titel zeigt alle Details.
|
|
</p>
|
|
<p>
|
|
<span className={fett}>Vollautomatik:</span> Unter Einstellungen → Ripping einschaltbar —
|
|
dann startet der Rip ohne Nachfrage, sobald eine Disc erkannt wurde. Bereits gerippte
|
|
Discs (Fingerabdruck) werden übersprungen.
|
|
</p>
|
|
</Abschnitt>
|
|
|
|
<Abschnitt icon={Tv} titel="Serien rippen">
|
|
<p>
|
|
Im „Rippen starten"-Dialog <span className={fett}>„Serien"</span> wählen, Serienname und
|
|
Staffel angeben. Die Ablage wird automatisch <code>Serie/Season 02/…</code>, und nach dem
|
|
Rip ordnet Rippy die Episoden über einen Laufzeit-Abgleich mit TMDB zu und benennt sie
|
|
(„Serie S02E03.mkv"). Das passiert nur bei <span className={fett}>eindeutiger</span> Zuordnung —
|
|
im Zweifel bleiben die Original-Namen und das Log sagt warum.
|
|
</p>
|
|
<p>
|
|
Eine komplette Staffel auf einer Disc klappt auch, wenn alle Episoden gleich lang sind
|
|
(Anime-Boxen). Bei Teil-Discs mit lauter gleich langen Episoden ist eine automatische
|
|
Zuordnung prinzipiell nicht möglich — dann von Hand umbenennen.
|
|
</p>
|
|
</Abschnitt>
|
|
|
|
<Abschnitt icon={HardDrive} titel="NAS & Speicherziele">
|
|
<p>
|
|
Einstellungen → Speicherziele: Rechner/NAS eintragen, <span className={fett}>Benutzer +
|
|
Passwort</span> angeben (Windows und die meisten NAS lehnen Gast-Zugriffe ab!), „Freigaben
|
|
auflisten", Freigabe wählen, „Einhängen & speichern". Danach taucht das Ziel im
|
|
„Rippen starten"-Dialog auf und wird beim Start automatisch wieder verbunden.
|
|
</p>
|
|
<p>
|
|
<span className={fett}>4K-UHD-Tipp:</span> Rohdaten sind bis 100 GB groß. Wenn die
|
|
Rippy-Platte knapp ist (Dashboard zeigt den freien Platz), das Arbeitsverzeichnis unter
|
|
Einstellungen → Verarbeitung auf eine große Freigabe legen. Rippy prüft den Platz vor
|
|
jedem Rip und bricht sonst mit Klartext ab.
|
|
</p>
|
|
</Abschnitt>
|
|
|
|
<Abschnitt icon={Tv} titel="Jellyfin, Emby, Kodi, Plex">
|
|
<p>
|
|
Einstellungen → Ripping → Media-Server: Rippy benennt fertige Rips als „Titel (Jahr)" und
|
|
legt für Jellyfin/Emby/Kodi zusätzlich <code>movie.nfo</code> + <code>poster.jpg</code> dazu —
|
|
dein Server erkennt alles ohne Nacharbeit (Plex nutzt nur die Benennung).
|
|
</p>
|
|
<p>
|
|
<span className={fett}>Null-Klick-Kette:</span> Bei Jellyfin/Emby zusätzlich Server-URL und
|
|
API-Key eintragen (Administration → API-Schlüssel) — dann stößt Rippy nach jedem fertigen
|
|
Rip sofort einen Bibliotheks-Scan an. Disc rein → Film erscheint im Server.
|
|
</p>
|
|
</Abschnitt>
|
|
|
|
<Abschnitt icon={Bell} titel="Benachrichtigungen">
|
|
<p>
|
|
Einstellungen → Benachrichtigungen: eine Webhook-URL eintragen (Discord-Webhook, ntfy-Thema
|
|
für Handy-Push, Slack oder eigenes JSON), „Test senden", speichern. Rippy meldet sich, wenn
|
|
ein Job fertig ist, fehlschlägt oder abgebrochen wird. Die Schritt-für-Schritt-Anleitung je
|
|
Dienst steht direkt auf der Einstellungs-Seite.
|
|
</p>
|
|
</Abschnitt>
|
|
|
|
<Abschnitt icon={Cpu} titel="Weitere Maschinen als Encoding-Worker">
|
|
<p>
|
|
Die Kompression kann jede Maschine im Netz übernehmen — Einstellungen → Worker.
|
|
Für <span className={fett}>Windows</span> gibt es einen <span className={fett}>Installer
|
|
(.exe)</span>: herunterladen, doppelklicken, im Fenster Adresse + Name eintragen,
|
|
„Installieren" — kein Konsolenfenster, kein CLI (nur Python 3.10+ muss auf dem PC sein).
|
|
Für <span className={fett}>Linux</span> gibt es einen Docker-Befehl. Die Maschine taucht
|
|
danach unter ihrem Namen in der Worker-Liste auf und zieht sich Kompressions-Jobs
|
|
automatisch. Gerippt wird immer auf der Rippy-Hauptmaschine.
|
|
</p>
|
|
<p>
|
|
Der Windows-Worker läuft mit <span className={fett}>Tray-Symbol</span> neben der Uhr
|
|
(Status, Start/Stopp, „Rippy öffnen", Log) — gestartet über <code>start-tray.bat</code>.
|
|
Deinstallieren: <code>uninstall.ps1</code> im Worker-Ordner stoppt alles, entfernt den
|
|
Autostart, meldet den Worker in Rippy ab und löscht den Ordner rückstandsfrei.
|
|
</p>
|
|
<p>
|
|
<span className={fett}>Wichtig:</span> Worker verbinden sich direkt im Heimnetz — in den
|
|
Befehlen immer die <span className={fett}>LAN-Adresse</span> der Rippy-Maschine verwenden,
|
|
nie eine externe Domain (die läuft über den Reverse-Proxy und blockt).
|
|
</p>
|
|
</Abschnitt>
|
|
|
|
<Abschnitt icon={Wrench} titel="MakeMKV-Beta-Key & System">
|
|
<p>
|
|
Blu-ray-Ripping braucht den MakeMKV-Beta-Key, der etwa <span className={fett}>monatlich
|
|
wechselt</span> (MakeMKV-Forum, Thread „MakeMKV is free while in beta"). Neuen Key unter
|
|
Einstellungen → System eintragen — gilt ab dem nächsten Rip, ohne Neustart. DVDs gehen
|
|
immer auch ohne Key. Dort stehen auch die Werkzeug-Versionen und der freie Speicherplatz.
|
|
</p>
|
|
{/* 25.07.2026 richtiggestellt: Updates bringen keine Disc-Schluessel mit — siehe UHD-Absatz unten. */}
|
|
<p>
|
|
<span className={fett}>Updates:</span> „Auf Updates prüfen" (ebenfalls Einstellungen →
|
|
System) vergleicht die installierten Versionen mit makemkv.com und den offiziellen
|
|
HandBrake-Releases. Gibt es ein MakeMKV-Update, zeigt Rippy den fertigen
|
|
Update-Befehl an — neue Versionen bringen bessere Laufwerks-Unterstützung und
|
|
Fehlerbehebungen. <span className={fett}>Disc-Schlüssel für 4K-UHD kommen dagegen nicht
|
|
aus einem Update</span> — die holt MakeMKV zur Laufzeit, und die Linux-Version tut das
|
|
nie. Wie du sie trotzdem bekommst, steht unter „Häufige Fragen".
|
|
</p>
|
|
</Abschnitt>
|
|
|
|
<Abschnitt icon={Download} titel="Fertige Dateien herunterladen">
|
|
<p>
|
|
Bei fertigen Jobs: „Download" in der Aktion-Spalte (oder Klick auf den Titel) → Dateiliste
|
|
mit „Alle herunterladen". Die Job-Liste lässt sich per Papierkorb bzw. „Erledigte aufräumen"
|
|
leeren — <span className={fett}>die gerippten Dateien bleiben dabei immer liegen</span>.
|
|
„CSV" exportiert die komplette Historie für Excel.
|
|
</p>
|
|
</Abschnitt>
|
|
|
|
<Abschnitt icon={HelpCircle} titel="Häufige Fragen">
|
|
<p>
|
|
<span className={fett}>„Diese Disc wurde bereits gerippt"?</span> Rippy erkennt Discs am
|
|
Fingerabdruck. Nochmal rippen geht trotzdem — der Hinweis verhindert nur Versehen.
|
|
</p>
|
|
{/*
|
|
25.07.2026 auf BEIDEN Maschinen nachgemessen und erneut korrigiert. Es
|
|
stand hier nacheinander zweierlei Falsches: erst "ein MakeMKV-Update macht
|
|
die Disc rippbar", dann "MakeMKVs Schluessel-Kanal ist tot". Richtig ist:
|
|
makemkvcon unter Linux ruft die Schluessel nie ab, die Windows-Version
|
|
schon (Meldung 3338, Verbindung nach 185.84.108.20:443).
|
|
*/}
|
|
<p>
|
|
<span className={fett}>4K-UHD schlägt fehl mit „volume key is unknown"?</span> Das Laufwerk
|
|
liest die Disc einwandfrei (LibreDrive) — MakeMKV fehlt nur der Schlüssel dieser Pressung.
|
|
Der Grund liegt nicht bei dir und nicht bei Rippy: <span className={fett}>die Linux-Version
|
|
von MakeMKV holt Disc-Schlüssel nie selbst aus dem Netz</span>. Die Windows-Version tut es.
|
|
Ein MakeMKV-Update ändert daran nichts.
|
|
</p>
|
|
<p>
|
|
<span className={fett}>Der Weg drumherum:</span> MakeMKV einmalig auf einem Windows-PC
|
|
installieren (gleicher Beta-Key), das Laufwerk dort anstecken, die Disc öffnen — MakeMKV
|
|
lädt die Schlüssel dabei nach. Dann in MakeMKV unter <em>Preferences → General</em> das
|
|
„MakeMKV data directory" nachschlagen und die Datei <code>_private_data.tar</code> daraus
|
|
bei Rippy unter Einstellungen → System hochladen. Wirkt ab dem nächsten Rip. Für neue
|
|
Discs gelegentlich wiederholen — der Block dort zeigt dir, wie viele Schlüssel Rippy kennt.
|
|
</p>
|
|
<p>
|
|
Geht eine Pressung auch damit nicht auf, kennt MakeMKV sie selbst nicht. Dann bleiben zwei
|
|
Dinge: eine <code>KEYDB.cfg</code> (ebenfalls dort hochladbar, der Notnagel), oder den
|
|
<span className={fett}> AACS-Dump</span> im MakeMKV-Forum im Bereich „Ultra HD Blu-ray"
|
|
einreichen — der bleibt jetzt erhalten und steht unter Einstellungen → System zum
|
|
Herunterladen. <span className={fett}>Rippy liefert keine Schlüssel mit und lädt keine
|
|
herunter</span> — es verwaltet nur, was du selbst mitbringst.
|
|
</p>
|
|
<p>
|
|
<span className={fett}>„Neu komprimieren" fehlt bei einem Fehl-Job?</span> Der Knopf
|
|
erscheint nur, wenn die Rohdaten noch daliegen — bei einem Job, der nie gerippt hat, gäbe
|
|
es nichts zu komprimieren.
|
|
</p>
|
|
<p>
|
|
<span className={fett}>Kein Laufwerk sichtbar?</span> In einer VM muss das Laufwerk per
|
|
USB-Passthrough durchgereicht sein (nicht als emuliertes CD-ROM) — Details in der README.
|
|
</p>
|
|
</Abschnitt>
|
|
</div>
|
|
)
|
|
}
|