Desktop-Anwendung zum gleichzeitigen Hochladen auf mehrere File-Hoster
8fed8669f3
(A) Intermittent pure-white startup window. On a Windows VM viewed over RemoteDesktop the app sometimes opened to a blank white window — no error banner, not even the static menu bar. A multi-agent investigation + adversarial review pinned it by one airtight deduction: the BrowserWindow is created with backgroundColor '#16181c' (dark), so "white" can never be an un-painted, loading, or failed state — all of those show dark. Pure white, with no banner and no static menu bar, and silent in the logs, eliminates every DOM/init/CSS/load failure mode (each would leave the dark styled shell, unstyled black-on-white menu text, or the red init().catch banner) and leaves exactly one: a GPU/compositor surface failure on the RDP virtual display adapter. The code ran hardware acceleration full-default with no fallback (no disableHardwareAcceleration, no GPU switch anywhere), and the GPU child-process-gone handler is log-only — matching the silent symptom. Fix (the reviewed safe subset): - app.disableHardwareAcceleration() at module top (before app.whenReady), gated on an RDP session (process.env.SESSIONNAME matches /^RDP/) OR a persisted gpu-disabled.flag in userData. The renderer has no WebGL/canvas/video, so software compositing costs effectively nothing here and does not undo the recent renderer perf work; local/console users keep hardware acceleration. - Auto-heal: when a GPU child-process-gone fires, write gpu-disabled.flag so the next launch disables acceleration even if the RDP gate didn't match (covers a VM reached via console or a flaky virtual GPU). Self-heals after at most one white screen. - The existing child-process-gone / render-process-gone / did-fail-load logging is kept so the affected server's next white-start log can confirm the cause (CHILD PROCESS GONE type=GPU). A webContents reload would not disrupt uploads (uploadManager lives in the main process and is torn down only on quit), but no watchdog is added because in this GPU mode init completes — an init-complete signal would not detect the blank surface. (B) Backup export default filename changed from multi-hoster-backup-YYYY-MM-DD.mhu to DD-MM-YYYY-multihoster-backup.mhu. 409 tests pass; clean boot (the guard is inert off-RDP). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|---|---|---|
| assets | ||
| docs | ||
| gateway | ||
| 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