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

New issue

Closed

opened 2026-09-16 01:13:37 +02:00 by Claude · 1 comment

Claude commented

2026-09-16 01:13:37 +02:00

Collaborator

Three ways the media sources of a version group differ from upstream's, all on the read side that #214 made reachable.

1. The order drops upstream's width tiebreak

crates/ephyra-http/src/assemble/playback.rs:641-649 sorts by: the asked row first, then a plain file before a folder rip, then 3D last. Upstream's BaseItem.GetMediaSources (upstream/MediaBrowser.Controller/Entities/BaseItem.cs:1180-1188) has a fourth key, ThenByDescending(i => i, new MediaSourceWidthComparator()).

With three or more cuts of one title, all plain files, every source after the first can be in a different order from upstream's. A client's version dropdown lists them in that order. The current tests cannot see it, because the asked row always takes the first slot.

2. The most recently played version is not moved to the front

Upstream's SetAlternateVersionResumeStates puts the version a user last played at the head of the list, so a client reopening a film offers the cut that was being watched. Ours leaves the order as it is.

3. A source name carries no format terms

Upstream appends 3D, Bluray, DVD and ISO to a source's name where they apply. Ours names a source from the file alone. This is pre-existing, and it shows on the same dropdown as the other two.

Verifying

crates/ephyra-http/tests/versions.rs covers serving a group. A film with three cuts of different widths, and a played cut, can fail for the first two. The third needs a rip or a 3D file in the fixture.

Found reviewing #214.

Three ways the media sources of a version group differ from upstream's, all on the read side that #214 made reachable. ## 1. The order drops upstream's width tiebreak `crates/ephyra-http/src/assemble/playback.rs:641-649` sorts by: the asked row first, then a plain file before a folder rip, then 3D last. Upstream's `BaseItem.GetMediaSources` (`upstream/MediaBrowser.Controller/Entities/BaseItem.cs:1180-1188`) has a fourth key, `ThenByDescending(i => i, new MediaSourceWidthComparator())`. With three or more cuts of one title, all plain files, every source after the first can be in a different order from upstream's. A client's version dropdown lists them in that order. The current tests cannot see it, because the asked row always takes the first slot. ## 2. The most recently played version is not moved to the front Upstream's `SetAlternateVersionResumeStates` puts the version a user last played at the head of the list, so a client reopening a film offers the cut that was being watched. Ours leaves the order as it is. ## 3. A source name carries no format terms Upstream appends `3D`, `Bluray`, `DVD` and `ISO` to a source's name where they apply. Ours names a source from the file alone. This is pre-existing, and it shows on the same dropdown as the other two. ## Verifying `crates/ephyra-http/tests/versions.rs` covers serving a group. A film with three cuts of different widths, and a played cut, can fail for the first two. The third needs a rip or a 3D file in the fixture. Found reviewing #214.

Claude referenced this issue

2026-09-16 01:48:24 +02:00

A local alternate version is filed but never joined to the title it is a cut of #214

Claude referenced this issue

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

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

Claude commented

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

Author

Collaborator

Fixed, and landed on main at 94f7a924.

All three read against the pin first, because each is easy to get backwards:

Width. MediaSourceWidthComparator returns 0 unless the two sources' paths match, ignoring case, so width breaks ties only among sources naming one file. Ours orders the widest first with a source carrying no video stream last, after the three keys that come before it.
The last-played version. SetAlternateVersionResumeStates moves a version to the front only for a video with at least two sources, where the state has a position past zero and the asked item has no primary. The winner is the latest play, compared strictly, so the first encountered wins a tie. Ours does the same, and the user data is read under each version's own keys — including its Tmdb key, which is where upstream writes a film's state, so the reorder fires against rows upstream wrote rather than only against our own.
The terms. 3D, then Bluray, DVD or ISO, joined with a slash, videos only, applied once.

The issue also expected a resolution term. There is none at the pin: those four are the only literals GetMediaSourceName appends.

Left: a disc image always reads ISO here, because no row carries which kind of disc it is. Filed as #236.

Fixed, and landed on `main` at `94f7a924`. All three read against the pin first, because each is easy to get backwards: - **Width.** `MediaSourceWidthComparator` returns 0 unless the two sources' paths match, ignoring case, so width breaks ties only among sources naming one file. Ours orders the widest first with a source carrying no video stream last, after the three keys that come before it. - **The last-played version.** `SetAlternateVersionResumeStates` moves a version to the front only for a video with at least two sources, where the state has a position past zero and the asked item has no primary. The winner is the latest play, compared strictly, so the first encountered wins a tie. Ours does the same, and the user data is read under each version's own keys — including its Tmdb key, which is where upstream writes a film's state, so the reorder fires against rows upstream wrote rather than only against our own. - **The terms.** `3D`, then `Bluray`, `DVD` or `ISO`, joined with a slash, videos only, applied once. The issue also expected a resolution term. There is none at the pin: those four are the only literals `GetMediaSourceName` appends. Left: a disc image always reads `ISO` here, because no row carries which kind of disc it is. Filed as #236.

Claude closed this issue

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