-
Multi-Hoster-Upload v3.3.68 Stable
Administrator released this
2026-06-15 00:47:09 +02:00 | 94 commits to master since this releaseNew top menu bar (Datei / Einstellungen / Hilfe) matching the Real-Debrid Downloader look. Datei: add files/folder, backup export/import, restart, quit. Einstellungen: open the settings tab plus inline live controls for max parallel uploads and the speed limit (MB/s), synced with the Settings tab. Hilfe: open the log folder, export a diagnostics bundle, check for updates. Click to open, hover to switch between menus, click outside or Escape to close.
Downloads
-
Multi-Hoster-Upload v3.3.67 Stable
2026-06-15 00:31:11 +02:00 | 96 commits to master since this releaseFaster Upload history (Verlauf) and configurable retention; expand/collapse-all for accounts. The Verlauf tab now opens fast even with very large histories (renders the newest 2000 rows; the full history stays on disk and Export still emits everything). New retention setting in the Verlauf header: keep all (default), last 7/30/90 days, or last 1000/100 uploads, applied immediately with a confirmation showing how many entries are removed. Accounts: new button to expand or collapse all hoster groups at once.
Downloads
-
Multi-Hoster-Upload v3.3.65 Stable
2026-06-10 23:16:56 +02:00 | 99 commits to master since this releaseFiles panel: the REAL fix for 'newest upload doesn't appear on top until I click Datum twice'.
Root cause (finally pinned down): the panel's sort result is memoized, keyed by sortKey|direction|rowCount. The panel caps at 2000 rows — heavy sessions hit that cap quickly. Past the cap, every new link pushes one entry in and drops the oldest out, so the ROW COUNT STAYS AT 2000 → the cache key never changes → the sorter keeps returning the stale cached array WITHOUT the new entry. That's why exactly two Datum clicks 'fixed' it each time: click 1 flips to ascending (new cache key → fresh sort), click 2 flips back to descending (fresh sort again) → newest finally visible. Below 2000 rows the count changes on every add, so the bug only appeared after ~2000 uploads in a session — matching the 'happens after a while' observation.
Fix: a data-version counter that increments on EVERY mutation of the panel data (new link, delete selected, clear all) is now part of the cache key, so any change invalidates the memo. The 3.3.60 scroll-pin keeps the view at the top, so with date-descending (default) every fresh link now appears at the top instantly, no clicking, for the entire session regardless of how many thousands of links accumulate.
Downloads
-
Multi-Hoster-Upload v3.3.64 Stable
2026-06-10 16:53:05 +02:00 | 101 commits to master since this releaseThe network-outage auto-pause from 3.3.59 is REMOVED entirely. It false-positived on real servers and froze running batches with 'Netzwerk-Ausfall — pausiert' even though the network was fine, leaving thousands of jobs stuck at 'Wartet' with 0 connections until app restart.
Root cause of the false positive: the connectivity probe used dns.resolve(), which queries DNS servers directly via c-ares and BYPASSES the Windows system resolver. On locked-down servers (filtered DNS, VPN setups) those direct queries fail permanently while actual uploads — which use the OS resolver via dns.lookup() — work fine. Two failed probes closed the gate; since the probe could never succeed on such machines, the gate never reopened. Heavy uplink saturation during 5-hoster uploads could also time out the 5s probes and trigger the same freeze mid-batch.
Removed completely: the DNS probe loop, the network gate in the upload manager (job-start hold + retry hold), the 'Netzwerk-Ausfall — pausiert' status, and the pause/resume toasts. Upload behavior is back to exactly how it was before 3.3.59: transient network errors retry on the same account without blacklisting it, nothing ever holds the queue.
Unaffected and still active: Discord/webhook notifications (incl. ping + retry), auto-retry rounds after batch end (default off), and all other 3.3.59-3.3.63 features.
Downloads
-
Multi-Hoster-Upload v3.3.63 Stable
2026-06-10 15:42:37 +02:00 | 103 commits to master since this releaseBackups no longer carry the upload history (Verlauf tab).
- Export (.mhu and .json) now strips the history before writing — backups only contain accounts, hoster settings, and global settings. Smaller files, no upload trail in the backup.
- Import ignores any history present in the file (including history from backups made with older versions) and writes an empty history — after importing on a fresh server the Verlauf tab is empty instead of showing the source machine's uploads.
- The Backup section description in Settings now says so explicitly.
Both platforms keep their local history untouched on export; only import resets the local Verlauf (by design — the import replaces the whole config).
Downloads
-
Multi-Hoster-Upload v3.3.62 Stable
2026-06-10 00:08:26 +02:00 | 105 commits to master since this releaseWebhook reliability overhaul from a 5-lens multi-agent audit (36 confirmed findings). The notification now actually arrives in the situations where it used to silently fail.
Delivery reliability:
- sendBatchWebhook is now awaited and retries up to 3× with backoff. Before it was fire-and-forget with zero retry — exactly the wrong design for the one moment you need it (end of a long unattended batch, when the network is most likely to be briefly flaky). A transient failure now retries instead of vanishing.
- Discord 429 rate-limit is honored: the Retry-After header is parsed and the POST is re-sent. Critical when many servers finish near-simultaneously and all hit the same webhook — previously some notifications were silently dropped.
- HTTP status is validated. 2xx (incl. Discord's 204) = success; 4xx = stop (bad URL/payload, logged clearly); 5xx/network = retry. Previously ANY response — even 404/401 — was logged as 'sent'.
- The webhook is now awaited before the shutdown-after-finish countdown and before the upload manager is torn down, so an in-flight POST can't be killed.
- Webhook is now ALSO sent on the batch-init error path (startBatch reject) — previously only the happy path notified.
Correctness:
- isDiscordWebhook now requires a real id/token (…/webhooks//). An incomplete URL pasted by mistake no longer gets treated as a valid Discord webhook and 404'd silently.
- Discord 2000-char limit: content is capped (hoster breakdown truncated to top 12 + '…+N', hard clamp at 1900). A 60-hoster or huge batch can no longer 400.
- Fully-aborted/cancelled batches no longer fire a 'done' webhook (you cancelled it — you don't need a ping).
- Auto-retry rounds no longer each fire a webhook (was one ping per round); only the initial batch notifies.
- durationSec clamped to ≥0; machineName falls back to 'unknown-host' if hostname is empty.
Lifecycle:
- The network monitor's DNS-probe interval is now stopped on the batch error path too (was leaking an 8s timer per failed batch).
+12 tests (268 total).
Downloads
-
Multi-Hoster-Upload v3.3.61 Stable
2026-06-09 23:41:05 +02:00 | 107 commits to master since this releaseWebhook notifications can now actually PING you on Discord. Until now the batch-done message was just posted into the channel with no mention, so Discord showed it but never sent a push notification.
New optional 'Discord Ping' setting under Unbeaufsichtigter Betrieb. Accepts:
- your Discord User-ID (enable Developer Mode → right-click your name → Copy User ID) → pings you directly
- role:ROLE_ID or <@&ROLE_ID> → pings a role
- @here or @everyone → pings the channel
The mention token is prepended to the message and the correct allowed_mentions is set so Discord actually fires the notification. Left empty = post only, no ping (allowed_mentions is locked to parse:[] so a stray @ in any future content can never mass-ping by accident). The Test button now includes the ping too, so you can confirm the notification works. +6 tests (263 total).
Downloads
-
Multi-Hoster-Upload v3.3.60 Stable
2026-06-09 21:56:05 +02:00 | 109 commits to master since this releaseTwo fixes:
-
Files panel: newest links now stay pinned at the top live during an upload — no more clicking 'Datum' twice. The panel uses a scrollable wrapper; new rows were correctly inserted at the top of the table, but if the wrapper had drifted from scrollTop 0 (or browser scroll-anchoring held the old position) the newest row sat just above the viewport and looked like it landed at the bottom. Now, while sorted by date-desc (the default) and the user is at/near the top, the wrapper re-pins to the top whenever a new link comes in, so the newest is always visible. The sort-header click handler is also simplified back to a standard toggle (the previous first-click-is-a-no-op behaviour was the source of the 'click twice' annoyance). Row ids are now a strictly-increasing counter (no collisions after the 2000-row cap).
-
Byse 'Not video file format': the file no longer wastes ~30 seconds before failing. When byse explicitly rejects a file (not-video / duplicate / quota), the uploader was still running the 15× file-list recovery poll (built for the inconclusive empty-filecode case) before re-throwing the same verdict. Recovery polling is now skipped on explicit rejections — the file fails immediately, with no retry and no account rotation (unchanged). Inconclusive empty-filecode responses still poll + recover as before. +2 tests proving the list endpoint is hit once (baseline only) on rejection vs polled on a genuine empty response (257 total).
Downloads
-
-
Multi-Hoster-Upload v3.3.59 Stable
2026-06-09 20:40:36 +02:00 | 111 commits to master since this releaseUnattended-operation package — three features for batches that run while you sleep:
-
Network outage auto-pause + resume. While a batch is running, main probes DNS (one.one.one.one / dns.google alternating) every 8s. Two consecutive failures → offline: the upload manager closes a network gate — queued jobs hold before starting, and a job that just failed with a transient network error waits at the gate WITHOUT consuming a retry attempt (a 30-minute ISP flake no longer burns the whole retry budget). Two consecutive successes → online: all held jobs resume automatically. The status bar shows 'Netzwerk-Ausfall — pausiert' and toasts announce pause/resume. Monitor only runs during an active batch (zero idle overhead).
-
Auto-retry rounds after batch end. New settings under 'Unbeaufsichtigter Betrieb': Auto-Retry Runden (0-5, default 0=off) and Retry-Wartezeit (minutes, linear backoff — round N waits N×delay). After batch-done, transient failures (network, hoster-flake, unknown — NOT file-rejected/account errors) are automatically re-queued and started. Stops when no retryable failures remain or rounds are exhausted. Any manual start or cancel resets the cycle.
-
Webhook / Discord notification on batch-done. New 'Webhook-URL' setting with Test button. Discord webhook URLs are auto-detected and get a formatted message (ok/fail/total counts, duration, per-hoster breakdown, machine hostname — useful when multiple servers report to the same channel). Any other URL receives a generic JSON payload (event, version, machine, counts, durationSec, perHoster, timestamp) for custom automation. 10s timeout, failures only logged — never blocks the batch.
Also: the Verbose-Logging checkbox now actually persists across restarts (it was session-only before). +11 new tests (255 total).
Downloads
-
-
Multi-Hoster-Upload v3.3.58 Stable
2026-06-09 06:02:16 +02:00 | 113 commits to master since this releaseWaiting rows in the queue (status='queued', 'getting-server', 'retrying') no longer show '0 B / 0 B' when the file size hasn't been resolved yet.
Two causes for the cosmetic bug:
- Files added via folder drag-drop or restored from a pre-3.3.55 persisted queue have bytesTotal=0 — the renderer never knew the file size.
- The size cell rendered 'formatSize(0) / formatSize(0)' = '0 B / 0 B' for any non-preview status, even when bytesTotal was missing.
Fixes:
- New _formatUploadedSize(job) helper centralizes the cell logic. Queued / getting-server / retrying rows with bytesTotal=0 now render '...' (same as preview), so the column reads as 'size unknown, will resolve' instead of falsely 'this file is 0 bytes'.
- New _hydrateMissingJobSizes() helper collects all queueJobs paths with bytesTotal=0 and asks main via the existing get-file-sizes IPC. Sizes are patched in place, _queueStatsCache invalidated, queue + status bar re-rendered. Runs at: app boot after restore, and at every Start / startSelectedUpload click — so after Update + Restart, all waiting rows get their real sizes within ~50ms of the queue being visible.
- Status bar ETA + bytes-remaining will now include the formerly-invisible bytes.
Downloads