Symptom (User): 4 Accounts hinterlegt, aber die Rotation nutzte nur die
Accounts 1-3 — der 4. wurde nie angefasst, ausser man deaktivierte die
anderen manuell.
Ursache (im Live-Log des Servers belegt, rd_downloader.log): Die
Account-Schleife in unrestrictWithAccounts startete bei JEDER
Link-Aufloesung bei Account 1 und nahm den ersten brauchbaren
(First-Usable-Wins-Failover). Ein spaeterer Account kam nur dran, wenn
ALLE davor am Tageslimit/Cooldown/deaktiviert waren. Live-Verteilung:
Account 1 = 749 OK + 1314x "Tageslimit — bis Neustart gesperrt",
Account 2 = 1733 OK + 448x Tageslimit-Sperre, Account 3 = 1603 OK ohne
ein einziges Limit — die Kette endete deshalb IMMER spaetestens bei
Account 3, und Account 4 tauchte im gesamten Log mit keinem einzigen
Event auf (nicht getestet, nicht geskippt). Accounts 1-2 liefen also
staendig ins Tageslimit, waehrend die Kapazitaet von Account 4 jeden
Tag verfiel.
Fix: Round-Robin-Cursor in unrestrictWithAccounts. Jede Aufloesung
startet beim Account NACH dem zuletzt getesteten (Modulo ueber die
Liste), alle bestehenden Checks (deaktiviert, lokales Tageslimit,
Cooldown, Park-bis-Neustart) bleiben unveraendert und werden in der
neuen Reihenfolge durchlaufen. Damit verteilen sich Links gleichmaessig
ueber alle Accounts, kein Account wird mehr stumpf bis ans Limit
gehaemmert, und Account 4 nimmt automatisch teil. Der Cursor ist
Modul-State (bei App-Neustart wieder Account 1), die "naechster
Account"-Vorschau im Fehlerpfad folgt der Modulo-Reihenfolge, und
resetMegaDebridRuntimeStateForTests setzt ihn fuer deterministische
Tests zurueck. Die Debrid-Link-Key-Rotation (separate Schleife) bleibt
unveraendert First-Wins — dort ist kein Account konfiguriert; bei
Bedarf gleiches Muster nachziehen.
Nebenfix: Das Support-Bundle exportiert jetzt auch
logs/account-rotation.log (+ .old) — genau dieses Log fehlte im Bundle
und haette die Diagnose sofort geliefert (die Datei kollidiert
namentlich mit dem gleichnamigen Log des Multi-Hoster-Uploaders, daher
war zunaechst das falsche Log in der Analyse).
Tests: 2 neue Regressionstests (5 Links auf 4 Accounts -> 1,2,3,4,1;
Cooldown-Account wird in der Reihe uebersprungen), Suite 806 gruen,
tsc=6 Baseline, self-check + build ok.
- Electron crash handlers (render-process-gone, child-process-gone,
unresponsive/responsive, process warnings) with a circuit-breaker
auto-reload for renderer crashes
- Renderer error capture (window.onerror, unhandledrejection, React
ErrorBoundary) forwarded to the main log via a one-way IPC channel
- Memory-pressure heartbeat measured against the V8 heap_size_limit
- Gated DEBUG log level (RD_DEBUG) and an in-memory ring of recent
WARN/ERROR lines, exposed via the /errors endpoint and support bundle
- Disk-error classification (ENOSPC etc.) on download failures and
integrity-check pass/fail logging
Strip every comment from the source (parsed with the TypeScript compiler so
strings, template literals, regex literals and JSX are never touched), and drop
internal/working artifacts that do not belong in the public repository
(design mockups, internal analysis docs, a stray backup file and an old log).
No functional change: build is green, the full test suite passes.
User-Goal: bei kuenftigen Renaming-Problemen eine vollstaendige, sofort auffindbare Uebersicht —
JEDER Umbenenn-/Verschiebevorgang protokolliert UND danach verifiziert (liegt die Datei wirklich
unter dem Zielnamen? Quelle weg? richtige Schreibweise?).
- NEU desktop-rename-log.ts: pro Sitzung <Desktop>/Downloader-Log/rename-session_<ts>.txt; Ordner
selbstheilend (mkdir recursive vor jedem Write -> auch nach Loeschung zur Laufzeit sofort wieder
da). Synchroner Append, Schreibfehler verschluckt (bricht nie einen Download).
- verifyRename (sync) + verifyRenameAsync (Hot-Path): prueft Ziel-Existenz, echten On-Disk-Namen
(case-genau via readdir), Quell-Abwesenheit; Level INFO/WARN/ERROR. Nutzt denselben \?\-Long-
Path-Prefix wie der echte Rename (sonst falsche Urteile auf langen Scene-Pfaden).
- download-manager: renamePathWithExdevFallback = verifizierter Wrapper um die unveraenderte
Raw-Logik (deckt alle Media-Renames ab) + 3 Sync-Sites (startup-Dedup, Deobfuskation, Suffix-Fix)
via logVerifiedRenameSync; logRenameProcess spiegelt ins Desktop-Log.
- app-controller init/shutdown (getPath("desktop") gegen Startup-Crash abgesichert); support-bundle
packt das Log mit ein.
Adversarialer Review-Workflow (4 Linsen) fand + behoben: Long-Path-Verify-Bug (falsches OK
maskiert halb-fertigen Move), readdir-Fehler-False-OK, sync-I/O im Hot-Path, getPath-Guard,
Test-Temp-Cleanup. tsc 9 (Baseline), 663 Tests (+7 neue), Build gruen.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Das Bundle packte bisher alle logs-Unterordner rekursiv (addDirectoryIfExists)
→ tausende Per-Item-Logs → 200+ MB (User-Bundle: 4273 Item-Logs, 214 MB).
Zum Verschicken/Analysieren unhandlich.
Neue addRecentDirectoryFiles(): packt nur Dateien mit mtime in den letzten
8h. Package-Logs und Item-Logs nutzen das 8h-Fenster; Session-Logs (wenige
Dateien) weiterhin komplett. Haupt-Logs (rd_downloader.log, rename.log,
audit.log, session.log, trace.log) waren schon per addFileIfExists einzeln
gepackt und bleiben unveraendert. Live-Logs der aktiven Queue (laufende
Session) ebenfalls komplett.
Ergebnis: Bundle enthaelt alles fuer aktuelle Fehler + Rename-Probleme,
aber kein Bloat durch tausende alte Item-Logs.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
