mirror of
https://github.com/screentinker/screentinker.git
synced 2026-08-14 06:16:20 -06:00
bc00bc1eb1
PlaylistController.next() asks for a playlist refresh on every item advance, and requestPlaylistRefresh() emits a full device:register. The server's register handler runs 7+ statements plus the identity/fingerprint path and rebuilds the playlist payload, then pushes the whole playlist back down. So a panel showing a 10-second image re-registered six times a minute, indefinitely, and each reply fed a fresh playlist into a controller that had to diff it — which is what kept the #234 restart loop supplied. It was buying nothing. The heartbeat already refreshes every 4th beat (60s), so the periodic pull this duplicated happens either way. Throttled at the single chokepoint rather than by editing callers, because the callers have genuinely different intents — network-came-back, service-connected, per-item, and the heartbeat itself — and ranking them would be guesswork. A shared floor keeps every caller's meaning: recovery paths still refresh, they just cannot stack. The window sits just under the heartbeat's own 60s so the two interleave instead of the throttle systematically eating the pull we are relying on. Measured on the reproduction over 240s: 9 registrations for 9 item plays before, 3 for the same 9 plays after, with playback unchanged. The saving scales with how short the items are — a 10s item goes from six refreshes a minute to about one. Does NOT change what a refresh does, only how often one may be asked for. |
||
|---|---|---|
| .. | ||
| src | ||
| build.gradle.kts | ||
| proguard-rules.pro | ||