Audio rows take Width/Height from the embedded cover art #7

New issue

Closed

opened 2026-08-02 14:27:21 +02:00 by Claude · 1 comment

Claude commented

2026-08-02 14:27:21 +02:00

Collaborator

2 241 Audio rows record Width/Height of 1000x1000 — the dimensions of
the embedded cover-art stream — as the track's own. Upstream records none.

The attached picture is being read as if it were the item's video geometry.

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.

2 241 `Audio` rows record `Width`/`Height` of `1000x1000` — the dimensions of the embedded cover-art stream — as the track's own. Upstream records none. The attached picture is being read as if it were the item's video geometry. --- 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.

Claude added the

scanner

correctness

labels

2026-08-02 14:27:21 +02:00

Claude commented

2026-08-02 17:33:55 +02:00

Author

Collaborator

Fixed in 28efb22.

The dimensions came from the first stream carrying any, and a picture inside a
file is a video stream as ffprobe reads it. On the real library 3721 of 4889
tracks were given a resolution (the issue said 2241 — the real figure is
higher) where upstream writes zero for every one.

Review found is_audio was the wrong knob. Upstream takes the stream it
classified as a video (FFProbeVideoInfo.cs:263), and our own normalizer
already reads every video stream of a track as an embedded picture. Keying on
the stream type fixes the track case and a second one the issue did not name: a
film whose cover sits ahead of its picture was taking the cover's size, and a
subtitle reporting a size of its own could have answered too. No parameter
needed.

That case is latent in this library — 0 of 8188 films and episodes differ — but
4356 of its subtitle streams do carry dimensions, so it was one stream ordering
away from being wrong.

Fixed in `28efb22`. The dimensions came from the first stream carrying any, and a picture inside a file is a video stream as ffprobe reads it. On the real library **3721 of 4889 tracks** were given a resolution (the issue said 2241 — the real figure is higher) where upstream writes zero for every one. Review found `is_audio` was the wrong knob. Upstream takes the stream it *classified* as a video (`FFProbeVideoInfo.cs:263`), and our own normalizer already reads every video stream of a track as an embedded picture. Keying on the stream type fixes the track case and a second one the issue did not name: a film whose cover sits ahead of its picture was taking the cover's size, and a subtitle reporting a size of its own could have answered too. No parameter needed. That case is latent in this library — 0 of 8188 films and episodes differ — but 4356 of its subtitle streams do carry dimensions, so it was one stream ordering away from being wrong.

Claude closed this issue

2026-08-02 17:33:55 +02:00

Claude referenced this issue

2026-08-02 18:22:10 +02:00

A database scanned by an older build keeps what that build did not write #28