Follow-up to #2797. `cutMultiple` already calls `assertFileExists` before
spawning ffmpeg, so a source file that was moved or deleted after being
opened produces a clear "Source file no longer exists or is not
accessible" message instead of a raw ExecaError plus the generic "Unable
to export this file" checklist (change output format, try keyframe cut,
change working directory...), none of which can help.
The other export paths had no such guard, so they still fail with a bare
ffmpeg "No such file or directory". Add the same check to:
- `captureFramesRange` (export segment frames as images)
- `captureFrameFromFfmpeg` (capture snapshot)
- `extractStreams` (extract all tracks / extract single track)
`extractAllStreams`/`extractSingleStream` swallowed the error message and
showed a generic toast, so let UserFacingError through there as well,
matching how the export and merge flows already handle it.
Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PqUn6Bh7hWqPqWejqR8p7u
`-movflags` (mov/mp4 family) and `-default_mode` (matroska family) were
added to every ffmpeg command regardless of the output format, so e.g.
exporting to matroska produced:
... -movflags "+faststart" -default_mode infer_no_subs -f matroska ...
ffmpeg tolerates private options belonging to a different muxer, so this
was harmless, but it adds noise to the command line we log, show under
"Last commands" and include in problem reports, which makes
troubleshooting harder than it needs to be.
Gate each set of flags on the output format. The format lists are derived
from ffmpeg's movenc.c and matroskaenc.c rather than the existing
util/streams.ts `isMov`/`isMatroska` helpers, because those are narrower
UI oriented lists that omit movenc formats we can output (3gp, 3g2, f4v,
psp) - reusing them would have silently dropped +faststart for those.
When the output format is unknown, ffmpeg infers the muxer from the file
extension, so the flags are kept as before.
Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PqUn6Bh7hWqPqWejqR8p7u
Setting `base: core22` left the snap declaring a core22 base while still
plugging the core18-era gnome-3-28-1804 content snap for its GNOME platform.
Mesa's DRI drivers in that platform cannot resolve their dependencies against
core22, so every GL/EGL path fails including the swrast software fallback, the
GPU process exits, and the main process segfaults before a window appears.
The base override never moved the platform. electron-builder's snap template
pairs `base: core20` with a hardcoded `gnome-3-28-1804` plug, and its legacy
snap path rewrites only the `base` field, leaving the plugs block untouched.
The two halves have to match, so the fix is to stop overriding the base and
let the template stay self-consistent.
Dropping the key rather than pinning core20 explicitly means the snap keeps
following whatever electron-builder's template ships.
This restores the pre-3.68 behaviour, which reopens#2614 for very new GPUs
whose hardware needs a newer Mesa than the platform provides. That trade is
deliberate: #2614 affected some GPUs, this affects every user.
Fixes#3002
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KboMatXCuTgjD6KfC1ik12
electron-builder's default AppImage toolset ("0.0.0") uses the legacy
AppImageKit runtime, which dlopens libfuse.so.2 at startup and fails on
distros that no longer ship libfuse2.
Opting into toolset appimage 1.0.3 uses AppImage/type2-runtime 20251108,
a static-pie runtime with libfuse/squashfuse linked in, so the AppImage
runs without any FUSE packages installed.
Fixes#3022
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01MmsuZZPx6pFKSjN6UZmGcJ
On Windows, when the ffmpeg/ffprobe executable does not exist (e.g. a
custom FFmpeg directory pointing to a location without ffmpeg.exe),
cross-spawn (used by execa) falls back to running the command through
cmd.exe, which fails with exit code 1 and a confusing
"'...' is not recognized as an internal or external command" error
instead of ENOENT. This bypassed the "FFmpeg executable not found"
dialog and instead triggered the error report dialog.
Now check that the executables exist as part of the startup check
(which also re-runs whenever the custom FFmpeg directory setting
changes), so a missing executable yields a proper ENOENT. Also mention
the custom FFmpeg directory setting in the error dialog when one is
configured.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PE6aFnysh85Ryndeu6zXYG
Gating steps on the exact matrix image name (windows-latest,
windows-11-arm) breaks silently whenever the image in the matrix is
renamed, as happened with the windows-2022 switch. runner.os and
runner.arch describe what we actually care about and are independent
of the image label.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PWvFPqUcXUzsYf3DY7RziJ
The matrix was switched from windows-latest to windows-2022, but the
Windows x64 ffmpeg download, electron-builder, e2e and screenshot upload
steps were still gated on matrix.os == 'windows-latest', so they never
ran and the artifact upload failed with
'File dist/LosslessCut-win-x64.7z does not exist'.
Gate them on runner.os == 'Windows' && matrix.os != 'windows-11-arm'
instead, so they are independent of the exact Windows runner image.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PWvFPqUcXUzsYf3DY7RziJ
Mikael Finstad