-
Multi-Hoster-Upload v3.3.108 Stable
Administrator released this
2026-06-27 19:55:45 +02:00 | 1 commits to master since this releasev3.3.108 — Session log filename: 6-digit uniqueness suffix
Session-mode log files now carry a generated 6-digit suffix, e.g.
26-06-2026-mdu-session-06-02-847581.log. Dropping seconds and the process id in
v3.3.107 reintroduced same-minute collision risk on a fast close/reopen; the random
suffix restores per-launch uniqueness without leaking the process id.Single-file and daily log modes are unchanged. 411 tests pass.
Downloads
-
Multi-Hoster-Upload v3.3.107 Stable
2026-06-26 06:57:52 +02:00 | 2 commits to master since this releasev3.3.107 — Session log filename
The per-session log file is renamed from
fileuploader-session-2026-06-26_06-02-36-10816.logto
DD-MM-YYYY-mdu-session-HH-MM.log(e.g.26-06-2026-mdu-session-06-02.log) — hour and minute only,
no seconds or process id. Single-file and daily log modes are unchanged.410 tests pass. No other behaviour changed.
Downloads
-
Multi-Hoster-Upload v3.3.106 Stable
2026-06-23 16:06:36 +02:00 | 3 commits to master since this releasev3.3.106 — Fix the intermittent white screen on startup (RemoteDesktop/VM) + export filename
Two things:
1. Intermittent white window on startup (the main fix). On a VM viewed over RemoteDesktop the app sometimes opened to a blank white window. A focused investigation pinned it precisely: the window's background colour is dark, so a "white" window can never be a still-loading or failed state — it can only mean the GPU/compositor failed to paint a surface, which is the classic intermittent-white-screen problem for Electron apps running over RemoteDesktop / in a VM (the virtual display adapter + hardware acceleration). The app had no GPU fallback configured.
Fix: when running in a RemoteDesktop session (or after a GPU process has ever crashed), the app now disables hardware acceleration and uses software rendering. The interface has no 3D/video/canvas content, so this costs nothing visible and removes the white-screen failure entirely. Local/desktop users keep hardware acceleration. It also self-heals: if a GPU crash is ever detected, the next launch automatically switches to software rendering.
If it ever happens again, the startup log now records the exact GPU event so the cause can be confirmed.
2. Backup export filename changed to
DD-MM-YYYY-multihoster-backup.mhu(e.g.23-06-2026-multihoster-backup.mhu).409 tests pass. No upload behaviour changed.
Downloads
-
Multi-Hoster-Upload v3.3.105 Stable
2026-06-22 03:54:30 +02:00 | 4 commits to master since this releasev3.3.105 — Data-safety: a crash can no longer wipe your accounts
A server that crashed hard during an upload lost its configured accounts. This was not the update (a second server updated to v3.3.104 and kept everything) — it was a durability gap exposed by the crash, now closed.
What was wrong:
- The config was saved atomically (write temp + rename) but never flushed to disk (no fsync), so a hard crash could leave electron-config.json truncated.
- On the next start the app read the truncated file, fell back to the backup, and if that was also bad it loaded empty defaults — and the next automatic settings/queue save then wrote those empty accounts over the real ones.
What this release changes (no change to normal behavior):
- Config writes are now flushed to disk (fsync) before the rename, on both the normal save path and the on-close save — a hard crash can no longer leave a truncated config.
- The backup file is only refreshed from a non-empty live config, so a truncated config can never overwrite a good backup.
- A wipe-guard: any save that is not explicitly changing accounts will refuse to persist empty accounts — it restores them from the most recent backup (live → .bak → the permanent pre-split snapshot) instead. Deleting all accounts on purpose still works.
- Config loading gained an extra fallback to the permanent pre-split snapshot, so it can recover accounts even if both the live file and the regular backup are damaged.
If a server already lost its accounts: with the app closed, copy
%APPDATA%\multi-hoster-uploader\electron-config.json.pre-history-split.bak (or electron-config.json.bak)
over electron-config.json — that backup still holds the accounts.409 tests pass.
Downloads
-
Multi-Hoster-Upload v3.3.104 Stable
2026-06-22 03:16:59 +02:00 | 5 commits to master since this releasev3.3.104 — The "Recent uploads" panel is now instant too (virtualized)
The v3.3.103 log (a real 2464-file batch across 4 hosters, ramping to 95 simultaneous uploads) confirmed the previous fixes held beautifully: the whole 90-second ramp ran with the main thread essentially free (~11ms), 32 fps, zero jank. The one remaining rough edge was switching tabs while that heavy upload was running.
The cause was the last large list still rendering every row into the page at once: the Recent-uploads panel built up to 2000 rows in the DOM, so switching to it had to lay out all of them (~200ms on the remote-desktop VM).
Fix: the Recent-uploads panel is now virtualized, exactly like the upload queue and the History view already are — only the ~40 rows actually on screen exist in the DOM, scrolling renders the next window. Selection (including ctrl/shift-select), sorting, and live updates as new uploads complete all keep working; nothing is hidden or capped.
Verified on the real DOM at 2000 rows: showing the panel dropped from ~118ms to ~2ms, the DOM stays at ~40 rows regardless of total, scrolling lands on the right rows, the scrollbar is correct, and a selected row off-screen still shows as selected when scrolled back into view.
Every large table in the app (Queue, History, Recent) is now virtualized. 407 tests pass. No upload behavior changed.
Downloads
-
Multi-Hoster-Upload v3.3.103 Stable
2026-06-21 20:54:55 +02:00 | 6 commits to master since this releasev3.3.103 — Smooth batch start: the file-size checks no longer freeze the main thread
The v3.3.102 log confirmed the big wins held: the History view is instant and steady-state uploads are pristine (32 fps, event-loop ~12ms). The one remaining rough spot was the first few seconds after a large batch starts — the main thread froze for ~336ms and the UI janked briefly, then settled.
A multi-agent investigation (with an adversarial review that caught and rejected a tempting-but-wrong fix that would have reintroduced an old queue-persistence bug) traced it to the real cause: when a batch starts, the app checked every file's size with a synchronous
fs.statSync— up to 200 of them in a single tick (~336ms of blocking I/O on the VM), made worse by the disk already being busy with the 1MB read-ahead.Fix: those file-size checks now run asynchronously on a background thread pool, in parallel, so the main thread never blocks on them. Same data, same behavior — just off the UI thread. The 336ms freeze at batch start drops to zero; the brief UI jank and the inherited tab-click lag during spin-up should go with it.
407 tests pass. No upload behavior changed.
Downloads
-
Multi-Hoster-Upload v3.3.102 Stable
2026-06-21 20:05:07 +02:00 | 7 commits to master since this releasev3.3.102 — History tab is now instant on every open (virtualized)
v3.3.101 stopped the History tab from re-parsing the whole 30000-entry file on every switch. This build removes the remaining cost: the layout of the History table itself.
The History table rendered up to 2000 rows into the DOM at once, so making the view visible forced the browser to lay out all 2000 rows (~200ms on the remote-desktop VM) — the residual tab-switch lag, even when no reload happened.
Fix: the History table is now virtualized, exactly like the upload queue already is. Only the rows actually on screen (~40) are in the DOM; scrolling renders the next window. The full history stays completely scrollable — nothing is hidden or capped away — but the view now opens essentially instantly.
Measured on the real DOM (with a stress test of 6000 rows): showing the History view dropped from ~118ms to ~1ms, the DOM stays at ~40 rows regardless of total size, scrolling maps to the correct rows, and the columns stay stable. Verified end-to-end.
407 tests pass. No upload behavior changed.
Downloads
-
Multi-Hoster-Upload v3.3.101 Stable
2026-06-21 19:46:49 +02:00 | 8 commits to master since this releasev3.3.101 — History tab is instant again + a diagnostics history fix
The v3.3.100 interaction instrument pinpointed the last residual UI lag exactly: every slow click was a switch into the History view (200–840 ms), each one parsing the entire 30000-entry history file on the main thread and re-flattening it in the renderer. Uploads themselves were already pristine.
Fixes:
- History tab no longer reloads unconditionally. It already tracked a "dirty" flag but never checked it, so every visit re-read and re-parsed the whole ~185 MB history file. Now it only reloads when there is actually new history (a completed batch) or on the first visit. Result: repeat History tab switches with no new uploads are instant. (The first open right after a new upload batch still parses the file once; making that instant too is a planned follow-up.)
- Diagnostics history regression fixed. Since the v3.3.99 history split, remote diagnostics reported 0 history batches in packaged builds even though the full history was intact on disk. The diagnostics now read the real history file.
407 tests pass. No upload behavior changed.
Downloads
-
Multi-Hoster-Upload v3.3.100 Stable
2026-06-21 19:22:38 +02:00 | 9 commits to master since this releasev3.3.100 — Complete the diagnostics: measure every UI interaction (switches, sorts, tabs, buttons)
Following the v3.3.99 fix that eliminated the main-thread config thrash, this build closes the last measurement gap so that every action names itself in the log if it is ever slow — not just the ones that cross into the main process.
What was already covered: every IPC handler is timed (button → main-process latency), a main-thread long-task monitor logs any block over 100 ms with its trigger, and config load/serialize are timed. Account switches were already covered too — the switch itself is a trivial in-memory operation and the rotation work is asynchronous, so it cannot block.
What this adds (renderer side, additive, only logs when slow):
- Interaction timing (Event Timing API): every UI interaction whose latency exceeds 50 ms is logged as
renderer-interaction <type> dur=Xms proc=Yms target=<element>— always on, whether idle or under load — and names the element (id / class / data-action / label). This is the direct click-to-reaction latency. - Idle long-task logging: any renderer long task over 100 ms is logged immediately (
renderer-longtask dur=Xms), no longer only during uploads.
Set
MHU_PERF=0to silence the main-process probes. No functional/upload behavior changed.Downloads
- Interaction timing (Event Timing API): every UI interaction whose latency exceeds 50 ms is logged as
-
Multi-Hoster-Upload v3.3.99 Stable
2026-06-21 18:38:21 +02:00 | 10 commits to master since this releasev3.3.99 — The real fix: history split out of the hot config file (kills the 1-2s button lag)
The previous build's instrumentation finally named the true cause of the UI lag, and it was none of the read-path suspects.
electron-config.jsonhad grown to 38.5 MB and was being loaded / structuredCloned / JSON.stringified ~137 times in a 73-second window (140–592 ms each) on the main thread — roughly 47% main-thread occupancy. A button click landing while the thread is mid-clone of a 38.5 MB object is exactly the 1–2 s delay.The bulk was history, not the queue: every completed batch appended the full per-file result list (per-hoster URLs) into the config, and the default retention never prunes it, so it grew without bound.
Fix — history now lives in its own
electron-history.jsonand is never parsed, cloned or serialized during normal operation:- One-time, fail-safe migration at startup: the history file is written, fsync'd and verified before the config is ever allowed to drop its history, and a permanent
electron-config.json.pre-history-split.bakis kept. Your existing history is never the sole copy and is fully preserved. - After migration the config file shrinks from tens of MB to a few KB, so every config read/write becomes sub-millisecond. Validated against a real 185 MB / 30000-entry fixture: all entries preserved, load time 631 ms → 0.1 ms.
Comprehensive instrumentation (additive, set
MHU_PERF=0to disable): every IPC handler now logs its wall-time when slow (the button-press latency), a main-process long-task monitor logs any main-thread turn over 100 ms with context, and the config-store perf lines gained caller attribution. This makes any remaining stall name itself directly.405 tests pass (9 new migration tests). No upload behavior changed.
Downloads
- One-time, fail-safe migration at startup: the history file is written, fsync'd and verified before the config is ever allowed to drop its history, and a permanent