Queue as a priority list for Play now: fetch ahead in order, play whatever's ready
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
This proposal depends on Play now (#124) landing first and describes changes in both the app and continuo, including a per-account prioritized fetch queue and playback selection. Read the Play now implementation and the queue and playback entry points in both projects; the issue does not name specific files or tests. Done means fetching follows queue priority and concurrency limits, ready songs can play while the next item downloads, and owned-song order, shuffle, and repeat behavior are preserved.
Written by the indexing model from the issue text.
Description
An idea from the user (2026-10-26), building on Play now (#124, continuo#12).
Prioritised fetching. When several Play now songs are in the queue (say 5), continuo starts fetching them all ahead of time, with priority by queue position. The next song gets the fastest peer and first claim on bandwidth, and later songs follow.
The queue as a suggestion, not a strict order. If the next song's download isn't ready but a later Play now song (or any song you own) is, play the ready one now. That keeps the music going while the next song finishes downloading, and it slots back in as soon as it's ready.
Notes for when this is built
- continuo: a per-account fetch queue with priorities, reordered when the app's queue changes (
POST /v1/play-now/queuewith the ordered recording IDs), plus concurrency limits (e.g. 2 downloads at once, nearest first). - App: before advancing, ask whether the next item is playable (owned, downloaded, or a Play now stream past its start threshold). If not, pick the nearest one that is, and show that the order shifted ("Up next: X, still downloading").
- Never reorder songs you own among themselves; this only works around songs still downloading. Respect shuffle and repeat semantics.
- Depends on Play now landing first (alpha.31).
- Dominant language
- Kotlin
- Stars
- 1
- Forks
- 0
- Avg merge
- 44m
- Merged PRs (30d)
- 76
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from isaacault/polyphony
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
Maintainers usually reply within 1 day
-
area/cast priority/p2 type/verification
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
-
area/playback priority/p2 type/feature
Difficulty 4/5 3-5 days Newbie friendliness 48/100
Maintainers usually reply within 1 day
-
area/transcoding priority/p2 type/feature
Difficulty 4/5 3-5 days Newbie friendliness 45/100
Maintainers usually reply within 1 day
All issues in isaacault/polyphony
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
OpenAPITools/openapi-generator#25454 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
navikt/mock-oauth2-server#1149 ·
Maintainers usually reply within 1 day
-
triaged
Difficulty 1/5 Under an hour Newbie friendliness 65/100
Maintainers usually reply within 1 day
-
priority: high scope: frontend type: bug
Difficulty 2/5 1-3 hours Newbie friendliness 79/100
GonsiorHack/czyPrzejade#12 ·
-
afk-ok area:frontend size:S
Difficulty 2/5 1-3 hours Newbie friendliness 87/100
enorm-labs/event-junkie#4154 ·
Maintainers usually reply within 1 day