Rclone Streaming Optimizer¶

The rclone streaming optimizer measures how an InfiniDysk-backed DUMB-managed rclone instance behaves on the current deployment. It accounts for the combined effects of the provider, network, CPU, memory, cache storage, InfiniDysk, and rclone instead of assuming one flag set is right for every server.

The optimizer is currently limited to InfiniDysk. It appears on the specific rclone service page, not as an InfiniDysk configuration tool. When an associated test is active, the InfiniDysk service page shows a link to that rclone job.

What the test actually reads¶

Each candidate uses this path:

DUMB-managed Arr instance -> active InfiniDysk category
  -> production rclone mount/content/<category> (metadata discovery only)
  -> safe mount-relative read path
  -> optimizer reader
  -> isolated read-only rclone shadow mount
  -> InfiniDysk WebDAV
  -> InfiniDysk's configured Usenet provider(s)

The shadow mount uses the same rclone remote/configuration as the production mount, but has its own mount path, VFS cache directory, and loopback RC port. It does not stop the production mount, purge its cache, or reuse its cache for candidate reads.

DUMB uses the production mount only for bounded directory metadata discovery. It does not measure file reads there because that would reuse the production VFS cache and make candidate comparisons unreliable. Each category entry is resolved to a safe mount-relative read path and opened on every isolated shadow mount. For a regular entry this can be content/radarr-infinidysk/example.mkv; a symlink-backed entry can resolve to its mount-internal backing path while the UI retains the friendly category path.

These are real provider reads. They can consume provider traffic and are subject to provider connection, automation, and acceptable-use policies.

Measurements¶

For every candidate and selected file, DUMB records:

• file-open time;
• time to first byte;
• time to fill the configured startup buffer (32 MiB by default);
• early/sequential throughput;
• seek latency near the end of the file;
• rclone process memory, CPU, cache use, and RC statistics; and
• InfiniDysk active reads, bytes, errors, provider latency, retries, circuit state, failover data, and stream-trace count when the maintained InfiniDysk API supplies them.

Failed or unavailable files remain visible in the report but are excluded from performance scoring. The recommendation score favors startup time and first-byte latency while also considering seek latency, throughput, resource use, and excluded/error samples.

The report distinguishes trace capture unavailable from no matching retained trace. If InfiniDysk tracing cannot be enabled, rclone performance measurements can still complete, but provider-level event correlation is explicitly marked unavailable instead of being presented as a path-matching result.

Reading InfiniDysk provider evidence¶

The first four values in each expanded provider-evidence panel come from the InfiniDysk overview window captured after that candidate. They are not isolated to the candidate and can include unrelated InfiniDysk traffic. The next five fields are an aggregate of all retained stream traces matched to that candidate's selected paths and test window. Those candidate-matched fields remain visible when no trace is available and show not available instead of disappearing. Individual matched trace rows appear below the aggregate. This distinction is one reason the media server and InfiniDysk should be idle during testing.

Content selection¶

Open the InfiniDysk-backed rclone service and select Rclone Optimizer. DUMB first reuses the same Arr-to-InfiniDysk category derivation used during integration setup. Only enabled Radarr, Sonarr, Lidarr, and Whisparr instances whose core_service includes infinidysk contribute categories. For example, a Radarr instance named InfiniDysk produces radarr-infinidysk.

The configured rclone instance supplies the user-defined mount base through mount_dir plus mount_name. DUMB scans only <mount>/content/<active-category>, reports missing/empty categories in the panel, and suggests a small, stratified set:

• recently modified content, which is more likely to be warm;
• older content, which is more likely to be cold;
• a large/high-bitrate candidate; and
• a typical file near the middle of the observed set.

These files are representative automatic suggestions, not mandatory choices. They are pinned to the top of the picker and labeled with the selection reason, such as Recent / likely warm, Older / likely cold, Largest / high-bandwidth candidate, or Typical / median-age candidate. Keep the automatic set, replace it with your own files, or mix automatic and manual choices up to the eight-file limit. Restore automatic selection returns to the suggested starting set after manual changes.

Age is only a cache-likelihood heuristic. It does not prove whether an article is cached by InfiniDysk or a provider. The report keeps recent/likely-warm and older/likely-cold startup results separate, while InfiniDysk's live metrics and stream traces explain what happened during the reads.

You can replace the automatic selection with any listed media files. Select between one and eight files. The scan is intentionally bounded by file count and time so discovering content does not recursively enumerate an unlimited remote library. No /mnt/debrid/... mount path or category name is hard-coded into the optimizer.

Candidate matrix¶

The optimizer does not try every possible rclone flag permutation. That would consume excessive time and provider traffic while producing noisy results. Instead, it tests known-shape profiles:

The report deliberately separates the settings into five roles:

