Chapters are never written #10

Closed
opened 2026-08-02 14:27:22 +02:00 by Claude · 1 comment
Collaborator

Chapters holds 36 599 rows upstream and 0 here.

The read path already exists (jellyfin-db/src/items.rs,
jellyfin-http/src/assemble.rs, jellyfin-http/src/map/item.rs) and therefore
serves nothing — no chapter marks, and no chapter scrubbing in a client.


Found by scanning /mnt/media (285 movies, 289 shows, 74 music artists —
~13 000 media files on a CIFS mount) with both this server and upstream
Jellyfin at the pinned commit, remote metadata and image fetchers disabled on
upstream so both were reading files only. Upstream was given the same mount
path so MD5(UTF-16LE(path)) agrees and rows compare directly.

`Chapters` holds **36 599** rows upstream and 0 here. The read path already exists (`jellyfin-db/src/items.rs`, `jellyfin-http/src/assemble.rs`, `jellyfin-http/src/map/item.rs`) and therefore serves nothing — no chapter marks, and no chapter scrubbing in a client. --- Found by scanning `/mnt/media` (285 movies, 289 shows, 74 music artists — ~13 000 media files on a CIFS mount) with both this server and upstream Jellyfin at the pinned commit, remote metadata and image fetchers disabled on upstream so both were reading files only. Upstream was given the same mount path so `MD5(UTF-16LE(path))` agrees and rows compare directly.
Author
Collaborator

Fixed in 29630ba, 637f556 and f0a27b5.

ProbeRequest::extract_chapters was never set, so ffprobe was never asked and the
table was never written.

Verified against the real library: 36599 chapter rows, identical to upstream —
zero differences in either direction
(was 0 rows).

Getting there took two rounds of review and two rescans, because the first cut was
wrong in three ways the table itself revealed:

  • a bare number is a span of days to upstream, so a file whose chapters are
    titled 1, 2, 3 has them renamed — 25 rows here. is_a_time now reads
    [-]{d | [d.]hh:mm[:ss[.fffffff]]} with upstream's ranges, including the cap of
    just under 10675200 days that keeps a title like 20240115 a title
  • a chapter starting at or past the runtime is dropped
    (ChapterManager.SaveChapters:249) — 56 rows here, and a file reporting no
    runtime keeps none at all, which is what a lifted long? comparison does
  • a chapter is read back in the order it starts, not the order it was written

save_chapters had no test at all when first written: the delete before a rewrite,
the index from zero, the empty picture path and the unset date were the four things
it had to get right and all four could be broken with the suite green.

Fixed in `29630ba`, `637f556` and `f0a27b5`. `ProbeRequest::extract_chapters` was never set, so ffprobe was never asked and the table was never written. **Verified against the real library: 36599 chapter rows, identical to upstream — zero differences in either direction** (was 0 rows). Getting there took two rounds of review and two rescans, because the first cut was wrong in three ways the table itself revealed: - a bare number is a *span of days* to upstream, so a file whose chapters are titled `1`, `2`, `3` has them renamed — 25 rows here. `is_a_time` now reads `[-]{d | [d.]hh:mm[:ss[.fffffff]]}` with upstream's ranges, including the cap of just under 10675200 days that keeps a title like `20240115` a title - a chapter starting at or past the runtime is dropped (`ChapterManager.SaveChapters:249`) — 56 rows here, and a file reporting no runtime keeps none at all, which is what a lifted `long?` comparison does - a chapter is read back in the order it starts, not the order it was written `save_chapters` had no test at all when first written: the delete before a rewrite, the index from zero, the empty picture path and the unset date were the four things it had to get right and all four could be broken with the suite green.
Sign in to join this conversation.
No description provided.