Preview generation fails when video stream has a non-zero start offset
Have you enabled troubleshooting mode?
- I confirm that the troubleshooting mode is enabled.
Describe the bug
Video preview generation fails for files whose video stream starts at a non-zero timestamp while the container reports start: 0.
Stash distributes the preview segments evenly across the duration reported by the container, so the first segment is cut at t=0. At that position no video frame exists yet and ffmpeg writes a 0-byte file. The same happens at the end, because the effective video length is shorter than the reported duration.
The concat demuxer determines the stream layout from the first entry of the list. With an empty file there it aborts with "Output file does not contain any stream", and the entire preview fails even though the remaining segments were encoded correctly. The fallback path fails identically.
Observed with HEVC files converted with HandBrake 1.11.1, but the codec is not the cause: the relevant property is the video stream start offset, which can occur with any codec or encoder. In this case HandBrake preserved an offset from the original recording, where audio started before video.
Steps to reproduce
- Use a file where ffprobe reports a video stream start offset while the container reports
start: 0(see ffprobe output below) - Set "Exclude start time" and "Exclude end time" to 0
- Run Generate -> Previews for that scene
- Preview generation fails, fallback fails identically
- While the task is running,
generated/tmpcontains the segment files; the first and last are 0 bytes
Expected behaviour
Empty or stream-less segments should be skipped when building the concat list, rather than aborting the whole preview. Alternatively, segment positions could be derived from the actual video stream start/end instead of the container duration.
Screenshots or additional context
Workaround
Setting "Exclude start time" and "Exclude end time" to 2% keeps the segments away from the edges; previews then generate normally.
Diagnosability
The root cause is effectively invisible:
- The segment phase is not logged at all. With log level set to Debug, the log contains no
DBUGentries and no ffmpeg invocations for the individual segments — only the final concat command, and only because it failed. Between "generating video preview" and the fallback warning, ~11 seconds of work happen with zero log output. - The concat list file and the segment files are removed immediately when the run fails, so their contents cannot be inspected afterwards. Capturing the
.txtby polling the tmp directory did not succeed; it exists only for a fraction of a second. Logs
HTTP request lines omitted; no other entries were present in this range.
ffprobe output of the affected file ``` Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '.mp4': Metadata: major_brand : mp42 minor_version : 512 compatible_brands: mp42iso2mp41 encoder : HandBrake 1.11.1 2026032200 Duration: 04:56:46.83, start: 0.000000, bitrate: 3221 kb/s Stream #0:0[0x1](und): Video: hevc (Main) (hvc1 / 0x31637668), yuv420p(tv, bt709), 1920x1080 [SAR 1:1 DAR 16:9], 3045 kb/s, 59.98 fps, 60 tbr, 90k tbn, start 2.017000 (default) Stream #0:1[0x2](und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 161 kb/s (default) ```Note start 2.017000 on the video stream vs. start: 0.000000 on the container.
0 KB, 1 KB, 28 KB, 30 KB, 32 KB, 33 KB, 37 KB, 38 KB,
40 KB, 43 KB, 44 KB, 52 KB, 52 KB, 55 KB, 61 KB, 0 KBThe 0-byte files correspond to the segments at the very start and very end of the file.
Decoding works — manual segment encode succeeds Running the segment command manually at an arbitrary timestamp produces a valid 0.75s clip (32 KB, plays correctly):ffmpeg -v error -ss 1000 -t 0.75 -i "<file>.mp4" -y -c:v libx264 -pix_fmt yuv420p \
-profile:v high -level 4.2 -preset veryfast -crf 21 -threads 4 -vf scale=640:-2 -an out.mp4This rules out a decoder or HEVC/hvc1 seeking problem.
**Additional context**All affected files in my library come from the same HandBrake pipeline and share the same offset, which is why this initially looked like an HEVC decoding problem. Possibly related to #6499 (fast seek producing no output in generate tasks).
Stash version
v0.31.1
Device details
Chrome 153 64bit Windows 11 25H2 (26200.9445)
Relevant log output
This is the complete unmodified section for the run, log level was set to Debug. Only the Windows user name and media paths were replaced. Apart from HTTP request lines, nothing else was logged in this time range — as described in the issue, the segment phase produces no log output at all.
2026-09-12 21:31:00Info Generate finished (47.59052s)
2026-09-12 21:31:00Error command stderr: [out#0/mp4 @ 0000026f2368ec40] Output file does not contain any stream Error opening output file C:\Users\User\.stash\generated\tmp\1392784893.mp4. Error opening output files: Invalid argument
2026-09-12 21:31:00Error error generating preview: error running ffmpeg command <-v error -f concat -i C:/Users/User/.stash/generated/tmp/1676700445.txt -y -c:v copy -c:a copy C:\Users\User\.stash\generated\tmp\1392784893.mp4>: exit status 0xffffffea
2026-09-12 21:30:29Info [generator] generating video preview for F:\Videos\Example\example_video.mp4
2026-09-12 21:30:29Warning [generator] failed generating scene preview, trying fallback
2026-09-12 21:30:13Info [generator] generating video preview for F:\Videos\Example\example_video.mp4
2026-09-12 21:30:12Info Creating screenshot for F:\Videos\Example\example_video.mp4
2026-09-12 21:30:12Info [generator] generating phash sprite for F:\Videos\Example\example_video.mp4
2026-09-12 21:30:12Info Generating 1 covers 1 previews 1 phashes
2026-09-12 21:30:12Info Generate started with 6 parallel tasksSource: stashapp/stash