CMS Upload & Media Issues

How the pipeline works is described on Assets; this page is for when something looks wrong.

An asset card shows "Processing..." for a long time

Every upload is processed in the background — images into AVIF/WebP variants and thumbnails, audio into normalized AAC/Opus plus waveform data, video into an H.264 web rendition with a poster frame. Video takes the longest. While a video is processing, the layer inspector shows "Processing… duration and poster will appear once transcoding finishes." and the canvas badge reads processing….

If a card stays in that state far beyond the expected time, re-open the asset library to refresh, and if it persists, re-upload the file — a failed job leaves the card stuck.

My video has no poster or duration

Both come from transcoding. Until the job finishes they are simply not there yet (see above). Audio durations, by contrast, are extracted immediately in your browser at upload time.

"Forward–backward" playback is disabled for my video

Forward–backward (ping-pong) playback needs a downloadable video rendition so a reversed copy can be prepared. Streaming-only (HLS) assets don't have one, so the option is disabled for them — upload a regular video file (e.g. MP4) instead. See Video Panels.

Large uploads fail midway

Files of 10 MB and more upload in 5 MB parts, and each part is retried automatically up to three times — a short network hiccup doesn't cost you the upload. If a part still fails, the upload shows as Failed in the Large uploads section of the Assets tab: click Retry to continue from the parts already uploaded (the CMS restarts the file by itself if storage has discarded the partial upload). You can also Pause an upload and Resume it later without losing finished parts. Reloading or closing the tab discards unfinished uploads — those have to be started again. If large uploads consistently fail, check for proxies, VPNs, or firewalls that cut off long-running transfers or block direct uploads to the storage host. See Large files.

An upload is rejected with "File content does not match the declared type"

The CMS looks at what's actually inside each uploaded file. This message means the content doesn't fit the file's type — typically a file that was renamed (a .pdf saved as .png) or exported in a format the library doesn't recognise. Re-export the file from your image, audio, or video tool in a standard format and upload that. SVG files are also rejected when they are larger than 2 MB or contain scripts or embedded HTML. See Upload checks.

Re-uploading an old file after "Replace File"

Uploading the file you replaced earlier creates a new, separate asset next to the replaced one — the replaced asset keeps its ID and the new content. (Until September 2026 this failed with a server error.)

A work archive won't upload

The Import Archive dialog accepts .zip archives up to 50 GiB. Above 1 GiB the zip is sent in parts; closing or cancelling the dialog stops the upload and discards the parts already sent, so keep the dialog open until the import has started. A failed import can be retried from the dialog for 7 days — after that, upload the zip again.

Import is rejected

The Import dialog on My Works accepts PanelWave JSON manifests only, with two hard limits in the current release:

• panelwave.version must be a format from 1.0 to 1.7 (patch and pre-release versions included; newer formats get "This manifest uses format X; this CMS supports 1.0–1.7."),
• the file must be at most 10 MB.

The importer validates before importing and shows a preview of what will be created. See Import.

A replaced asset still shows the old image

Variants are cached aggressively. After replacing an asset, give processing a moment to regenerate variants, then hard-reload the editor (Ctrl+Shift+R). If a published work still serves the old file, re-publish so the CDN cache is invalidated — see Publishing.

"Too many requests. Please try again in N seconds."

The CMS limits how many requests a single account or address may send in a short time, to keep the service responsive for everybody. Ordinary editing stays far below these limits — you would typically only meet them with scripts, many browser tabs polling at once, or repeated sign-in attempts. Wait the number of seconds shown and try again.

Sign-in related actions have tighter limits of their own, per account:

A burst of failed sign-ins therefore blocks further attempts on that account for up to 15 minutes; use Forgot password? on the sign-in page if you're unsure of the password rather than retrying.