kenzuya/unshackle
1
0
Fork 2
mirror of https://github.com/unshackle-dl/unshackle.git synced 2026-11-14 13:05:09 +00:00
Code Issues Packages Projects Releases Wiki Activity

Deployed 80f2b8f with MkDocs version: 1.6.1

Browse Source
This commit is contained in:
2026-09-07 02:17:11 +00:00
parent 35ab58330d
commit e911e9b165
7 changed files with 654 additions and 657 deletions
Download Patch File Download Diff File Expand all files Collapse all files
guide/cli-reference/index.html
+1 -1
View File
@@ -3392,7 +3392,7 @@ and keeps the service's numbering unchanged. Pick an order that covers the whole
<tr>
<td><code>--download-processes</code></td>
<td><code>1</code></td>
<td>Split large segment batches (24+) across this many download processes to exceed the single-process throughput cap on multi-gigabit connections. Ignored while a speed limit is set: the cap is one shared budget, which extra processes cannot share, so the download stays in a single process.</td>
<td>Split large segment batches (24+) across this many download processes to exceed the single-process throughput cap on multi-gigabit connections. Ignored while a speed limit is set: the cap is one shared budget, which extra processes cannot share, so the download stays in a single process. Also ignored when the service HTTP session carries state a child process cannot rebuild, such as a custom TLS adapter.</td>
</tr>
<tr>
<td><code>--continue-downloads</code></td>
guide/downloading/index.html
+2 -2
View File
@@ -3923,11 +3923,11 @@ configured proxy providers), or a <code>provider:region</code> form.</p>
</tr>
<tr>
<td><code>--adaptive-workers</code></td>
<td>Opt-in: start with a moderate per-track worker count and ramp it up or back off based on measured CDN throughput and errors, capped at <code>--workers</code>. Off by default (fixed worker count).</td>
<td>Opt-in: start the per-track worker count at <code>--workers</code>, reduce it when the CDN returns errors, then raise it again while the extra workers add measured throughput. The count never goes above <code>--workers</code>. Off by default (fixed worker count).</td>
</tr>
<tr>
<td><code>--download-processes N</code></td>
<td>Opt-in: split a large segment batch across <code>N</code> download processes, each with its own worker pool. A single process tops out around 1.3 Gb/s (Python interpreter limit); <code>2</code> reaches 2.5GbE line rate on fast CDNs. Only engages for batches of 24+ segments. Ignored while <code>--speed-limit</code> (or serve's <code>global_speed_limit</code>) is set: the cap is one shared budget, which extra processes cannot share, so the download stays in a single process. Default <code>1</code>.</td>
<td>Opt-in: split a large segment batch across <code>N</code> download processes, each with its own worker pool. A single process tops out around 1.3 Gb/s (Python interpreter limit); <code>2</code> reaches 2.5GbE line rate on fast CDNs. Only engages for batches of 24+ segments. Ignored while <code>--speed-limit</code> (or serve's <code>global_speed_limit</code>) is set: the cap is one shared budget, which extra processes cannot share, so the download stays in a single process. Also ignored when the service HTTP session carries state a child process cannot rebuild, such as a custom TLS adapter. The download stays in a single process instead of running with the wrong settings. Default <code>1</code>.</td>
</tr>
<tr>
<td><code>--continue-downloads</code></td>