10 Commits

Author	SHA1	Message	Date
Hitonabi	6438beec05	fix(worker): kein CMD-Blitzen mehr - und die 7200-Sekunden-Meldung ist erklaert ... Zwei Meldungen, beide auf dieselbe Wurzel zurueckgefuehrt: Der Worker startet Konsolenprogramme, und das hat unter Windows Nebenwirkungen. 1. "Es geht immer alle paar Sekunden ne CMD auf." Kein Geist, sondern der HERZSCHLAG. Der Worker laeuft als pythonw.exe, also ohne eigene Konsole. Wer ohne Konsole ein Konsolenprogramm startet, bekommt von Windows eine NEUE - und die ist sichtbar. `capture_output=True` hilft nicht: es leitet die Datenstroeme um, unterdrueckt aber kein Fenster. Und caps.py fragt jede Minute `HandBrakeCLI --help`, `--preset-list` und `--version` ab, dazu makemkvcon aus der Schluessel-Automatik: vier bis fuenf Fenster pro Minute, in Schueben. Neues winlauf.py haelt CREATE_NO_WINDOW an EINER Stelle; alle elf Aufrufe in caps.py, ripping.py und schluessel.py benutzen es. Auf Linux ist der Wert 0 und creationflags=0 eine Nulloperation - im Worker-Container gegengeprueft, damit derselbe Code auf beiden Seiten laeuft. 2. Die 7200 Sekunden sind CELERYS EIGENE UMRECHNUNG, nicht die Uhren. Erst fiel auf, dass die Sekundenbruchteile nur 40 ms auseinanderliegen (.177269 vs .134799) - derselbe Augenblick, zweimal verschieden gerechnet. Die Quelle sagt warum (celery/utils/time.py): def utcoffset(): # Sekunden WEST von UTC, in Stunden return time.altzone // 3600 # CEST -> -2 ; UTC -> 0 def adjust_timestamp(ts, offset, here=utcoffset): return ts - (offset - here()) * 3600 Absender VM (offset 0), Empfaenger Windows-PC (here() = -2): ts - (0 - (-2)) * 3600 = ts - 7200. Celery verschiebt den empfangenen Stempel also selbst und vergleicht ihn dann mit der eigenen Uhr. Die Annahme dahinter - Ereignisse truegen Ortszeit - stimmt nicht, `Event()` stempelt Epoch. Abhilfe gemessen, nicht geraten: Mit TZ=UTC meldet Windows utcoffset 0 (timezone=0, isdst=0 - auf dem Commander-PC geprueft), damit wird die Umrechnung zur Nulloperation. Beide .bat-Dateien setzen es jetzt. Nebeneffekt ist erwuenscht: Der Worker rechnet dann in derselben Zone wie die VM und wie Rippys UI. Fuer Rippy war die Meldung ohnehin folgenlos - /capabilities fragt per Celery-Ping (Frage/Antwort, ohne Zeitstempel), nicht ueber die Gossip-Ereignisse. Aber eine Warnung, die bei jedem Blick ins Log steht und nichts bedeutet, kostet Vertrauen. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 16:05:54 +02:00
Hitonabi	4195854bf8	feat(bausteine): Preset-Liste, Pfad-Vorschlag und Restzeit - alles gemessen ... Vier neue reine Bausteine, jeder mit Tests. Sie beantworten Fragen, die Rippy bisher geraten oder gar nicht gestellt hat. 1. caps.parse_preset_liste - die Preset-NAMEN, die das HandBrake DIESES Workers wirklich kennt (`--preset-list`, Format im Worker-Image gemessen). Damit endet das Raten: die Namen unterscheiden sich je HandBrake-Version, und ein erfundener Name laesst die Kompression scheitern. Richtigstellung zum SAVEPOINT v3.16: Dort galt es als unmoeglich, die Hardware-Preset-Namen auf der Rippy-VM zu ermitteln, weil dort kein Hardware-Encoder laeuft. Gemessen ist das falsch - die Kategorie `Hardware/` steht vollstaendig in der Liste (VCN, NVENC, QSV, MF). HandBrake trennt zwei Fragen: --preset-list nennt alle Presets, --help nur die nutzbaren Encoder. Zwei Fragen, zwei Quellen. 2. mounts.pfad_map_vorschlag/pfad_map_zeile - der fehlende Anschluss fuer RIPPY_PATH_MAP. Geraten werden muss dafuer nichts: Rippy hat die Freigabe selbst eingehaengt und kennt ihre Quelle (//host/share). Mountpunkt plus Quelle IST das Mapping. NFS gibt bewusst "" - Windows-Schreibweise ist nicht ableitbar (AGENTS Regel D). Der Test fand dabei sofort die dokumentierte Windows-Falle: os.path.join baute `/app/media\rippy` in einen Container-Pfad, das Mapping waere still wirkungslos geblieben. _mountpoint nutzt jetzt posixpath. 3. presets.empfehlung - "immer das Beste" (Commander-Anforderung) ohne Punktesystem: fuer jede Lage eine feste Reihenfolge echter Namen, genommen wird der erste, den der Worker kennt. Hardware nur, wenn die Familie wirklich gemeldet ist (vce -> Preset heisst VCN, sonst liefe eine AMD-Karte unter dem Intel-Namen). vaapi und MF werden nie empfohlen: fuer vaapi gibt es kein Preset, bei MF ist die Nutzbarkeit nicht ablesbar. 4. eta - Restzeit aus dem gemessenen Fortschritt. Messreihe je Phase (Rip und Kompression haben nichts miteinander zu tun), Stillstand verlaengert die Schaetzung, und unter zwei Messwerten oder 60 Sekunden Spanne gibt es ehrlich keine Aussage. Test mit den echten 25.07.-Werten: 1,44 % in 29 min landet bei "noch ca. 1 Tag 23 h" - genau die Angabe, deren Fehlen den 50-Stunden-Lauf unsichtbar machte. Dazu: HandBrakes "Invalid preset <Name>" wird uebersetzt. Vorher stand im UI nur "HandBrake endete mit Code 3" - dass der Preset-NAME das Problem ist, war daraus nicht zu erraten. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 12:57:51 +02:00
Hitonabi	fd1feaaee3	fix(ui): die Ablage war im UI ueberhaupt nicht einstellbar ... Der Grund, warum der erste Rip mit externem Encoder scheitern MUSSTE - und Commander-Vorgabe: "Wenn ein externes Ziel eingehaengt ist, soll Rippy das ausgewaehlte als Arbeitsziel verwenden. Das stellt man ja sowieso in den Einstellungen ein. Das muss auch fuer den Automatik-Modus so sein." Genau das ging nicht. outputDir stand in den Einstellungen, wurde von der Vollautomatik (main.py) und der Schnellwahl (RipTargetModal) gelesen - aber es gab NIRGENDS ein Eingabefeld. Die Ablage klebte auf /app/media, der Container-Platte. Das Arbeitsverzeichnis hatte eine Auswahlliste der eingehaengten Ziele, das Ziel nicht. Folge im Praxistest: Rohdaten auf der NAS (die der PC erreicht), Ziel auf der VM-Platte (die er nicht erreicht, kein Samba dort). Der externe Encoder konnte lesen, aber nicht schreiben - und das haette man mit den vorhandenen Bedienelementen gar nicht anders einstellen koennen. JETZT: Ablage-Auswahl in Einstellungen -> Ripping, mit derselben Liste eingehaengter Ziele wie das Arbeitsverzeichnis. Damit wirkt sie automatisch auch in der Vollautomatik und in der Schnellwahl, weil beide outputDir lesen - also genau so, wie der Commander es beschrieben hat. DAZU die Pruefung, die den Vorfall verhindert haette: Sobald ein EXTERNER Worker gemeldet ist, warnt das UI, wenn Ablage und Arbeitsverzeichnis nicht beide auf einer erreichbaren Freigabe liegen. Drei Faelle, jeweils mit der Konsequenz im Klartext: - Arbeitsverzeichnis auf der Container-Platte -> externer Encoder kann nicht lesen - Arbeit auf Freigabe, Ablage lokal -> kann lesen, nicht schreiben (der Vorfall) - beide auf VERSCHIEDENEN Freigaben -> laeuft, kostet aber eine Vollkopie "Extern" ist dabei keine Heuristik ueber IPs oder Namen: caps.py meldet es selbst (`extern`), weil /app im Rippy-Image immer existiert und ausserhalb nie. Zusaetzlich meldet der Worker jetzt seine `pfad_map` - damit kann das UI im naechsten Schritt sagen, ob die Uebersetzung ueberhaupt gesetzt ist. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 11:58:58 +02:00
Hitonabi	fe12401e34	fix(worker): Hardware-Encoder und CPU-Merkmale auf Windows - plus ehrliche Transcode-Fehler ... Aus dem gescheiterten Test-Rip des Commanders (Job 95afdc89) und seiner UI-Durchsicht. Der Reihe nach. ## 1. Der externe Encoder wurde SEHR WOHL gesehen (Diagnose-Korrektur) Der Commander schloss aus der Meldung, das System sehe seinen PC nicht. Live gemessen sagt das Gegenteil: meta.transcode_node = tobisnicerpc@TobisNicerPC VM-Worker-Log = nur rip_disc, KEIN transcode_files 22:19:41.271 Kompression eingereiht 22:19:41.453 "Keine Roh-MKVs gefunden" <- 182 ms spaeter Das Routing hat funktioniert. Sein PC nahm die Aufgabe an und lehnte sie sofort ab, weil er /app/media/rippy/<job> nicht finden kann - ein Pfad, der nur INNEN im Container existiert. Der Rip war vollstaendig (79,6 GB auf der NAS). ## 2. Der Hardware-Encoder-Bug war meiner leite_backends_ab() verlangte zusaetzlich ein Geraet: /dev/dri fuer VAAPI/QSV/VCE bzw. nvidia-smi fuer NVENC. Unter WINDOWS gibt es beides nicht - der PC des Commanders (RX 9070 XT) meldete deshalb nur CPU-Encoder, obwohl HandBrakes Windows-Build vce_*/nvenc_*/qsv_* beherrscht. Der Bug traf genau den Anwendungsfall, fuer den externe Worker gedacht sind. Die Pruefung war ausserdem ueberfluessig: HandBrake probiert Hardware beim Start selbst an und listet nur Nutzbares - auf der VM belegt durch "qsv: not available on this system" bei gleichzeitig fehlendem qsv_* in --help. Jetzt ist HandBrakes Liste die einzige Auskunft. Dazu nach FAMILIE unterschieden (nvenc/qsv/vce/vaapi) statt alles in "vaapi" zu werfen - eine AMD-Karte lief unter dem Intel-Namen. Hardware-AV1 bekommt eine eigene Kennung, weil es die beste Kombination aus Tempo und Groesse ist und sonst unsichtbar bliebe. ## 3. Vektorbefehle unter Windows - gemessen, nicht "unbekannt" Es gibt dort kein /proc/cpuinfo, also meldete der Windows-Worker "Vektorbefehle unbekannt" - gerade auf der Maschine, die encodieren soll. Jetzt ueber IsProcessorFeaturePresent (kernel32, winnt.h dokumentiert) plus CPU-Name aus der Registry. Auf dem Commander-PC gegengeprueft: vorher: AMD64 Family 26 Model 68 Stepping 0 / Vektorbefehle unbekannt jetzt: AMD Ryzen 7 9700X 8-Core Processor / avx512f / 16 Kerne Damit verschwindet die AVX2-Warnung fuer diesen Worker von selbst - genau das hatte der Commander gefordert. ## 4. Ehrliche Fehlermeldung statt "Keine Roh-MKVs gefunden" Neues _erreichbarkeit_pruefen() unterscheidet jetzt drei Faelle statt einem: Pfad nicht erreichbar UND kein Mapping gesetzt (nennt RIPPY_PATH_MAP samt Beispiel), Mapping gesetzt aber greift nicht, oder Pfad einfach nicht da. Und es prueft BEIDE Pfade - im Fall des Commanders lag die Quelle auf der erreichbaren NAS, das ZIEL aber auf der VM-Platte ohne Samba; das waere erst beim Schreiben nach Stunden Rechenzeit aufgefallen. Jede Meldung sagt jetzt ausdruecklich, dass die Rohdaten NICHT verloren sind und "Neu komprimieren" genuegt. ## 5. Persoenliche Werte raus Vier Platzhalter trugen die Umgebung des Commanders (192.168.178.20, TOBIS-PC, seine Jellyfin- und Rippy-IP). In einem Repo, das weitergegeben wird, hat das nichts verloren. Nebenbei dreimal in die eigene Falle getappt: deutsche Anfuehrungszeichen in DOPPELT gequoteten Python-Strings beenden den String vorzeitig. Der Bestand nutzt dafuer einfach gequotete f-Strings - jetzt auch meine. NOCH OFFEN und wichtig: RIPPY_PATH_MAP wird von niemandem GESETZT (Installer, UI, Compose). Ein Windows-Worker kann damit grundsaetzlich nicht transcodieren. Das ist der naechste Schritt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-26 11:51:47 +02:00
Hitonabi	883c1c290b	fix(caps,ui): Encoder werden gemessen statt behauptet ... Der Modulkopf von caps.py verspricht "ehrlich erkannt, nicht behauptet" - erkenne_encoder() tat aber drei Mal das Gegenteil: 1. cpu-x264 und cpu-x265 standen fest verdrahtet in der Liste ("immer dabei"). Ein Rip-Worker OHNE HandBrake behauptete damit, komprimieren zu koennen; jeder Transcode dort endete sofort mit "nicht installiert". 2. 'vaapi' wurde allein wegen /dev/dri gemeldet, ohne zu pruefen, ob HandBrake das ueberhaupt kann. Auf der VM gemessen: das Worker-Image kennt svt_av1/x264/x265/mpeg4/mpeg2/VP8/VP9/theora und KEINEN einzigen Hardware-Encoder. Rippy haette VAAPI versprochen und dann versagt. 3. Ueber die Rechenleistung sagte es gar nichts. Genau deshalb war nicht zu sehen, dass ein 4K-Encode auf dieser Maschine Tage braucht: CPU-Modell ist das generische "QEMU Virtual CPU version 2.5+", grep -c avx2 /proc/cpuinfo = 0, nur bis sse4_2. x265 lebt von AVX2. Gemessen an der Leseposition des Quellstroms: 28-55 h fuer einen Film, 3,84 von 4 Kernen gesaettigt. Abhilfe waere der CPU-Typ 'host' in Proxmox. Jetzt wird die Encoder-Liste aus `HandBrakeCLI --help` geparst (Abschnitt -e/--encoder, Formatstrings im Worker-Image gemessen - AGENTS Regel D), und Hardware zaehlt nur, wenn Geraet UND HandBrake-Unterstuetzung da sind. Neu gemeldet: cpu-av1 (svt_av1 ist wirklich verfuegbar) sowie CPU-Modell, Kernzahl und Vektorbefehlsstufe je Worker. UI: Kerne/Vektorbefehle stehen bei jedem Worker (Worker-Tab und Einstellungen -> System), dazu die ungefilterte HandBrake-Auskunft und eine sichtbare Warnung, wenn AVX2 fehlt - inklusive des Hinweises auf den VM-CPU-Typ. Der Warntext liegt in lib/encoder.ts, damit er nicht doppelt im Code steht. Mit im gleichen Zug (dieselbe Datei): der Schalter "Alle Tracks rippen" ist entfallen. Er war ein Placebo - abcde bekommt keine Track-Auswahl und es gab auch keine Oberflaeche, um eine Teilmenge zu waehlen. Eine Audio-CD wurde also immer vollstaendig gerippt, egal wie der Schalter stand. An seiner Stelle steht jetzt die Wahrheit. 7 Tests, Testdaten sind echte HandBrake-Ausgaben von der VM. Der Parser ist zusaetzlich gegen die vollen 697 Zeilen der echten --help gegengeprueft. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 21:04:42 +02:00
Hitonabi	f449c4ee34	fix(uhd): 4K-UHD geloest - makemkvcon holt Schluessel unter Linux nie ... 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>	2026-07-25 11:18:09 +02:00
Hitonabi	0935766f61	feat(uhd): KEYDB.cfg-Unterstuetzung - MakeMKVs Schluessel-Kanal liefert nichts mehr ... 4K-UHD scheiterte an "The volume key is unknown for this disc". Am 25.07.2026 im Worker-Container nachgemessen: Laufwerk und MakeMKV sind in Ordnung (LibreDrive v06.3 / Meldung 1011, Disc wird gelesen, AACS-Dump geschrieben) - MakeMKV versucht gar nicht erst, online einen Schluessel zu holen. Belege: _private_data.tar enthaelt nur die Index-Datei und KEINE hkd_*.bin; auch mit geloeschter update.conf (Meldung 5074 belegt den Web-Kontakt) und mit app_UpdateEnable="1" kam keiner; hkdata.fairuse.org und hkdata.crabdance.com loesen weltweit nicht mehr auf (NXDOMAIN gegen Fritz!Box, 8.8.8.8, 1.1.1.1). Betroffen war Akira UHD (MKB v76, Pressung Dez. 2020) - also gerade KEINE Neuerscheinung. Der bisherige Fehlertext ("Disc neuer als die Schluessel-Datenbank, mit einem der naechsten Updates rippbar") war falsch. Einziger heute funktionierender Weg ist eine vom Nutzer selbst mitgebrachte KEYDB.cfg. Rippy liefert KEINE Schluessel mit, laedt keine herunter und verteilt keine - es stellt nur den Platz bereit und zeigt an, was dort liegt. - Datenverzeichnis persistent gemountet (MAKEMKV_DATA_HOST, Default /srv/rippy/makemkv): KEYDB.cfg und AACS-Dumps ueberleben jeden Rebuild. Vorher loeschte jeder "up -d --build" beides - inklusive des Dumps, auf den die Fehlermeldung selbst verwies. - entrypoint.sh und tasks.py schreiben settings.conf ergaenzend statt zerstoerend. Der entrypoint bricht bei nicht beschreibbarem Verzeichnis nicht mehr ab - mit "restart: unless-stopped" waere das ein Crashloop gewesen, in dem auch reines DVD-Rippen tot ist. - Neues Zwillings-Modul makemkv_daten.py (docker/api + docker/worker, byteweise identisch; test_zwillinge_sind_byteweise_identisch wacht darueber und wurde durch absichtliches Verstellen als wirksam nachgewiesen). - API: GET/POST/DELETE /system/keydb, GET /system/aacs-dumps(/{dateiname}). JSON-Body statt Multipart - python-multipart ist bewusst nicht installiert und wuerde die API beim Import toeten. nginx client_max_body_size 64m, sonst scheitert der Upload mit 413, bevor die API ihn sieht. - UI (Einstellungen -> System): Status, Hochladen per Datei-Dialog, Entfernen, Dump-Download, KEYDB-Plakette je Worker (nur wo das Verzeichnis wirklich gemountet ist - ein Remote-Transcode-Worker truege sonst eine Warnung, die ihn nichts angeht). - parse_msg() + log_cb: MakeMKV-Meldungen landen im Rippy-Log (gedrosselt: Code 1003 raus, keine Wiederholungen, max. 40 je Rip). Nebenbei behoben: der alte Parser (split(",", 4)[3]) schnitt jede Meldung am ersten Komma ab. - Fuenf Stellen richtiggestellt, die behaupteten, MakeMKV-Updates braechten die neueste Disc-Schluessel-Datenbank mit (UI, Anleitung, README, Worker-Dockerfile, makemkv_key.py). NICHT bewiesen: ein erfolgreicher UHD-Rip - es lag keine KEYDB.cfg mit dem Akira-Schluessel vor. Belegt sind der Befund und die neue Mechanik. So steht es auch im SAVEPOINT und in der ROADMAP. Quellen (AGENTS Regel D): - Datenverzeichnis + Dateiname GROSS/case-sensitiv: https://forum.makemkv.com/forum/viewtopic.php?t=30636 - hkd_*.bin in _private_data.tar: https://forum.makemkv.com/forum/viewtopic.php?t=32675 - headless settings.conf / app_UpdateEnable: https://forum.makemkv.com/forum/viewtopic.php?t=20364 - KEYDB.cfg-Zeilenformat (libaacs): https://github.com/ShiftMediaProject/libaacs/blob/master/KEYDB.cfg - MSG-/PRGV-Format: https://www.makemkv.com/developers/usage.txt Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-07-25 01:26:08 +02:00
Hitonabi	5778ac4645	Praxis-Feedback-Runde: CIFS-Cap-Fix, TMDB v3-Keys, 4K-UHD-Typ, Vollautomatik, Job-Verwaltung, Worker-Namen ... Zwei bewiesene Bug-Fixes: - SMB-Mount 'Unable to apply new capability set': mount.cifs hebt CAP_DAC_READ_SEARCH an, die in Dockers Default-Caps fehlt (auf der VM reproduziert: Bounding-Set a82425fb ohne Bit 2; mit der Capability verschwindet der Fehler). Fix: cap_add DAC_READ_SEARCH fuer den api-Container. - TMDB fiel still aus: Client konnte nur v4-Bearer-Tokens, der uebliche 32-Hex-v3-Key bekam 401 und die Suche lieferte nur OMDb. Jetzt beide Key-Arten (ist_v4_token + api_key-Query-Param lt. developer.themoviedb.org, mit Tests) — damit kommen auch die deutschen Texte an (language=de-DE war ueberall schon gesetzt). Neu: GET /metadata/status + 'Verbindung pruefen' in Einstellungen -> APIs (Live-Check am Cache vorbei). Features aus dem Commander-Feedback: - 4K UHD als eigener Disc-Typ: classify >= 55 GiB (BD-66/BD-100; BD-50 bleibt bluray), beide detection.py + Tests, eigene Badge-Farbe in Dashboard/Laufwerken, Prescan-Label '4K UHD'. UHD-Rip-Fehler 'Failed to open disc' (Code 11) bekommt Klartext: LibreDrive-Firmware noetig. - Vollautomatik (Setting autoRipStart): Disc erkannt -> Rip startet ohne Popup in den Schnellwahl-Ordner (Serie->Serien, sonst Filme, CD->Musik). - Job-Verwaltung: 'Neu komprimieren' nur noch mit can_retry (Rohdaten liegen wirklich da), DELETE /jobs/{id} + 'Erledigte aufraeumen' (Dateien bleiben immer), 'Alle herunterladen' im Job-Detail (gestaffelte Einzel-Downloads statt Server-Zip von 40-GB-Dateien). - Worker zuordenbar: WORKER_NAME-Env als stabiler Anzeigename (fixt auch die Offline-Leichen nach Rebuilds), info.hostname/ip gemeldet, Online-Abgleich ueber hostname, DELETE /workers/{name} + Papierkorb im UI, Quelle-Anzeige an der Disc-Karte ('Quelle: TMDB - 99 % sicher'). - Ripping-Tab nach Medium gegliedert (Video/Audio-CD/Allgemein) + Untertitel-Klartext (--all-audio/--all-subtitles bleiben komplett), CD -> Musik-Vorauswahl im Ziel-Dialog, Ordner-Verwaltung beschriftet und standardmaessig eingeklappt. - Docs: SAVEPOINT v3.3, ROADMAP Etappe 14 + Ideen (nativer Windows-Worker, deutsche OMDb-Texte via TMDB-Find), README. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 13:29:10 +02:00
Hitonabi	e032a9df1c	feat(backend): Media-Server-Aufbereitung, echte Webhooks, SMB-Klartext, UHD-Arbeitsverzeichnis, MakeMKV-Key via UI ... - jobs.meta (Migration in beiden db.py): Disc-Metadaten wandern in den Job — Quelle fuer Job-Detail-Popup (GET /jobs/{id}/detail), Ordner-Benennung, NFO. - medien.py (Worker, mit Tests): Zielordner 'Titel (Jahr)' statt Job-UUID; movie.nfo/tvshow.nfo (Kodi-Schema, kodi.wiki/view/NFO_files) + poster.jpg fuer jellyfin/emby/kodi; plex nur Benennung; Kollision -> Job-ID-Suffix. - notify.py (identisch in API+Worker, mit Tests): Webhook bei Job-Ende — Discord ({content}, discord.com/developers), Slack ({text}, api.slack.com/messaging/webhooks), ntfy (Rohtext + ?title=, docs.ntfy.sh), generisches JSON. Vorher war das Setting ein Placebo: nichts sendete je. POST /notifications/test beweist die Anbindung sofort. - mounts.py: NT_STATUS-Fehler -> handelbarer Klartext (ACCESS_DENIED ohne Credentials = Gast-Abfrage verweigert), Timeout-Meldung, mount-Hinweis bei error(13). Mit Tests. - tasks.py: Platz-Check per Disc-Groesse (ioctl BLKGETSIZE64) VOR dem Rip; Arbeitsverzeichnis workDir (unter /app/media, z.B. NAS) statt fix /app/temp/raw — 4K-UHD-Rohdaten (bis 100 GB) sprengen sonst die VM-Platte; MakeMKV-Key aus UI-Settings (~/.MakeMKV/settings.conf, Format wie entrypoint.sh) gilt ab dem naechsten Rip ohne Rebuild. - caps.py: Werkzeug-Versionen (MakeMKV aus ENV MAKEMKV_VERSION im Image, makemkvcon hat keinen --version-Schalter lt. usage.txt; HandBrakeCLI --version lt. handbrake.fr/docs) + Key-Quelle; workers.info-Spalte. - /browse liefert jetzt auch DATEIEN (Name + Groesse) — der 'leere' bluray-Ordner war voll, der Browser zeigte nur Unterordner. - GET /system/info: Versionen, Plattenplatz, Key-/Webhook-Status. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 08:55:22 +02:00
Hitonabi	b584cc29ad	Universal-Sprint: Wizard, UI-Mounts, Encoder-Erkennung, Task-Split, README ... Commander-Ziel: All-in-one, universell, weitergebbar. - First-Run-Wizard: startet automatisch bei neuer Installation (Keys, Verarbeitung, erkannte Hardware); /setup + /setup/complete - Data-Mounts via UI: Einstellungen -> Speicherziele haengt NFS/SMB direkt ein (mounts.py, CAP_SYS_ADMIN + rshared-Propagation, Auto-Remount beim Start, CIFS-Creds via Datei statt Kommandozeile); nfs-common/cifs-utils im api-Image - Encoder-Erkennung: jeder Worker meldet beim Start ehrlich seine Faehigkeiten (caps.py -> workers-Tabelle), GET /capabilities, Anzeige in Wizard + Verarbeitung-Tab - Task-Split: transcode_files als eigener Task auf Queue "transcode" (Basis fuer optionale Remote-GPU-Worker, deploy/remote-transcode-worker.yml EXPERIMENTELL) + POST /jobs/{id}/retry-transcode + UI-Knopf "Neu komprimieren" bei fehlgeschlagenen Jobs - API-Keys aus der DB: Settings-UI/Wizard ueberstimmen Env — vorher waren die Key-Felder im UI reine Dekoration (Clients lasen nur Env) - README komplett neu: generischer Schnellstart, Laufwerk-Override via docker-compose.override.yml, Architektur, Env-Tabelle Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>	2026-07-23 20:49:08 +02:00