yonlu/yellowjacket
1
1
Fork 0
Code Issues 53 Pull Requests Actions Packages Projects Releases 13 Wiki Activity

slskd: the transfer limit is per daemon where Soulseek's politeness is per peer #272

New Issue
Closed
opened 2026-09-26 21:14:45 +00:00 by yonlu · 2 comments
yonlu commented 2026-09-26 21:14:45 +00:00
Owner
Copy Link
Copy Source

slskd is capped at one transfer per provider (kindConcurrency[KindSlskd] = 1). The help text says this is the polite setting, and politeness on Soulseek is about how many files you ask one peer for at once: downloads from two different users do not compete for anyone's upload slot, and slskd already queues per peer. So one slow peer serialises every other Soulseek download behind it.

Since #263 that blocking is bounded, because a peer that sends nothing for 10 minutes is abandoned. A peer that trickles bytes still holds the slot for as long as it takes, though.

Direction

Keep at most one grab per peer and allow a small number across peers. The manager's semaphores are per provider today, so this needs a semaphore keyed on (provider, Candidate.Origin) for Soulseek alongside the provider cap, and the maxConcurrent default and help text for slskd revisited.

A related gap: collect finds files under <downloadsPath>/<remote folder name>/, which is slskd's layout. Two concurrent grabs whose folders share a name (two different albums both called "Greatest Hits") would write into the same slskd directory. That is harmless at concurrency 1 and has to be handled before raising it.

slskd is capped at one transfer per provider (`kindConcurrency[KindSlskd] = 1`). The help text says this is the polite setting, and politeness on Soulseek is about how many files you ask *one peer* for at once: downloads from two different users do not compete for anyone's upload slot, and slskd already queues per peer. So one slow peer serialises every other Soulseek download behind it. Since #263 that blocking is bounded, because a peer that sends nothing for 10 minutes is abandoned. A peer that trickles bytes still holds the slot for as long as it takes, though. ## Direction Keep at most one grab per peer and allow a small number across peers. The manager's semaphores are per provider today, so this needs a semaphore keyed on `(provider, Candidate.Origin)` for Soulseek alongside the provider cap, and the `maxConcurrent` default and help text for slskd revisited. A related gap: `collect` finds files under `<downloadsPath>/<remote folder name>/`, which is slskd's layout. Two concurrent grabs whose folders share a name (two different albums both called "Greatest Hits") would write into the same slskd directory. That is harmless at concurrency 1 and has to be handled before raising it.
yonlu added the
Priority
Low
4
Kind/EnhancementPlatform/DesktopArea/Downloads labels 2026-09-26 21:14:45 +00:00
yonlu self-assigned this 2026-09-26 21:28:17 +00:00
yonlu added the
Status
In Progress
 label 2026-09-26 21:28:17 +00:00
yonlu commented 2026-09-26 21:28:18 +00:00
Author
Owner
Copy Link
Copy Source

Starting work on this on fix/272-slskd-per-peer.

Starting work on this on `fix/272-slskd-per-peer`.
yonlu commented 2026-09-26 21:28:30 +00:00
Author
Owner
Copy Link
Copy Source

Stacked on fix/271-slskd-search-recall (PR #267). Approach: a per-(provider, peer) semaphore in the manager's grab path beside the provider cap, the slskd default raised to a small cross-peer number, and each slskd grab collecting only the files it enqueued so two same-named folders from different peers cannot mix.

Stacked on fix/271-slskd-search-recall (PR #267). Approach: a per-(provider, peer) semaphore in the manager's grab path beside the provider cap, the slskd default raised to a small cross-peer number, and each slskd grab collecting only the files it enqueued so two same-named folders from different peers cannot mix.
yonlu closed this issue 2026-09-27 01:45:21 +00:00
gitea-actions bot removed the
Status
In Progress
 label 2026-09-27 01:47:36 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Area/Design
Area/Downloads
Area/Explore
Area/Library-UI
Area/Metadata
Area/Packaging
Area/Player
Area/Queue
Area/Settings
Area/Shell-Nav
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
 Platform/Android
Platform/Desktop
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Medium
3
The priority is medium
Priority
Low
4
The priority is low
Reviewed
Confirmed
1
Issue has been confirmed
Reviewed
Duplicate
2
This issue or pull request already exists
Reviewed
Invalid
3
Invalid issue
Reviewed
Won't Fix
3
This issue won't be fixed
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
In Progress
Somebody is actively working on this right now
No labels Area/Downloads Kind/Enhancement Platform/Desktop
Priority
Low
4
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
logan yonlu
No Assignees yonlu
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: yonlu/yellowjacket#272