An attachment is read from a rip's folder, not its concat list #45

New issue

Closed

opened 2026-08-03 21:01:09 +02:00 by Claude · 1 comment

Claude commented

2026-08-03 21:01:09 +02:00

Collaborator

An attachment is pulled out of a rip through the folder it lives in, where
upstream reads it out of the concat list.

TranscodeManager picks the input by video type before it extracts
(TranscodeManager.cs:401):

if (state.MediaSource.VideoType == VideoType.Dvd || ... BluRay)
    concatPath = Path.Join(CachePath, "concat", MediaSource.Id + ".concat");
    ExtractAllAttachments(concatPath, ...)
else
    ExtractAllAttachments(state.MediaPath, ...)

so a rip's fonts come out of the list of files that play it, and only a plain
file is read through its own path. This port passes the source's own path for
both, which for a rip is a directory ffmpeg cannot open.

Subtitles are not affected: SubtitleEncoder reads mediaSource.Path whatever
the video type is, which is what this port already does.

Blocked on #43 — there is no list to read until one is written.

The .concat branch already in crates/jellyfin-encoding/src/attachment.rs is
unreachable until this is fixed, so whatever it does is unmeasured.

Only reached when a subtitle is burned in, which needs a rip carrying a
subtitle stream. Neither library here has one, so this is read from upstream
rather than seen.

An attachment is pulled out of a rip through the folder it lives in, where upstream reads it out of the concat list. `TranscodeManager` picks the input by video type before it extracts (`TranscodeManager.cs:401`): if (state.MediaSource.VideoType == VideoType.Dvd || ... BluRay) concatPath = Path.Join(CachePath, "concat", MediaSource.Id + ".concat"); ExtractAllAttachments(concatPath, ...) else ExtractAllAttachments(state.MediaPath, ...) so a rip's fonts come out of the list of files that play it, and only a plain file is read through its own path. This port passes the source's own path for both, which for a rip is a directory ffmpeg cannot open. Subtitles are not affected: `SubtitleEncoder` reads `mediaSource.Path` whatever the video type is, which is what this port already does. Blocked on #43 — there is no list to read until one is written. The `.concat` branch already in `crates/jellyfin-encoding/src/attachment.rs` is unreachable until this is fixed, so whatever it does is unmeasured. Only reached when a subtitle is burned in, which needs a rip carrying a subtitle stream. Neither library here has one, so this is read from upstream rather than seen.

Claude commented

2026-08-03 21:37:11 +02:00

Author

Collaborator

A rip's fonts now come out of the list of the files that play it.

TranscodeManager picks the extraction's input by video type before it
extracts, and only a plain file is read through its own path. This server
passed the source path either way, which for a rip is a directory ffmpeg
cannot open — so a burned-in subtitle on a rip lost every font in it.

That also reaches the .concat branch the attachment builder already carried,
which nothing could hand a list to until now. Upstream spots the list the same
way, by the suffix on the input path.

Subtitles are unchanged: SubtitleEncoder reads the source's own path whatever
the video type is, which is what this already did.

The test covers the wiring rather than the argument builder — pointing the
extraction back at the source path fails it. A test on the builder alone passed
either way, which is no test at all.

Still unmeasured, and unmeasurable here: this path is only reached when a
subtitle is burned into a rip, and neither library holds a rip at all, let alone
one carrying a subtitle stream. The corpus cannot see it either, its generator
refusing a folder source. Read from upstream and asserted by hand.

A rip's fonts now come out of the list of the files that play it. `TranscodeManager` picks the extraction's input by video type before it extracts, and only a plain file is read through its own path. This server passed the source path either way, which for a rip is a directory ffmpeg cannot open — so a burned-in subtitle on a rip lost every font in it. That also reaches the `.concat` branch the attachment builder already carried, which nothing could hand a list to until now. Upstream spots the list the same way, by the suffix on the input path. Subtitles are unchanged: `SubtitleEncoder` reads the source's own path whatever the video type is, which is what this already did. The test covers the wiring rather than the argument builder — pointing the extraction back at the source path fails it. A test on the builder alone passed either way, which is no test at all. Still unmeasured, and unmeasurable here: this path is only reached when a subtitle is burned into a rip, and neither library holds a rip at all, let alone one carrying a subtitle stream. The corpus cannot see it either, its generator refusing a folder source. Read from upstream and asserted by hand.

Claude closed this issue

2026-08-03 21:37:11 +02:00