The Clip is cut from whatever stream sits at that index #42

New issue

Open

opened 2026-08-13 15:08:17 +00:00 by aiko · 0 comments

aiko commented

2026-08-13 15:08:17 +00:00

Owner

What to build

Cut the Clip from the audio stream, not from whatever stream happens to sit at that index.

The failure, from the first real Export. Every Clip failed with ffmpeg exit 234:

Output #0, opus, to '/config/data/data/kurageyomi/media/4.opus':
[out#0/opus] Output file does not contain any stream
Error opening output file ... Invalid argument

-map 0:{index} matched a stream — an unmatched map says so explicitly and this did not — and then -vn -sn -dn removed it. That only happens when the mapped stream is not audio. The source is an mkv carrying around thirty streams including font attachments, so being one slot out is enough.

The comment in FfmpegExtractionEncoder states the assumption that broke: "The Capture's index is the stream's position in the whole file, which is what Jellyfin reports and what ffmpeg's 0:n means." One of those two halves is untrue for this file, and the plugin has no business guessing which.

Resolve it server-side against what Jellyfin already knows. MediaSourceLocator has ILibraryManager and the media source in hand, and a media source carries its MediaStreams with both their index and their type. Look the Capture's index up there, confirm it is an audio stream, and pass the index that actually addresses audio. When the stored index does not name an audio stream — an old Capture, a re-indexed file, a session that reported something else — fall back to the media source's default audio stream rather than failing: a Clip of the wrong language is recoverable and a Capture that never cuts is not.

Say what happened when it still fails. The current failure reports ffmpeg's tail, which is 400 characters of font attachments and no mention of which stream was asked for. The reason should name the index that was mapped and what type it turned out to be. This is the fourth failure in this area where the message named a conclusion rather than the fact that ends the search.

Acceptance criteria

The Clip is cut from a stream confirmed to be audio, resolved from the media source rather than assumed from the stored index
A Capture whose stored index does not name an audio stream still produces a Clip, from the default audio stream
A source with no audio stream at all fails with a reason that says so, rather than an ffmpeg tail
The failure reason names the stream index that was used and its type
The three Captures currently sitting failed in the queue succeed on a retry, without being re-mined
Tests cover: an index that names audio, an index that names a non-audio stream, and a source with no audio at all

Blocked by

None - can start immediately.

## What to build Cut the Clip from the audio stream, not from whatever stream happens to sit at that index. **The failure, from the first real Export.** Every Clip failed with ffmpeg exit 234: ``` Output #0, opus, to '/config/data/data/kurageyomi/media/4.opus': [out#0/opus] Output file does not contain any stream Error opening output file ... Invalid argument ``` `-map 0:{index}` matched a stream — an unmatched map says so explicitly and this did not — and then `-vn -sn -dn` removed it. That only happens when the mapped stream is not audio. The source is an mkv carrying around thirty streams including font attachments, so being one slot out is enough. The comment in `FfmpegExtractionEncoder` states the assumption that broke: *"The Capture's index is the stream's position in the whole file, which is what Jellyfin reports and what ffmpeg's `0:n` means."* One of those two halves is untrue for this file, and the plugin has no business guessing which. **Resolve it server-side against what Jellyfin already knows.** `MediaSourceLocator` has `ILibraryManager` and the media source in hand, and a media source carries its `MediaStream`s with both their index and their type. Look the Capture's index up there, confirm it is an audio stream, and pass the index that actually addresses audio. When the stored index does not name an audio stream — an old Capture, a re-indexed file, a session that reported something else — fall back to the media source's default audio stream rather than failing: a Clip of the wrong language is recoverable and a Capture that never cuts is not. **Say what happened when it still fails.** The current failure reports ffmpeg's tail, which is 400 characters of font attachments and no mention of which stream was asked for. The reason should name the index that was mapped and what type it turned out to be. This is the fourth failure in this area where the message named a conclusion rather than the fact that ends the search. ## Acceptance criteria - [ ] The Clip is cut from a stream confirmed to be audio, resolved from the media source rather than assumed from the stored index - [ ] A Capture whose stored index does not name an audio stream still produces a Clip, from the default audio stream - [ ] A source with no audio stream at all fails with a reason that says so, rather than an ffmpeg tail - [ ] The failure reason names the stream index that was used and its type - [ ] The three Captures currently sitting `failed` in the queue succeed on a retry, without being re-mined - [ ] Tests cover: an index that names audio, an index that names a non-audio stream, and a source with no audio at all ## Blocked by None - can start immediately.

aiko added the

ready-for-agent

label

2026-08-13 15:08:17 +00:00

aiko referenced this issue from a commit

2026-08-13 15:30:41 +00:00

fix: cut the Clip from a stream confirmed to be audio

aiko referenced this issue from a commit

2026-08-13 15:30:41 +00:00

merge: cut the Clip from audio, and never print undefined (#42, #43)