A disc image's source is always named ISO, because no row carries which kind of disc it is #236

New issue

Closed

opened 2026-09-16 06:28:07 +02:00 by Claude · 1 comment

Claude commented

2026-09-16 06:28:07 +02:00

Collaborator

A disc image's source is always named ISO, because nothing in this port works out which kind of disc it holds.

Both sides

upstream/MediaBrowser.Controller/Entities/BaseItem.cs:1340-1372 reads video.IsoType and appends Bluray or DVD when it is known, falling back to ISO only when it is null.

crates/ephyra-http/src/map/media.rs:1055-1070 appends ISO for every Iso row. There is no IsoType anywhere: no column, no blob member, and no scan that determines one.

What a client sees

A version dropdown naming a disc image reads Film - ISO here and Film - Bluray upstream.

The shape of the fix

Work out how upstream decides an IsoType at all — it is set when the image is resolved, from what the image contains — and file it on the row, then let the name read it. The doc comment on the naming states upstream's null-case rule as though it were the whole rule; that should say we never hold the value until this is done.

Found reviewing #229.

A disc image's source is always named `ISO`, because nothing in this port works out which kind of disc it holds. ## Both sides `upstream/MediaBrowser.Controller/Entities/BaseItem.cs:1340-1372` reads `video.IsoType` and appends `Bluray` or `DVD` when it is known, falling back to `ISO` only when it is null. `crates/ephyra-http/src/map/media.rs:1055-1070` appends `ISO` for every `Iso` row. There is no `IsoType` anywhere: no column, no blob member, and no scan that determines one. ## What a client sees A version dropdown naming a disc image reads `Film - ISO` here and `Film - Bluray` upstream. ## The shape of the fix Work out how upstream decides an `IsoType` at all — it is set when the image is resolved, from what the image contains — and file it on the row, then let the name read it. The doc comment on the naming states upstream's null-case rule as though it were the whole rule; that should say we never hold the value until this is done. Found reviewing #229.

Claude referenced this issue

2026-09-16 06:56:47 +02:00

A version group's sources are ordered without width, never led by what was last played, and named without format terms #229

Claude commented

2026-09-16 16:27:42 +02:00

Author

Collaborator

Closing this as decided rather than done: the gap is recorded as D53 and the misleading comment is fixed, landed on main at 60dd4302. No IsoType is filed.

Why not file the value. Upstream's BaseVideoResolver.SetIsoType is three steps: the path contains dvd, the path contains bluray, or open the image with a UDF reader and look for VIDEO_TS or BDMV. The first two are cheap and are not the detector — most disc images are named after the film.

And IsoType is not only a label. Upstream carries it into MediaSourceInfo, and the encoder builds a bluray: input from it. Filing a value from the path rules alone would identify a disc when the path happened to say so and leave every other image unidentified — moving the divergence out of a name a user reads and into what ffmpeg is told to open. Nothing in this port reads a filesystem out of a file, and no answer key can cover an .iso, because the generator cannot lay down a real UDF image.

Reading the kind at naming time was rejected too: it would put a resolver's rule in the mapping layer and let the row a client sees disagree with the row a transcode reads.

So a source naming a disc image reads ISO here, and the comment above it now says that this port never holds the value, instead of quoting upstream's null case as though it were the whole rule. D53 names what would justify revisiting it.

Closing this as decided rather than done: the gap is recorded as **D53** and the misleading comment is fixed, landed on `main` at `60dd4302`. No `IsoType` is filed. **Why not file the value.** Upstream's `BaseVideoResolver.SetIsoType` is three steps: the path contains `dvd`, the path contains `bluray`, or **open the image with a UDF reader and look for `VIDEO_TS` or `BDMV`**. The first two are cheap and are not the detector — most disc images are named after the film. And `IsoType` is not only a label. Upstream carries it into `MediaSourceInfo`, and the encoder builds a `bluray:` input from it. Filing a value from the path rules alone would identify a disc when the path happened to say so and leave every other image unidentified — moving the divergence out of a name a user reads and into what ffmpeg is told to open. Nothing in this port reads a filesystem out of a file, and no answer key can cover an `.iso`, because the generator cannot lay down a real UDF image. Reading the kind at naming time was rejected too: it would put a resolver's rule in the mapping layer and let the row a client sees disagree with the row a transcode reads. So a source naming a disc image reads `ISO` here, and the comment above it now says that this port never holds the value, instead of quoting upstream's null case as though it were the whole rule. D53 names what would justify revisiting it.

Claude closed this issue

2026-09-16 16:27:42 +02:00