Desktop-Anwendung zum gleichzeitigen Hochladen auf mehrere File-Hoster
eeec1d150c
Closing the app (especially during an active upload or on a hard kill) and reopening sometimes left already-uploaded files sitting in the queue as if still pending. Root cause is three layers stacked: 1. Persist-starvation: persistQueueStateSoon() reset a 10s debounce on every progress event, so during an upload the on-disk queue snapshot was never rewritten and stayed frozen at the pre-upload state (all jobs "preview"). 2. The beforeunload sync flush only covers a clean close; a hard kill / crash leaves that stale snapshot on disk. 3. Startup auto-dedup only dropped jobs with status "done". The completed files were stored as "preview" in the stale snapshot, so they survived and reappeared. Fix (mechanism-independent — holds whether the stale snapshot came from starvation, a mid-upload close race, or a hard kill): FIX A (core, durable): the upload log is the source of truth. Each persisted snapshot is now stamped with savedAt; on restart any restored job whose newest matching log entry is timestamped at/after floor(savedAt) is dropped regardless of status — it provably completed after the snapshot, so a "preview" row for it is a ghost. lib/queue-dedup.js gains an additive 3rd savedAt param; without savedAt or without log timestamps it behaves exactly as before (the 5 canary tests stay green, so intentional re-uploads of older files still survive). FIX B: new lib/throttle-timer.js with a max-wait. During uploads the snapshot is now written at most ~20s into a continuous progress burst instead of never; idle stays a pure debounce. The fallback shim honors max-wait too, so a missing library can never silently reintroduce the starvation. FIX C: the synchronous close-write retries renameSync on EBUSY/EPERM/EACCES and uses a pid-unique tmp (de-conflicts it from config-store._atomicWrite's fixed .tmp). A startup sweep reclaims orphaned <config>.<pid>.tmp files left by a hard kill between write and rename. lib/upload-log.js extracts formatUploadLogLine + parseUploadLogLine from main.js so the real writer -> reader -> gate seam is unit-tested (a future log-format or epoch-basis change can no longer pass green while breaking the fix). Verified: 334/334 tests green (incl. throttle fake-clock starvation/maxWait, ts-gate multi-hoster partial-completion, and the real-format seam tests), ESLint clean, smoke-boot identical to baseline, and an adversarial multi-agent review (15 findings, 14 refuted, 1 low — the tmp orphan, now swept) on the diff. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| assets | ||
| lib | ||
| renderer | ||
| scripts | ||
| tasks | ||
| tests | ||
| .gitignore | ||
| app.py | ||
| eslint.config.mjs | ||
| hosters.py | ||
| main.js | ||
| package-lock.json | ||
| package.json | ||
| preload-drop-target.js | ||
| preload.js | ||
| README.md | ||
| requirements.txt | ||
Multi-Hoster-Upload
Desktop-Anwendung zum gleichzeitigen Hochladen von Dateien auf mehrere File-Hosting-Dienste.
Unterstuetzte Hoster
- doodstream.com - API-Key basiert
- voe.sx - API-Key basiert
- vidmoly.me - Login basiert (Username/Passwort)
- byse.sx - API-Key basiert
Installation
Setup (empfohlen)
Lade die Multi-Hoster-Upload Setup X.X.X.exe aus den Releases herunter und installiere.
Portable
Lade die Multi-Hoster-Upload X.X.X.exe herunter. Keine Installation noetig.
Entwicklung
npm install
npm start
Build
npm run release:win
Erzeugt Setup + Portable EXE im release/ Ordner.
Release
GITEA_TOKEN=dein_token npm run release:gitea -- 1.0.1 "Release notes"
Features
- Drag & Drop oder Dateiauswahl
- Gleichzeitiger Upload zu mehreren Hostern
- Echtzeit-Fortschrittsanzeige
- Ergebnis-Tabelle mit Sortierung und Kopier-Funktion
- Upload-Verlauf (letzte 100 Eintraege)
- Health-Check fuer Hoster-Verbindungen
- Auto-Updater (prueft git.24-music.de)
- Log-Datei kompatibel mit File & Image Uploader Format