mirror of
https://github.com/austinried/subtracks.git
synced 2026-11-10 15:11:58 +01:00
austinried
4652430f73
Two things a 3k-song playlist turned up, plus the hero's downloaded state. - The platform runs about eight downloads at a time, but a bulk action handed it every song at once. Three thousand pending requests meant a notification flood, and a poll tick that rewrote every row's bytes/total, so the whole list churned ten times a second. Now a bulk action only records the songs and hands over at most IN_FLIGHT_LIMIT, oldest first, promoting the next as each finishes, so our row state mirrors what is actually running and a cancel only has to reach what is in flight. - Cancelling was therefore unusable at that size. It now touches at most the in-flight requests instead of thousands, and the rows wait behind it. - A queued row with no engine id is waiting its turn, not lost, so reconcile no longer re-enqueues the whole list on every pass; a row whose engine entry vanished goes back to waiting and the next promote picks it up. A song that cannot be handed over fails instead of being retried every tick. - Requests follow the order the screen shows: artist songs resolve through the same albums ordering the artist page uses, so they were the one list that did not. - The hero's fully-downloaded state shows the downloaded glyph rather than a bin, and tapping it asks before deleting, naming the album or playlist and the space it frees.