Follow-up to an earlier report where I blamed a general 'burst media load'. I have now reproduced this outside Electron and the earlier explanation was wrong, so here is a corrected root cause with measurements.
Opening the Video Editor on a board with ~692 media files blocks the renderer main thread for over three minutes. It does not self-recover; the only way out is force-quitting the app.
KEY FINDING: the editor sidebar's media pane is always mounted and renders one DOM row per file for the CURRENT board, with no virtualization. On a ~700-file board that builds 434 <img> and 39 <audio> elements in a single synchronous pass.
Two things I initially suspected and have now ruled out:
1. NOT a reload/remount loop. There are no 'GET /' or 'GET /assets/index-*.js' requests during the freeze, so the renderer never reloads. In a clean reproduction exactly ONE /api/media/admin call fires, then the freeze.
2. NOT the canvas iframes. Inside the frozen page, document.querySelectorAll('iframe').length is 0 – the canvas is unmounted when the editor opens. Total DOM is only ~10,139 nodes, so this is not a DOM-size explosion either.
Also NOT the video project: the active project payload is 5 KB, 7 clips, 7 channels.
SECONDARY ISSUE – /api/media/admin is unscoped. It returns every file across every board: 1,452 files / 17 boards / 3.94 GB, as a 3.74 MB JSON response taking 5.3 s server-side. It ignores ?board_id= and ?board= (byte-identical responses). The editor only ever needs the current board. The panel does already collapse other boards in the UI, so the extra ~760 files are fetched and parsed but never shown.
THIRD ISSUE – the media pane is mounted even when hidden. In the editor sidebar it is rendered as style={{display: tab==='media'||tab==='presets' ? 'flex' : 'none'}}, so all rows are built on editor open regardless of which sidebar tab is active. Users cannot avoid the cost by staying on another tab.
Suggested fixes, in order of impact: virtualize the media grid (or cap rows with a 'show more'); mount the media pane only when its tab is active; add a board scope parameter to /api/media/admin and use it from the editor; make audio rows lazy (they are currently fetched as 206 Partial Content on render, i.e. real decoding <audio> elements).
I tried a local workaround of forcing collapseToCurrentBoardByDefault to true by default – it is a no-op, because the editor already passes that flag. The cost is the current board's own files, so board-scoping alone will not fix it.
Steps to reproduce
1. Use a board with roughly 700 media files (mine: 692 files, 3.12 GB, 444 elements – 167 html, 150 image, 42 video, 33 audio, 32 frame).
2. Open the board on the canvas and let it settle.
3. Click Editor in the header.
4. The renderer stops responding within a couple of seconds and stays blocked for 200s+.
Reproduces in a plain Chrome tab too, not just Electron: the backend serves the same SPA, so loading http://localhost:18000/ , opening the board and clicking Editor blocks the tab identically. A page.evaluate issued immediately after the click took 216 seconds to return.
Expected
The Video Editor opens promptly and the media sidebar stays responsive, regardless of how many files the board holds.
Actual
The main thread is blocked for 200s+ (measured 216 s). The app logs 'Renderer became unresponsive.' about 15 s in, and 'Renderer became responsive again' only ever appears in the same second as 'All windows closed' – i.e. the force-quit is what ends it.
Error output
[2026-08-13 17:06:56.617] GET /assets/VideoEditor-Y5rD_08J.js 304
[2026-08-13 17:07:01.668] GET /api/media/admin 200 OK <- 3.74 MB, 5.3 s, 1452 files / 17 boards
[2026-08-13 17:07:02.150] GET /media/.../Alt_Logos_....png?thumb=384 200 OK
... 118 media fetches in one burst, 37 of them 206 Partial Content (audio/video) ...
[2026-08-13 17:07:17.558] [warn] Renderer became unresponsive.
[2026-08-13 17:08:33.848] [info] Renderer became responsive again.
[2026-08-13 17:08:46.020] [info] All windows closed, shutting down...
Measured directly against the API:
GET /api/media/admin -> 5.27 s, 3,738,442 bytes
GET /api/media/admin?board_id=<board> -> 5.65 s, 3,738,442 bytes (identical)
GET /api/media/admin?board=<board> -> 5.25 s, 3,738,442 bytes (identical)
GET /api/moodboards/<board>/elements -> 0.24 s, 257,714 bytes
GET /api/moodboards/<board>/video-projects?data=active -> 0.37 s, 14,251 bytes (active project 5 KB, 7 clips)
Inside the frozen page, 216 s after the Editor click:
{ secondsSinceEditorClick: 216, mediaAdminCalls: 1, audioEls: 39, imgEls: 434, videoEls: 0, iframeEls: 0, domNodes: 10139 }
Context
Feature area: Video Editor / media sidebar, plus the /api/media/admin endpoint. Board has 692 media files (3.12 GB) and 444 elements. Install total across 17 boards: 1,452 files / 3.94 GB. Frontend chunks involved: index-BFuCHuRi.js (media panel component and its listMedia call) and VideoEditor-Y5rD_08J.js (sidebar that mounts it). No virtualization library is present in the frontend bundle; the media grid relies only on loading=lazy for images, and audio rows are not lazy at all.
Environment
App version: 9.6.0
Platform: Windows 11 (AMD64)
