6 Commits

Include renames

Author	SHA1	Message	Date
admin	710ceace12	fix(R-1250): the line-test hold waits until the held app has really slowed down before asking the agent ... Measured on demo-hp 2026-10-27: qBittorrent 5.2.4 kept sending at full speed for ~14 s after its limit fell to 1 KiB/s; the agent reads the uplink 5-15 s after the call, so every test on request was refused "not quiet" (four tries in an hour, 4.0-4.2 Mbit/s). waitDrained polls each held app's own upload (qBittorrent up_info_speed, Transmission uploadSpeed) until <= 16 KiB/s twice, 2 s apart, at most 90 s; an unreadable speed waits 20 s. Tests TestR1250_* (five), red-proved by four mutations.	2026-10-27 13:23:00 +01:00
admin	26191911c4	R-1292: qBittorrent's 50 % rule owns the NORMAL limit only (up_limit through app/preferences), never the current speed mode's slot. Test with the alternative mode on, red-proved. Commit only.	2026-10-26 13:01:31 +01:00
admin	a79a292d72	R-1261: the line hold holds every running seeder, drops the record of an app removed while held, and puts back the qBittorrent slot it held (alternative speed). Red-proved. Commit only.	2026-10-25 20:38:28 +01:00
admin	046b808792	upwatch: hold a seeding torrent app for one line test, then put its limit back exactly (R-1250) ... When the agent waits for quiet and qBittorrent or Transmission runs: record the limit first, hold at 1 KiB/s, ask the agent for a test on request, put the old limit back (deferred; a household change during the test stays). Start-up puts back a limit a killed controller left; the 50 % rule skips while a hold record exists. Commit only.	2026-10-24 13:19:07 +02:00
admin	ed1011b088	v0.342.0 (unreleased): the upload watch reads the host's weekly line test (GET /host/line-test, agent >= 0.164.0); qBittorrent's limit = 50 % of the TESTED line only (D41), the watch uses the higher of test and push floor, the system page names the source; red-proved	2026-10-24 08:59:57 +02:00
admin	a9c1997fbc	v0.342.0 (unreleased): the upload and CPU watch — an app that sends or burns far more than its own numbers explain is one operator-only alarm; the line learnt from the off-site push; qBittorrent's default upload limit (never over the household's) ... internal/upwatch: exact per-container counters from the Docker Engine API, per-app judging (upload >= max(5 Mbit/s, 25% of the line) for 15 min; CPU >= max(150%, 50% x cores) for 30 min), explainers qBittorrent / Transmission / Plex, app_unexplained_upload / app_unexplained_cpu + _cleared (hub 0.169.0). The off-site push is sampled once a second for the line (a lower bound). qBittorrent limit = 50% of the line, the household's limit always wins. 20 red-proofs. Spike + design: felhom.eu audits/SPIKE-upload-watch-2026-10-23.md, architecture/08 section 9. Not released.	2026-10-23 21:26:09 +02:00