An episode file holding two episodes reports only the first #73

Closed
opened 2026-08-04 16:06:59 +02:00 by Claude · 1 comment
Collaborator

An episode file holding two episodes reports only the first.

/Items?Recursive=true — 11 episodes:

episode IndexNumberEnd upstream ours
Children of the Gods (1) / Children of the Gods (2) 2 absent
Air (1) / Air (2) 2 absent

A single file holding two episodes is numbered from its first to its last, and
upstream records the last as IndexNumberEnd. This port records only
IndexNumber, so a client cannot tell the file covers two.

jellyfin-naming already parses multi-episode names — the corpus has cases for
it — so the likely gap is between what the parse produces and what the scan
writes.

An episode file holding two episodes reports only the first. `/Items?Recursive=true` — 11 episodes: | episode | `IndexNumberEnd` upstream | ours | |---|---|---| | `Children of the Gods (1) / Children of the Gods (2)` | 2 | absent | | `Air (1) / Air (2)` | 2 | absent | A single file holding two episodes is numbered from its first to its last, and upstream records the last as `IndexNumberEnd`. This port records only `IndexNumber`, so a client cannot tell the file covers two. `jellyfin-naming` already parses multi-episode names — the corpus has cases for it — so the likely gap is between what the parse produces and what the scan writes.
Author
Collaborator

Fixed. Both were broken on the read path and the write path — the live
databases are upstream's own scan, so the columns were already populated and
this server still reported nothing.

NormalizationGain is not from the probe. AudioFileProber.cs:456 reads
the tag REPLAYGAIN_TRACK_GAIN out of the tag library's additional fields,
strips a case-insensitive db suffix, and stores it if it parses finite —
audio only. DtoService.cs:1144 answers -18 - LUFS when a LUFS is stored and
the gain otherwise. LUFS itself is written only by a scheduled loudness pass
this port does not run.

That the tag library reads it rather than ffprobe is load-bearing: 42 of the
83 gain-carrying files in the library are MP3s whose gain lives in an APEv2 tag
ffprobe does not report at all.

IndexNumberEnd has no column — it is serialized into BaseItems.Data.
jellyfin-naming already parsed it correctly; the scan dropped it, the write
never carried it, and the read never looked in the blob.

field before after
NormalizationGain 30 0
IndexNumberEnd 11 0

Gains from a real scan of six library files are bit-identical to upstream's
answer key, and a rescan still writes nothing — every row's Data,
DateLastSaved and NormalizationGain byte-identical after a second pass.

Fixed. Both were broken on the read path **and** the write path — the live databases are upstream's own scan, so the columns were already populated and this server still reported nothing. **`NormalizationGain`** is not from the probe. `AudioFileProber.cs:456` reads the tag `REPLAYGAIN_TRACK_GAIN` out of the tag library's additional fields, strips a case-insensitive `db` suffix, and stores it if it parses finite — audio only. `DtoService.cs:1144` answers `-18 - LUFS` when a LUFS is stored and the gain otherwise. `LUFS` itself is written only by a scheduled loudness pass this port does not run. That the tag library reads it rather than ffprobe is load-bearing: **42 of the 83 gain-carrying files in the library are MP3s whose gain lives in an APEv2 tag ffprobe does not report at all.** **`IndexNumberEnd`** has no column — it is serialized into `BaseItems.Data`. `jellyfin-naming` already parsed it correctly; the scan dropped it, the write never carried it, and the read never looked in the blob. | field | before | after | |---|---|---| | `NormalizationGain` | 30 | **0** | | `IndexNumberEnd` | 11 | **0** | Gains from a real scan of six library files are bit-identical to upstream's answer key, and a rescan still writes nothing — every row's `Data`, `DateLastSaved` and `NormalizationGain` byte-identical after a second pass.
Sign in to join this conversation.
No description provided.