Administrator/real-debrid-downloader
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 512 Wiki Activity
f1e35f5f41
real-debrid-downloader/tasks/entscheidungen-offen.md
Sucukdeluxe f1e35f5f41 Fix: Mega "bis Tagesreset gesperrt" parkt das Paket bis zum Reset statt es den ganzen Tag alle 2 min neu zu versuchen 
Wenn ALLE Mega-Debrid-Accounts wegen wiederholt leerer/Server-loser Antworten
bis zum Tagesreset geparkt waren (in-memory untilRestart-Park aus Runde 3),
warf unrestrictWithAccounts einen reinen Klartext-Fehler ohne Maschinen-Token.
Im Manager-Catch fiel dieser durch parseMegaDebridCooldownRetry (kein
mega_debrid_cooldown:-Praefix) und isMegaDebridTransientResolveFailure und
landete im generischen isUnrestrictFailure-Zweig — nur weil der Text
"mega-debrid" enthaelt. Folge: das Item wurde den ganzen Tag etwa alle zwei
Minuten neu versucht (120s-Cap) und fuetterte dabei recordProviderFailure den
Provider-Circuit-Breaker, statt einmal bis zum Tagesreset zu parken. Bei
Standard-Einstellungen (retryLimit=0=unendlich) heilte es sich zwar um
Mitternacht selbst (kein Stranding), war aber unnoetige Log-Flut und Churn und
unterlief genau die untilRestart-Park-Absicht aus Runde 3.

Cross-Layer-Synthese-Pass (adversarisch verifiziert) hat parallel die
Advisor-Hypothese eines Key-Mismatch (Manager cool't aufgeloesten
"megadebrid-api", Fallback-Suche liest rohen "megadebrid") WIDERLEGT:
normalizeProviderOrder speichert immer den aufgeloesten Key, also faellt
Write/Check/Clear/Read auf denselben Key — der Routing-Fix (986fbab) ist fuer
den Mega-Fall nachweislich sicher.

Fix (konservativ, spiegelt den bereits korrekten mega_debrid_cooldown-Zweig):
- debrid.ts emittiert beim untilRestart-Park jetzt den Token
  mega_debrid_reset_park:<msBisReset>: (Delay aus megaDebridDailyParkExpiry,
  deckt sich exakt mit dem in-memory Park-Ablauf).
- download-manager.ts: neue reine parseMegaDebridResetPark (kein 15min-Clamp,
  26h-Cap) + Catch-Branch VOR der Cooldown-Klassifikation, der bis zum
  Tagesreset queued OHNE recordProviderFailure (ein geplanter Park ist kein
  Provider-Fehler).
- Token enthaelt weiter "mega_debrid" → jeder Fall-through landet schlimmstenfalls
  im heutigen Verhalten (sichere Untergrenze).

Tests: 5 neue (parseMegaDebridResetPark: parst/embedded/kein-15min-Clamp/Cap+Junk,
plus cooldown-Parser ignoriert den neuen Token) + die all-parked debrid-Assertion
prueft jetzt den Token. Volle Suite 881 gruen, tsc unveraendert.
2026-06-17 10:16:16 +02:00

4.7 KiB
Raw Blame History

Offene Entscheidungen für dich (Audit-Loop 2026-06-17)

Diese zwei Punkte habe ich BEWUSST nicht autonom „gefixt", weil jede Lösung einen Produkt-/Geschmacks-Kompromiss enthält, den du entscheiden solltest, nicht ich. Beide sind verifiziert (Code-Zitat + Szenario), nur die Richtung ist deine Wahl.

1. Failover-Kappung durch globalen 60-Sekunden-Timeout (HIGH)

Was passiert (belegt): download-manager.ts baut EINEN Timeout fürs gesamte Unrestrict:

const unrestrictTimeoutSignal = AbortSignal.timeout(getUnrestrictTimeoutMs());   // 60s
const unrestrictedSignal = AbortSignal.any([active.abortController.signal, unrestrictTimeoutSignal]);

Dieses EINE Signal geht an die komplette Provider-Kette in debrid.ts. Die 60s sind also ein Budget für ALLE Provider zusammen, nicht pro Provider. Wenn Provider 1 (z.B. Mega-Web mit Account-Queue) das Budget verbraucht, dann sieht Provider 2 ein bereits abgelaufenes Signal → debrid.ts wertet den Abbruch als „kein Failover" und wirft, ohne Provider 2 echt zu versuchen.

