extrasRows

Cast, then More Like This — the tail every video-library type shares.

What committing a resolved run does to each plan row. The caller applies it to the RowList; nothing here touches a node.

did not load that row actions - one per plan row: "write" build the row from its result, or rewrite the one on screen "leave" the row on screen stays exactly as it is "remove" the row on screen goes "none" there is no row, before or after isStructureChanged - true when a row appears, disappears or changes slot shape, which is the only time the RowList layout needs writing playlistContentKind - the kind of the playlist row as committed ("unknown" when it is not on screen), or invalid when the plan has no playlist row

The current item, then the items after it, then the items before it — e.g. viewing episode 3 of 5 gives [3, 4, 5, 1, 2]. Server order is kept when the item is absent.

A digest identifying a row's source content.

Taken over the exact text the row is built from (the HTTP response body, on the Task thread that already holds it) rather than over the item nodes: comparing every field of every node on the render thread measured 252-306 ms per Refresh on a Stick 4K for a three-row movie.

Orders, filters and (for playlists) re-shapes and classifies one delivered row.

a playlist row, and "" for every other row

Is a delivered row identical to the one on screen? Such a row is not written at all: RowList redraws its row counter on any write to an on-screen row, even one that changes nothing.

Identity is the title plus a digest of the row's SOURCE content — the server's response body, or the item data a local row is built from — taken where that content is at hand (see digestOf). Anything the server changes about the row, including a field on an item whose id did not change (its played state, an image tag), changes the digest; so an unchanged digest means the rebuilt row would be identical, and a tile can never be left showing stale data.

An empty digest means the content could not be identified, and is never treated as unchanged: the row is rewritten, which is correct if it costs a counter redraw.

Has every slot of a run resolved? A run is committed to the RowList only then, in one pass.

The ordered rows for an item type.

Each row is an AA: kind - what to fetch; the orchestrator maps it to a request ("chapters" and "cast" are built from the item itself, with no request) shape - "PORTRAIT" | "WIDE" | "SQUARE"; finishRow may revise it (playlists) titleKey - translation key; titleArgs holds its placeholders when it has any itemId - the id the request is keyed on seasonId - season rows only currentId - rows that put the viewed item first excludeId - rows that drop the viewed item

A row whose request cannot be formed for this item (an episode with no season, a track with no album) is left out of the plan rather than planned and resolved empty.

What a playlist holds, for ItemDetails' Watched button and "Tracks"/"Items" label.

"unknown" covers both an empty playlist and one that failed to load — ItemDetails treats it as the safe default (no Watched button, "Items" label).

What a resolved row does to the list.

A failed request says nothing about what the item HAS, so it never removes a row — the same rule latestRows.drainReady applies to Home. Only an answered, empty row removes one.

RowList layout for the rows on screen: one slot and one row height per row, in order.