I run unmanic to transcode my library to HEVC via VAAPI, and one file kept failing within ~20 seconds with no obvious reason. After digging into the command log, it turns out the failure has nothing to do with the codec or the hardware — unmanic's own working/output filename ends up too long for the filesystem to create.
What happens
For each conversion, the worker builds a working output path by taking the source basename and appending a suffix, roughly:
/tmp/unmanic/unmanic_file_conversion-<5char>-<epoch>/<source basename>-<5char>-<epoch>-WORKING-<n>-<n>.mkv
When the source basename is already long, that appended -<5char>-<epoch>-WORKING-<n>-<n> (~29 characters) pushes the filename component past the filesystem's NAME_MAX of 255 bytes. ffmpeg then can't open the output file and aborts immediately:
[out#0/matroska @ 0x…] Error opening output /tmp/unmanic/unmanic_file_conversion-xxxxx-17xxxxxxxx/<long name>-xxxxx-17xxxxxxxx-WORKING-1-1.mkv: File name too long
Error opening output file …
Error opening output files: File name too long
The task is then marked failed ~20s in, and there's no filename-specific message surfaced in the UI — it just reads as a generic failure.
Concrete numbers (from a real failing file)
- Source basename: 250 characters (legal on its own — under 255, which is why the file sits happily in the library).
- Working filename component after the suffix is appended: 279 characters → over
NAME_MAX (255).
So the practical threshold is roughly: any source basename longer than ~226 characters will fail, because 226 + ~29 (suffix) ≈ 255.
What kind of file hits this
Long bracket-style release names — common with anime and scene releases that embed every audio/subtitle language plus a CRC right in the filename, e.g.:
[Group] Title (Year) [Blu-ray 1080p][10bit][H264][FLAC 5.1][Multi-Audio][English+Japanese+French+German+Spanish+Italian+Portuguese+Russian+Korean+Chinese][Multi-Subs][ENG+JPN+FRA+DEU+SPA+ITA+POR+RUS+KOR+CHI+ARA+HIN][CRC12345].mkv
Expected behaviour
unmanic should detect when the generated working filename would exceed NAME_MAX and shorten/hash it — keep the extension, use a truncated or hashed basename for the temporary file. The temp filename is internal, so it doesn't need to preserve the full original name.
Environment
josh5/unmanic:latest (Python 3.12)- ffmpeg backend with
hevc_vaapi — though this is independent of the encoder; it's the output-path open that fails, before any encoding starts.
- Cache directory on a standard Linux filesystem (
NAME_MAX 255).
Suggested fix
When constructing the working filename, cap the basename so len(basename) + len(suffix) stays under 255 with some margin for the extension and the cache subdirectory — hash or truncate the original basename when it would overflow. Happy to open a PR if there's interest; a pointer to where this name is assembled would help.
I run unmanic to transcode my library to HEVC via VAAPI, and one file kept failing within ~20 seconds with no obvious reason. After digging into the command log, it turns out the failure has nothing to do with the codec or the hardware — unmanic's own working/output filename ends up too long for the filesystem to create.
What happens
For each conversion, the worker builds a working output path by taking the source basename and appending a suffix, roughly:
When the source basename is already long, that appended
-<5char>-<epoch>-WORKING-<n>-<n>(~29 characters) pushes the filename component past the filesystem'sNAME_MAXof 255 bytes. ffmpeg then can't open the output file and aborts immediately:The task is then marked failed ~20s in, and there's no filename-specific message surfaced in the UI — it just reads as a generic failure.
Concrete numbers (from a real failing file)
NAME_MAX(255).So the practical threshold is roughly: any source basename longer than ~226 characters will fail, because
226 + ~29 (suffix) ≈ 255.What kind of file hits this
Long bracket-style release names — common with anime and scene releases that embed every audio/subtitle language plus a CRC right in the filename, e.g.:
Expected behaviour
unmanic should detect when the generated working filename would exceed
NAME_MAXand shorten/hash it — keep the extension, use a truncated or hashed basename for the temporary file. The temp filename is internal, so it doesn't need to preserve the full original name.Environment
josh5/unmanic:latest(Python 3.12)hevc_vaapi— though this is independent of the encoder; it's the output-path open that fails, before any encoding starts.NAME_MAX255).Suggested fix
When constructing the working filename, cap the basename so
len(basename) + len(suffix)stays under 255 with some margin for the extension and the cache subdirectory — hash or truncate the original basename when it would overflow. Happy to open a PR if there's interest; a pointer to where this name is assembled would help.