# Line test on a seeding box, 2026-10-27 (R-1250, R-1261) — the hold failed as built, was fixed, and then held

Venue: demo-hp guest 9201 (controller 0.345.1, then `0.346.0-rc.1`; agent 0.166.0), a THROWAWAY qBittorrent ("qbline",
installed and removed through the product), seeding a private 3 GiB sparse file to DooPlex's qBittorrent (download
only, capped 3–4 Mbit/s, operator yes 2026-10-25). DooPlex's qBittorrent is reachable only inside the cluster, so it
dialled the seed through a small forwarder on 9201 (`tools/fwd.py`, LAN :6881 → the container). Method: reads of the
controller log, the agent journal, qBittorrent's own API and the interface counters. Nothing forced the line test.

## What the agent's slot is

demo-hp's slot is NOT 10:00: `slot_minute=95` (the agent's start line), so its test may start from 11:35 CET. Tester 1's
is 213 (13:33), demo-felhom's 20 (10:20). The seed was paused on DooPlex from 10:20 to 11:15 so it ran across 11:35
(`dooplex-add.txt`).

## Before the fix — four holds, four refusals (controller 0.345.1)

11:36, 11:51, 12:06, 12:21 CET: the controller held qBittorrent at 1 KiB/s, asked the agent, put the limit back
exactly (5898240 B/s), and the agent refused „not quiet" — 4.2, 4.2, 4.0, 4.0 Mbit/s while held
(`controller-upwatch-0345-refusals.txt`, `agent-demohp-day.txt`). **The 0.345.1 container's log was dropped when the rc
replaced it**; the refusal lines were recovered from this session's reads of the watcher's copies (said in that file's
header). The agent's journal holds the same four refusals independently.

Why, measured three ways:

1. `sec1-guest.txt` / `sec1-host.txt` (12:05:40–12:08 CET, one sample per second at the container, the guest and the
   host NIC): during the 12:06:17–12:06:32 hold the CONTAINER itself kept sending 2–11 Mbit/s each second — the
   forwarder was not the cause.
2. `udp-queues.txt`: the transfer is uTP (no TCP socket); every UDP queue was 0 — no buffering outside qBittorrent.
3. `qbsec-2-clean.txt` (the 12:21 hold) and `limitprobe.txt` (12:27, the controller's own 1 KiB/s value set by hand for
   60 s on the throwaway, then the exact value back; no test started): qBittorrent reports its limit as 1024 within a
   second, yet sends at full speed for **~14 s**, then 0. The agent reads the uplink 5–15 s after the call
   (`RequestSettle` 5 s + `RequestQuietWindow` 10 s), inside that drain — so every test on request was refused.

## The fix (operator's choice 2026-10-27: fix in the controller now) — felhom-controller `710ceac`

After the hold, `upwatch.waitDrained` polls each held app's OWN upload (`up_info_speed` / Transmission `uploadSpeed`)
until ≤ 16 KiB/s twice, 2 s apart (at most 90 s; an unreadable speed waits 20 s), and only then asks the agent. Five
tests, red-proved by four mutations (`redproof-r1250-drain.txt`).

## After the fix — the test ran through the hold (`0.346.0-rc.1` on 9201 from 13:24 CET)

`rc1-hold-proof.txt`: 13:39:56 held → 13:40:20 „the held app(s) slowed down after 22s — asking the agent" → three runs
94.5 / 93.4 / 94.4 Mbit/s → **94.5 Mbit/s** stored (`last_ok_at` 12:40:35Z) → 13:41:17 the limit back as it was
(5898240). The 50 % rule then KEPT the normal limit: the line moved 0.15 %, inside its 20 % band
(`qblimit.go` „kept"); no household flag; the alternative slot untouched (`upwatch-settings-after.txt`).

## Teardown (`teardown.txt`)

DooPlex: the torrent and its data removed, `/tmp/r1250` removed, 326 torrents as before, no category left. 9201: the
app removed through the product with `remove_hdd_data` and `remove_backups` FALSE — its download folder is the shared
library `media/torrents` (holding `movies`, `tv`, `.temp` from 14–15 October), and it made no backup today; its own
volume went with it. The forwarder stopped; the hand-made seed folder `r1250` and `/root/r1250` removed. Hub: nothing
provisioned. 9201 stayed on the rc until the per-box floor moved it to 0.346.0 (15:10 CET).