package.json

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

renderer/app.js

@@ -1982,12 +1982,12 @@ async function retrySelectedJobs() {
   });
   if (retryJobs.length === 0) return;
 
-  // Select the retry jobs and start them immediately.
+  // Select the retry jobs and start them immediately
-  // No renderQueueTable / updateQueueActionButtons / updateStatusBar here:
-  // startSelectedUpload() runs the exact same trio right after, and at 500+
-  // jobs the double render freezes the UI for multiple seconds.
   selectedJobIds.clear();
   retryJobs.forEach(j => selectedJobIds.add(j.id));
+  renderQueueTable();
+  updateQueueActionButtons();
+  updateStatusBar();
   persistQueueStateSoon();
   await startSelectedUpload();
 }

tasks/lessons.md

@@ -1,12 +0,0 @@
-# Lessons
-
-## 2026-04-21 — DOM-Doppelrender bei Bulk-State-Changes
-**Symptom:** User klickt auf "Erneut versuchen" mit 500+ Jobs → App hängt sekundenlang.
-**Root cause:** `retrySelectedJobs()` ruft `renderQueueTable + updateQueueActionButtons + updateStatusBar` auf, `startSelectedUpload()` ruft direkt danach genau dieselben Funktionen nochmal auf.
-**Regel:** Wenn ein Click-Handler `await anotherHandler()` aufruft und der innere Handler seinen eigenen kompletten Render-Zyklus hat, NIEMALS noch einen davor. Einmal ist genug — der folgende innere Render sieht die frischen State-Mutationen ohnehin.
-**Wie anwenden:** Vor jeder `await fn()`-Folge in einem Handler prüfen: macht `fn` schon `renderQueueTable()`? Wenn ja, äußere Render-Calls löschen.
-
-## 2026-04-21 — Keine fake Build-ETAs
-**Symptom:** User wartet 5+ min auf Tauri-Build den ich mit "1-2min" angekündigt habe.
-**Regel:** Tauri-Release-Builds brauchen real 3-6 min (Rust + NSIS + MSI). Keine Zeitangabe oder ehrlich "kann 3-6min dauern" schreiben.
-**Wie anwenden:** Wenn User nach Status fragt: sofort `tail` des Logs + `ls` des Bundle-Ordners zitieren, nicht raten.

tasks/todo.md

@@ -1,22 +0,0 @@
-# Retry-Hang bei 500-600 failed jobs
-
-## Problem
-User hat 500-600 Uploads, davon viele `error`. Markiert alle, klickt "Erneut versuchen" → App friert mehrere Sekunden ein.
-
-## Root Cause (renderer/app.js)
-`retrySelectedJobs()` (Z.1952) → mutiert 500 Jobs → `renderQueueTable() + updateQueueActionButtons() + updateStatusBar()` (Z.1988-1990) → dann `await startSelectedUpload()` (Z.1992) → das mutiert SIE ERNEUT (Z.1724-1732) → rendert NOCHMAL (Z.1733-1735).
-
-**Doppelter DOM-Zyklus + doppelte Mutation bei 500 Jobs = hängt-Gefühl.**
-
-Zusätzlicher Multiplikator: main.js:1066 `JSON.stringify(files)` in `debugLog` — auch wenn `files` leer ist. Außerdem `buildUploadTasksFromJobs` loopt synchron 500x im main-Thread.
-
-## Plan
-- [x] Entferne doppelten Render in `retrySelectedJobs` — `startSelectedUpload` macht das ohnehin in einem Rutsch.
-- [x] Lesson dokumentieren in `tasks/lessons.md`.
-- [ ] (optional, später) main.js:1066 — debugLog nicht mit JSON.stringify(files/hosters), nur counts loggen.
-- [ ] (optional, später) Progress-Event-Flood während laufendem Upload: batch via rAF statt sync updateQueueActionButtons+updateStatusBar+updateStatsPanel.
-
-## Review
-Fix entfernt eine komplette Render-Pass-Runde vor dem Aufruf von `startSelectedUpload`. Bei 500+ Jobs halbiert das die Sync-Work im Click-Handler (Sort, Virtual-Render, Button-Update, StatusBar-Update). `selectedJobIds` bleibt korrekt befüllt weil die Selektion VOR `startSelectedUpload` gesetzt wird. `persistQueueStateSoon` ist debounced, deshalb kein Zusammenspielproblem.
-
-Funktional identisch: Die Jobs durchlaufen am Ende dieselbe State-Kaskade (reset → queued → getting-server → uploading), nur mit einem statt zwei Render-Zyklen dazwischen.