The UI shows the complete optimizer-relevant effective settings for every candidate, including current-to-tested changes and the role of each value. The winning recommendation is therefore a bundle recommendation, not a claim that every displayed setting was individually optimized.

Preserved flags are outside the optimizer's intended streaming dimensions and normally should not determine this comparison. However, an unusual custom rclone flag can still change runtime behavior and must be reviewed manually. Their values are intentionally omitted from public job reports because rclone commands can contain credentials or other private values. The remote source, provider credentials, filtering, and user behavior flags remain preserved, and the production mount command is not modified during testing. The shadow process necessarily substitutes its temporary mount path and cache directory, binds a loopback RC endpoint without production RC credentials, forces read-only behavior and a test log level, and optionally adds the fixed bandwidth ceiling. Those isolation controls are not candidate tuning dimensions.

In particular, DUMB recommends --dir-cache-time=1w because InfiniDysk uses rclone RC vfs/forget notifications to invalidate affected directory metadata when content changes. This avoids a constant stream of WebDAV metadata refreshes. It also recommends --vfs-cache-max-age=1w so recently streamed file data can stay warm longer and reduce repeated provider reads; --vfs-cache-max-size remains the primary disk-usage constraint. Existing values longer than one week are preserved. These two timeouts are architecture guidance shared by every candidate, not values inferred from the short benchmark.

Before testing, DUMB checks that InfiniDysk RC notifications are enabled, point to the associated loopback rclone RC endpoint, use matching credentials, and can reach that endpoint. A failed check does not hide the one-week recommendation, but the report warns that directory changes may remain stale until the operator repairs RC or chooses a shorter fallback --dir-cache-time.

--vfs-cache-mode establishes VFS behavior and can matter, but is tested only as a bundled prerequisite. The UI explains the expected streaming relevance of each displayed flag; these statements describe expected scope, not a guarantee that arbitrary custom combinations can never influence playback.

Safety limits¶

The safety-limit values initially shown in the optimizer are generic starting placeholders, not recommendations. DUMB does not derive them from the deployment's CPU, RAM, cache disk, ISP bandwidth, InfiniDysk activity, or provider policy. Review and change every safety limit for the current hardware and provider before starting a job. The separate one-week InfiniDysk cache-timeout guidance described above is an architecture recommendation, not a safety-limit placeholder or benchmark result. The UI provides a native tooltip on each control explaining its purpose.

Configure the limits before starting a job:

Testing stops early when InfiniDysk indicates a provider circuit is open or reports strong throttling/authentication/rate-limit signals. Errors, retries, and failover remain in the report. This reduces provider risk but cannot guarantee that a provider will permit benchmarking; review your provider's rules and keep concurrency/data limits conservative.

Background jobs and notifications¶

The job continues in the DUMB backend when you close the panel or navigate away. The rclone service page keeps an active-job banner, and the frontend posts a completion or failure toast while it is open. If DUMB notifications are configured for the optimizer event types, the backend can also queue the completion/failure event.

If DUMB restarts during a test, the job is marked interrupted, the temporary mount/cache is cleaned up, and the matrix is not resumed. Start a fresh test so candidate conditions remain comparable.

Each candidate verifies that its isolated shadow mount is no longer mounted before the result is accepted. Before a job can report completed, DUMB also verifies that all job shadow mounts, the runtime directory, and the candidate cache directory are gone. The rclone page reports those three cleanup checks. If cleanup cannot be verified, the job fails instead of presenting a completed recommendation, leaves the runtime path available for a later safe retry, and retries cleanup during finalization and the next DUMB startup.

Apply and rollback¶

Finishing a test creates a report and recommendation. It does not change rclone.

1. Review every candidate's complete settings/roles, warm/cold samples, exclusions, resources, cleanup status, and InfiniDysk evidence.
2. Select Apply recommendation.
3. DUMB merges only the recommended optimizer flags into the saved rclone command.
4. DUMB stops rclone, detaches and verifies removal of the previous production FUSE mount, restarts the process, then requires the new mount to remain accessible and stable before reporting success.

The pre-apply command is stored privately in the job record. Select Roll back to restore it through the same stop, verified-unmount, restart, and mount-readiness sequence. If apply fails, DUMB attempts that rollback automatically. If the old mount cannot be detached, DUMB refuses to start another rclone against the stale mountpoint and reports the failure for operator attention.

Provider-risk guidance¶

• Start with Quick, one stream, and a small data budget.
• Do not run repeated tests back-to-back merely to chase small score changes.
• Avoid testing while normal users are already saturating the provider or ISP connection.
• Treat retries, failover, open circuits, authorization failures, and rate-limit messages as reasons to stop and investigate.
• Do not assume older content is uncached or recent content is cached.
• Keep the report as deployment-specific evidence; another user's result is not a universal rclone preset.

Related guides¶

• rclone service
• InfiniDysk
• Service pages
• Process Management API