Aktuell weitgehend latent: Seit v1.7.214 wird die API zuerst probiert (schneller Pfad), Mega-Web ist nur noch Fallback. Das Szenario „langsamer Provider 1 hungert Provider 2 aus" trifft in der Produktion derzeit selten. Deshalb dokumentiert statt dringend gefixt.

Deine Entscheidung — zwei Richtungen (gleiche Spannung, andere Seite):

  • A) Pro-Provider-Timeout: Jeder Provider bekommt sein eigenes frisches Budget. Failover bekommt IMMER einen echten Versuch. Kosten: Worst-Case-Wartezeit pro Item steigt. Das Budget ist dabei ein DREHregler, kein fixer Wert: 60s/Provider = bis 180s Worst-Case (3 Provider), 30s/Provider = bis 90s usw. Du akzeptierst langsameres Worst-Case-pro-Item für vollständigeres Failover — und stellst über den Pro-Provider-Wert ein, wie viel langsamer.

  • B) Globales Budget behalten, aber Slice für Failover reservieren: Provider 1 wird auf z.B. 35s gedeckelt, damit garantiert Zeit für Provider 2 bleibt. Kosten: Ein legitim langsamer Provider 1 (Mega-Web-Account-Queue bis ~90s) wird früher abgeschnitten → mehr Failover, auch wenn Provider 1 noch erfolgreich gewesen wäre.

Kernfrage, die nur du beantworten kannst: Wie lange darf ein Item bei einem langsamen aber funktionierenden Provider hängen, bevor wir ihn zugunsten des nächsten aufgeben?

2. Gespiegelter Mega API/Web-Schalter (HIGH, in Runde 3 als 2/3 bestätigt)

Was passiert (belegt): Die Mega-Debrid API- und Web-Account-Zeilen teilen sich EINE login-only Enable-Flag (hasMegaDebridCredentials gilt für beide; die Pro-Modus-Auswahl läuft über isMegaDebridModeEnabled(settings, "api"|"web")). Dein Report: „API ausschalten schaltet Web an" — weil der Schalter sich spiegelt.

Warum ich es NICHT autonom geändert habe:

  • Daten-Modell-Fix (echte unabhängige Flags) braucht eine Settings-Migration, die deaktivierte Accounts versehentlich re-aktivieren könnte.
  • Die saubere UI-Variante (zwei echte unabhängige Schalter) ist ein Layout-Redesign — und du bist UI-Geschmack-sensibel; das will ich nicht ungefragt umbauen.

Deine Entscheidung: Ein gemeinsamer Schalter (API+Web zusammen an/aus, klar beschriftet) ODER zwei unabhängige Pro-Modus-Schalter (mehr Kontrolle, aber UI + Migration nötig)?

Erledigt in dieser Runde (zur Info, kein Handlungsbedarf)

  • Mega „bis Tagesreset gesperrt" parkt jetzt wirklich (statt alle 2 min neu zu versuchen): Wenn ALLE Mega-Accounts wegen wiederholt leerer Antworten bis zum Tagesreset geparkt waren, hat das Tool den Fehler bisher als normalen Umwandlungsfehler behandelt und den ganzen Tag alle ~2 Minuten neu probiert (und dabei den Provider-Circuit-Breaker mit Fehlern vollgemüllt). Jetzt erkennt es den Park und legt das Paket EINMAL bis zum Tagesreset schlafen — genau das, was der „bis Tagesreset"-Park eigentlich erreichen sollte. Bei Standard-Einstellungen heilte sich das vorher schon um Mitternacht selbst (kein Datenverlust), war aber unnötige Log-Flut und Churn. Rot-bewiesener Test.

  • MED Failover-Routing: Wenn ein Provider in den Manager-Cooldown läuft (≥20 Fehler in Folge) und auto-Fallback an ist, hat der Manager bisher zwar einen Ersatz-Provider berechnet, ihn aber WEGGEWORFEN — die Kette führte trotzdem wieder mit dem ausgebremsten Provider an. Jetzt wird der Ersatz-Provider als „Lead" durchgereicht und die Kette führt mit ihm an, OHNE einen Provider zu verlieren (der ausgebremste bleibt als letzter Notnagel in der Kette). Greift nur, wenn der Provider bereits nachweislich degradiert ist → strikt-besser-wenn-aktiv, kein Timeout/Cancel-Vertrag berührt. Rot-bewiesener Test. (Hält für Roll-up-Release bereit.)