main.js

@@ -1092,9 +1092,7 @@ ipcMain.handle('start-upload', (_event, payload) => {
   const hosters = payload && Array.isArray(payload.hosters) ? payload.hosters : [];
   const jobs = payload && Array.isArray(payload.jobs) ? payload.jobs : [];
 
-  // At 500+ jobs JSON.stringify blew up the debug log with MB-sized lines
-  // per start-upload and added noticeable delay — log counts only.
-  debugLog(`start-upload: files=${files.length}, hosters=${hosters.length}, jobs=${jobs.length}`);
+  debugLog(`start-upload: files=${JSON.stringify(files)}, hosters=${JSON.stringify(hosters)}, jobs=${jobs.length}`);
 
   const tasks = jobs.length > 0
     ? buildUploadTasksFromJobs(config, jobs)

package.json

@@ -1,6 +1,6 @@
 {
   "name": "multi-hoster-uploader",
-  "version": "3.1.6",
+  "version": "3.1.5",
   "description": "Upload files to doodstream, voe, vidmoly, byse simultaneously",
   "main": "main.js",
   "scripts": {

tasks/todo.md

@@ -1,32 +1,28 @@
-# Perf/Stabilität Audit (nach 3.1.5)
+# Account-Rotation: vollständiger Session-Lernprozess
 
-Ziel: bekannte Schwachstellen aus der Review abarbeiten, jeweils mit eigenem Release.
+## Problem
+1. Byse "disk space full" wurde als file-rejected klassifiziert → keine Rotation. (3.1.4 ✓)
+2. `pre-job-swap` checkte `_failedAccounts` VOR Semaphore-Acquire → alle parallelen Jobs probierten weiter den vollen Account. (3.1.5 ✓)
+3. Wenn beim ersten Fail noch kein Fallback-Account existierte und der User DANACH einen hinzufügt → `_accountOverrides` blieb leer, keine weitere `account-failed`-Emission (nur einmalig pro Account) → System blieb stuck bis zum Neustart. (3.1.5 ✓)
 
-## Schritt 1 — Log-Geschwätz reduzieren (main.js:1066)
-- [ ] `JSON.stringify(files/hosters)` durch count-only ersetzen
-- [ ] Bei 500 Jobs spart's MB-große debugLog-Einträge pro start-upload
-- [ ] Release als 3.1.6
+## Fix
+- [x] `lib/upload-manager.js` — Pre-Job-Swap hinter `semaphore.acquire` verschoben, plus zwei public getter: `getFailedAccountKeys()`, `getOverride(hoster)`.
+- [x] `main.js` — `save-config` IPC-Handler ruft nach dem Speichern `getNextFallbackAccount` für alle failed-ohne-Override accounts im aktiven UploadManager. Findet er was, ruft er `switchAccount`. Emittiert `account-switched` an den Renderer.
+- [x] Tests (4 neue):
+  - pre-job-swap greift für parallele Worker nach Semaphore-Queue.
+  - getFailedAccountKeys + getOverride als public API.
+  - Neustart-Reset: fresh Manager hat keine gelernte failed-Historie.
+  - Late-resolved Override wird von Folgejobs genutzt (mid-batch config add).
+- [x] `npm test` — 80/80 grün.
+- [ ] Release als 3.1.5 (auf User-OK).
 
-## Schritt 2 — persistQueueState-Write vermessen + drosseln
-- [ ] Verstehen: wie groß ist das JSON bei 500 Jobs? Wie oft schreibt's während eines Batches?
-- [ ] Ggf. maximale Write-Größe / Frequenz während Upload erhöhen (derzeit 10s bei uploading, 500ms sonst)
-- [ ] Ggf. nur bei Status-Änderung, nicht bei Progress-Byte-Change
-- [ ] Release als 3.1.7 (nur wenn echter Bottleneck gefunden)
+## Behavior-Matrix
+| Szenario | Verhalten |
+|---|---|
+| acc1 + acc2 gleich aktiv, acc1 wird voll | acc1→acc2 Rotation, alle weiteren Jobs direkt acc2 ✓ |
+| Nur acc1 aktiv, acc2 mid-batch hinzugefügt BEVOR acc1 voll | Erster Fail resolved gegen frische Config, acc2 wird gezogen ✓ |
+| Nur acc1 aktiv, acc1 wird voll, DANACH acc2 hinzugefügt | `save-config` trigert Late-Resolve, `switchAccount(acc2)` wird aufgerufen, Folgejobs swappen pre-job ✓ |
+| App-Neustart | `_failedAccounts` in-memory → fresh, acc1 wird wieder probiert ✓ |
 
-## Schritt 3 — Progress-Event-Flood drosseln (app.js:1862-1871)
-- [ ] Status-Change-Events rufen sync `updateQueueActionButtons + updateStatusBar + updateStatsPanel`
-- [ ] Bei 50+ parallelen Uploads → 100+ sync Callbacks/Sek
-- [ ] Coalesce via rAF (wie `scheduleQueueRender` für uploading-events)
-- [ ] Tests für den neuen Pfad
-- [ ] Release als 3.1.8
-
-## Schritt 4 — Byse-Poller-Review (lib/hosters.js:440+)
-- [ ] Verstehen warum der Poller existiert (zuverlässigkeitsproblem mit direkter Response?)
-- [ ] Edge-Cases prüfen: was wenn Poll 0 neue Files findet aber Upload durch war?
-- [ ] Dokumentieren was funktioniert und was nicht
-- [ ] Kein Release außer echter Bug gefunden
-
-## Offen nach diesen Schritten
-- Memory-Wachstum bei langen Sessions (bräuchte Instrumentierung)
-- Throughput-Skaling bei 20+ parallelen Uploads (bräuchte Lasttest)
-- Netz-Ausfall-Recovery (bräuchte Netz-Interrupt-Test)
+## Review
+Drei Ebenen zusammen (3.1.4 Classifier + 3.1.5 pre-swap-after-queue + 3.1.5 late-resolve) machen das Session-Lernen komplett: disk-space-voll wird erkannt, markiert, alle wartenden Jobs sehen es wenn sie dran sind, und spätere Config-Änderungen werden reaktiv aufgegriffen.