fix: cut playlist helpers from 4 to 1 by standing down the auto-load cascade - #677
Merged
Conversation
…ed rows Confirmed on-device that the previous PR does not work: tile_scan reported rowsCollapsed:1 and rowsCollapsed:2 on real runs, yet the blank slots stayed exactly where they were, the single visible helper still sat in 4th position, and navigating down still had to step through all four. yt-virtual-list positions rows by transform from its own layout math over its data model, so a slot stays reserved whether or not the row element is displayed. Collapsing the row was never going to reclaim the space. It is also unsafe, which I should have caught before shipping it — this repo already removed the same pattern. 6a340fc dropped opacity:0 on helper rows because the virtual list RECYCLES .TXB27d nodes (repointing an existing row at new content instead of creating one), so inline styles ride along to whatever video reuses that node — producing black gaps and navigation hangs. An inline display:none does the same thing, only worse: a real video silently missing instead of a visible gap. Reverted to plain tile removal and left the reasoning in place so it isn't attempted a third time, including why the data model — the only layer that would actually work — is out of reach: 654577e removed clearStaleHelpersFromVListData after confirming every Polymer API (set/splice/notifyPath/render) is undefined on Tizen 5.0.
KrX3D
changed the title
… running Two mechanisms load the same playlist at once and they are badly out of step. On a 68-video all-watched playlist: 17:53:01.780 keep-one.register BO7rZs_CYQs (initial response) 17:53:01.908 auto_load.trigger attempt 0 17:53:02.058 continuation 15 items 17:53:02.060 keep-one.register yiCntUc1KKk 17:53:02.262 continuation 15 items 17:53:02.265 keep-one.register WKj_hyauRZ8 17:53:03.108 60 items present, all from YouTube's own responses 17:53:04.4 .. 17:53:12.3 background collector, batches 2-5 17:53:12.375 prefetch_ready 53 items, hasMore:false YouTube delivered four batches in ~1.3s, one helper each, while the background collector — paced at 2.5s per fetch to avoid the server rejections fixed earlier — was still on its second and only finished ten seconds later, by which point its 53 merged items had nowhere to go. That is the out-of-sync behaviour reported alongside the helper complaint. IMPORTANT — what is NOT established: whether our schedulePlaylistAutoLoad cascade actually causes those rapid refetches. The competing explanation is simply YouTube refilling an underfull viewport on its own: each batch filters down to a single helper while the screen fits four or five rows, so the list is starved and fetches again regardless of what we do. Our triggers and YouTube's fetches interleave closely enough in this log that neither ordering settles it, and auto_load.verify cannot arbitrate — its counts come from __ttCurrentPlaylistItems, which storePlItems dedupes and which the background collector also feeds. This change is therefore also the experiment that separates the two. When batch collect is active the cascade stands down, so the prefetched batches can land as one merged continuation carrying no further token — meaning hasContinuation is false, the keep-one branch never runs for it, and the single initial helper is retired and removed. If helper count drops to one, our cascade was driving the refetches. If it stays at four, YouTube's viewport refill is, and no DOM-side change will help because each stranded helper lives in the virtual list's data model, unreachable on Tizen 5.0 (654577e). Either way this removes a redundant second loader that finishes ten seconds late. Both cascade call sites log when they stand down instead of doing it silently. Only affects users with enablePlaylistBatchCollect on.
KrX3D
force-pushed
the
fix/revert-row-collapse
branch
from
August 29, 2026 18:31
51787c5 to
1029077
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two commits.
1. Revert the row collapsing.
rowsCollapsed:1/:2fired yet the blank slots stayed and the visible helper still sat 4th — yt-virtual-list positions rows by transform from its data model, so the slot is reserved regardless of the row's display. It was also unsafe:6a340fchad already removedopacity:0on helper rows because the list recycles.TXB27dnodes and inline styles ride along to whatever video reuses them.2. Stand down the auto-load cascade while batch collect runs.
Not established: whether our cascade actually causes those refetches. The competing explanation is YouTube refilling an underfull viewport on its own — each batch filters to a single helper while the screen fits 4–5 rows, so the list is starved and fetches again regardless. The triggers and fetches interleave too closely here to settle it, and
auto_load.verifycan't arbitrate: its counts come from__ttCurrentPlaylistItems, whichstorePlItemsdedupes and the background collector also feeds.So this doubles as the experiment. Helpers drop to 1 → our cascade was driving it. Helpers stay at 4 → YouTube's viewport refill is, and no DOM-side change will help, since each stranded helper lives in the virtual list's data model (unreachable on Tizen 5.0,
654577e).Either way it removes a redundant second loader that finishes ten seconds late.