62 releases 112 tags

RSS feed

• v1.48.0 78ae09a303

  Compare

  v1.48.0 Stable

  Ghost released this 2026-11-10 08:59:51 +00:00 | 35 commits to main since this release

  Deprecated

  • WarpTune: calib_clock_after_voltage (Oliver, 2026-11-06). A curve job measures every clock's own voltage, so the order has no meaning; the key is still read for a job journaled by an older build and will be removed from the docs and the config later.

  Added

  • WarpTune: the calibration measures a clock–voltage curve, down to the first failure and up when the reference is short (Oliver, 2026-11-06). A full calibration no longer stops calib_max_steps below a reference: every voltage stage walks down in 10 mV steps to the first failed step (the hard floors stay: the firmware's lowest offered voltage or WarpAxe's regulatorMinMv, calib_hard_min_mv, the board table; calib_max_steps now bounds the quick re-check alone), and a reference that is short of good no longer ends the stage — the search walks up in 10 mV steps to the first stable voltage: a step under the hand clock up to the hand voltage, a step above it with beyond_spec (or any step while no stock is configured) up to the ladder's ceiling, the hand point itself never (decision 4: it is measured downward only, stays the reference, the ceiling for steps under its clock and the restore point). The found voltage gets one more full share verdict before it counts (verifying on the card); the applied point keeps the calib_margin_mv reserve, capped at the step's ceiling. A BitForge Nano on WarpAxe without a configured stock can end above the fine ladder's 1020 mV at 625 MHz; on Forge-OS v1.8 the Max search walks from 1200 mV past the old 1140 mV limit. The clock search is a curve and on by default wherever the supply rating is known (calib_clock = false switches it off; the dialog's checkbox pre-sets from it): after the Eco stage the plan grows by the next clock below, each clock starting at the voltage the last one found and walking down to its first failure, until the J/TH has not improved for two clocks in a row, the voltage floor is reached, or the curve is three clocks (75 MHz) under its start clock (Oliver: a job stays under a day) — the clock with the best measured J/TH becomes the Eco cap (without an eco_cap_mhz and without a calibrated Eco cap — a newly connected miner — the Eco curve starts at the hand point's clock: its first own stage is the step below, seeded with the voltage the hand point's stage found, and every first calibration measures Max and Eco); after the Max stage the plan grows by the next clock above, each clock starting at the last found voltage and climbing as it needs, until the first limit over its window (the voltage ceiling, chip or VR temperature, core current, the power limit, the supply's reserve, the fan). Without beyond_spec the Max curve ends at the maker's top step (bounded by ladder_cap_mhz / calib_clock_max_mhz; climbing above the hand point inside the maker's table is intended) and no step is written above its own table voltage — the hand voltage at the hand clock and under it; with it (and a supply that fits) clocks above the hand point are searched up to the maker's beyond-spec maximum / calib_clock_max_mhz, their voltage up to the ladder's ceiling — found clocks are beyond_spec steps, Max mode only. The ladder steps between two measured clocks take a voltage interpolated between them (never above the higher neighbour, never above their own reference). The calibration dialog shows where Max ends and what sets it ("Max is searched up to 640 MHz / 1140 mV — limit: ladder_cap_mhz and voltage_max_mv in the miner settings", or the maker's top step at its own table voltage, or the power supply / board power limit, or the beyond-spec maximum — from the same source the sidecar uses for the clock ceiling), the expected duration ("about 6 h to 11 h", least and most from the plan and the miner's share rate) and, with beyond_spec, the search's ceiling ("clocks up to 700 MHz, voltage up to 1200 mV"); a hand point that does not run stable at its own voltage during the job is said clearly on the card and in the result ("Your hand point 640 MHz @ 1140 mV did not run stable during the calibration — raise its voltage or lower its clock", one journal line hand_point_unstable) and is still never raised; the timeout calib_timeout_s is per step as before (it starts over with every verdict), so a longer plan needs no longer timeout. The old clock stages (eco_clock / max_clock) remain in the code only for a job journaled before this change. A beyond_spec checkbox on the WarpTune Desktop miner settings ("Beyond the maker's specification (Max mode only)", off by default, 8 languages) with its warning sentence; it can be set only when the supply fits — a rating known (entered at the miner, psu_max_watts, or the board's stock supply), a power limit from a hardware figure, and the hand point's measured draw under the way-up limit — otherwise it is locked with the reason ("supply rating unknown — enter it at the miner", "the hand point already uses the supply"). An existing beyond_spec = true whose supply does not fit (the NerdQAxe++ without a rating) shows the box checked and locked with a note on the card: the regulation keeps the ladder's beyond-table steps exactly as before, the calibration searches nothing above the hand point until a rating is known. An Avalon is unchanged (work modes, no voltage search).
  • WarpTune: a heartbeat tells the WarpAxe firmware that WarpTune regulates the miner. A WarpAxe build with the regulator route (externalRegulator in /api/system/info; part A of block 5) steps its own regulation back while an external regulator's heartbeat is in force. For every such miner that WarpTune regulates live, WarpTune sends POST /api/v1/regulator {"ttl_s": 600} right after the live start or a reload and then about every two minutes; the firmware's regulation takes over again ten minutes after the last heartbeat, so a WarpTune crash leaves no miner unregulated. The route sets a time in RAM alone (no flash write, the display stays asleep, no event is logged). Never in a dry run, never to a stock firmware, never to an Avalon; {"ttl_s": 0} goes out best effort when the miner leaves live — live off, a shutdown or the miner removed from the file — after the restore write and with a 2 s timeout, so it never eats the stop budget; not on a reload (the new loop renews within seconds) and not after a device swap (the address answers with a board that was never WarpTune's). A board that still carries a heartbeat WarpTune did not send in this run — a predecessor that crashed, or live switched off on the page, which restarts the loop without live — gets the end once as well. The heartbeat is no write of the point (no foreign point, no settle); a heartbeat the firmware does not answer is logged at most once an hour per miner and is no fault and no reason for a restart. The journal notes when the heartbeat went on and off.
  • WarpTune: the firmware's own heals are followed by its selfHeals list. The block 5 firmware lists the cases it heals itself (["chain_silent", "chip_silent", "domain_latch"], fixed per version). For a case in the list WarpTune waits, for one not in it WarpTune acts as before — one rule in one place (Sample::firmware_heals). A firmware without the list (WarpAxe 0.1.40 and before, every stock firmware) is read by the case's own fields as in block 4 (chipSilentRestarts for a silent chip, domainLatchResets for a domain latch); the whole chain silent is never taken from a single field. chain_silent in the list is information only for now: the dead-chain verdict stays today's (the firmware's chain restart after a silent minute runs underneath it, as it has since WarpAxe 0.1.16).
  • Pool: the connect modal shows the TLS key fingerprint for a self-signed certificate. Next to the Stratum TLS address, a self-signed certificate (the default on Umbrel) now comes with the SHA-256 of its public key (AB:CD:…, also as connect.tls_spki_sha256 in /api/overview). Firmware that asks you to trust a pool outside the public CAs (WarpAxe) shows the same value, so you can compare the two before you confirm. A CA-signed certificate needs no such check and shows no fingerprint. The manuals now list WarpAxe v0.1.40 next to BitForge Nano v1.5 as firmware that only trusts its bundled CAs: use port 3333 there.

  Changed

  • WarpTune: the configured hand point overrides the core-current warn line's reserve (Oliver, 2026-11-06). A step up — the calibration's pin as well as the regulation's own climb and the restore — is held under 90 % (core_current_up_ratio) of the core-current line by its predicted current. For the hand point from the config (stock: that very clock and voltage, never a step above it or another voltage on its clock) the bar is now the warn line itself: the operator runs that point by hand, and the reserve kept a BitForge Nano's Max stage off its 625 MHz @ 1050 mV hand point for four hours (34.3 A predicted against 34.2 A). A prediction at or over the line still holds, a fault line (board default or core_current_warn_a in the config) keeps its reserve, a reading at or over the line stays the fault it is, and every other limit (power budget, power limit, supply reserve, chip and VR temperature, board limits) is unchanged. The reason line says when the hand point overrides the reserve (hand_point_over_warn, 8 languages).

  Fixed

  • WarpTune: a calibration stage concludes at the voltage floor after a latch pause, and every result carries a J/TH for the Eco curve (Oliver, 2026-11-09). The Octaxe's Eco stage at 650 MHz had 1180, 1170 and 1160 mV good when a chip domain latched at 1150; after the pause and the resume on its own it started over at 1180, stepped to 1170 and stood there for 1 h 40 min: the regulator's latch floor (the latch voltage plus two steps, 1170) let it go no lower, the good verdict at 1170 counted as "the same good verdict again" from before the pause, and the stage waited for a step that never came until the stall guard ended it — with 1160 mV from before the pause as its result — under the floor, where the regulator never runs — and without a J/TH, so the Eco curve read 650 MHz as "not better" (though it ran under 675's 17.77 J/TH) and ended two clocks early. On a resume after a latch the stage's floor now follows the regulator's latch floor on its clock, a voltage measured good under it before the pause is no candidate any more (the latched voltage stays as the bracket), and the same good verdict at a voltage the search cannot leave downward concludes the search: the voltage is verified and is the result, as a first good verdict at the floor is. A result that no verification window measured — a stall, a guard, a timeout, a re-check's end — gets its J/TH from the stage's reference by the measurement's own formula (the draw over the expected rate held to the share ratio), so the Eco curve weighs every clock. The clock search, the Max curve and the quick check share these paths where they have them; the quick check's screen starts over after a latch pause as before.
  • WarpTune: the cross audit of the 2026-11-09 changes — eleven findings closed (Warppool #2, 2026-11-09). Two step-down paths still wrote a passing step at the stage's voltage: the "domain latch again" step down and the soft-fail leave now carry the voltage every other write does. A passing step on the way down keeps the voltage the miner runs at, and the way-up gate predicts the power with the voltage the move writes, so a passing step's own voltage cannot slip past a budget. A share vote that began counting on keeps its shares until the point changes: the trim on the current ratio cut the history back to the newest 400 the moment a vote left the one-sigma band and re-judged it on those, so a point near the bar counted on round after round, or passed on a trimmed window; the verdict now falls over all the shares counted on. The calibration's chip error line is part of the regulator's share verdict while a stage runs — a near-short vote over the line is short at once instead of counting on for another hour, and a good share vote over the line is short too, so the regulator no longer steps the trial down once more before the stage overturns the verdict (the hold names the line as the witness, in 8 languages). Good steps an older journal stored over the line are judged by it when the job is read back — once, for journals from before the line — so no end of a stage takes one as its result. The share history keeps the extended window only for a vote that counts on, not for a point that merely reads within the band; a passing step on the way down whose latch floor or held failed voltage lies above the voltage the miner runs at is passed over instead of being written above it. A staged write whose voltage fails after the clock landed leaves the miner at the new clock and the old voltage, and the run knows that point as its own. Three further findings were refuted and left as they are.
  • WarpTune: a write down in clock and voltage goes in two stages — the clock first, the voltage after the firmware's ramp (Oliver, 2026-11-09). WarpAxe takes the core voltage of a PATCH /api/system at once and ramps the clock in 6.25 MHz steps every 100 ms (625 → 425 MHz in about 3.2 s), and stock AxeOS and NerdOS are believed to do the same: a write that lowered the clock and the voltage together ran the old clock at the new voltage for seconds (WarpAxe #2; the firmware's own fix comes with v0.1.42). WarpTune now writes the clock alone first, waits until /api/system/info reports the chips at the new clock (frequencyActual, WarpAxe; frequency is the configured value on every firmware and jumps with the write) — or the ramp's computed time plus two seconds, fifteen at most, where the firmware does not show the chips' clock — and writes the voltage in a second PATCH; the settle and the blind time start after the second write. A write up, a write down at the same or a higher voltage, and a voltage change alone go in one write as before; a failing second write is a write error like any other, and the miner then stands at the lower clock with the higher voltage, which is safe. The rule holds for all AxeOS-type firmwares (WarpAxe, stock AxeOS, NerdOS); the Avalon's work modes carry no voltage and are unchanged. The wait runs inside the miner's own loop, so the other miners are not held up.
  • WarpTune: a share vote within the noise on the double window counts on to 800 shares instead of failing the point (Oliver, 2026-11-09). A voltage verdict short of the 95 % bar by less than its noise was confirmed on a second window of 200 shares and then stood, at 400 shares — where one sigma is about 5 %, so a point hashing at a true 100 % fell in about one case in six on the scatter alone. The Gaia's Eco stage at 350 MHz @ 960 mV failed its verification on 92 % over 400 shares (the point runs at 105 % today); the NerdQAxe++ took 1150 mV for 1140 after 92 % over 400 at 0.6 % chip errors. A vote within one sigma of the bar on the double window, with every other witness clean — the chip errors under their line and not risen over the point's baseline, no rejects, no chip domain off, the firmware's own reading at the bar — now counts on to 800 shares, and the verdict falls over all of them: under the bar there, it is short as before (or noise, with flat chip errors, as the noise rule says). A vote clearly short, or short with a second witness, is short at once as before. The rule is the regulator's own share vote, so it holds for the calibration's verifications and steps, the quick check's confirmation and the regulator's trial alike; the share history keeps the 800 shares while a vote counts on, the hold says "counting on to 800 shares", the card asks for 800, and the slow-shares note reckons with 800 against the stage's timeout.
  • WarpTune: a ladder step on the way to a calibration's pinned step keeps its own voltage, never the stage's (Oliver, 2026-11-09). A calibration's stage gives the regulator a voltage window for its step, and the regulator wrote every step inside it — the steps it passed through on the way to the pinned one too. On the NerdQAxe++ a calibration started at the hand point 800 MHz @ 1250 mV with the Eco stage pinned at 600 MHz @ 1150: the way down wrote 725 MHz at 1150 mV, a chip domain latched off there, the regulator bumped the miner back to the hand point, the job paused, and a mark against 725 MHz @ 1150 mV stayed behind for a point the miner was only passing through. The window is the pinned step's alone now: a step on the way to it is written on the way up at its own voltage — its calibrated one where it has one, inside the owner's own window — and on the way down at the voltage the miner runs at, until the pinned step is reached, which takes the stage's voltage together with its clock in one write. A step below the pin that an urgent step down lands on is no passing step: it takes the stage's window and never more than the voltage the miner runs at — an emergency step down raises neither the power nor the current — and the power is predicted with the voltage written. A passing point written on the way down stays WarpTune's own point afterwards, not a foreign one. The regulator's own moves (the ladder, the Eco cap, the schedule) were never affected: they write each step at its own voltage.
  • WarpTune: the chip error line judges every voltage step of a calibration, not only the verification, and a verification over the line sends the stage upward (Oliver, 2026-11-08). With the regulation's chip_error_trigger off (the live setting since 2026-10-01) the steps of a voltage stage were judged on the pool's shares alone; only the verification held a curve stage to the chip error line (error_up_max_pct, 1 % by default, shifted by the miner's temperature slope). On the NerdQAxe++ the Eco stage at 575 MHz walked 1120 → 1090 mV at 1.4–5.8 % errors as good, the verification refused 1100 and 1110 on the line and the stage failed, with 1130 mV at 0.89 % never counted; the Max stage at 800 MHz was heading the same way. The same line — one function, the same baseline and temperature rule as the clock search's — now judges every verdict of a voltage stage: the reference, each step down, each step up and the verification. A good share verdict over the line is a bad verdict: the walk down ends there and the lowest good voltage above it is verified (1130 for the Eco stage, 1230 for the Max stage); a reference over the line, or a verification over it with no good voltage left above, is searched upward 10 mV at a time to the ceiling (a step over the line on the way up is short too) until a step holds the line and passes its verification; only with nothing left under the ceiling does the stage fail, and then with the line as its reason — not as a hand point that "did not run stable", a ceiling "short of good" or a reference short by the shares. The start clock's own reference — the hand point, the factory point — stays exempt as the validated yardstick. The old exemption of the whole stage at the start clock also explains the stage at the hand clock 600 MHz accepting 1120 mV at 1.42 % while the stage at 590 MHz refused the same reading; its steps below the reference are judged now. The regulation's own trigger outside the calibration is unchanged; the quick check keeps its relative screen.
  • WarpTune: a calibration's verification keeps its result on a guard exit, a reference short on its verification is searched upward, and the verified voltage is the result (release audit, 2026-11-08). A guard that moved the miner off the step during the verification — the VR line, a power limit — failed the stage without the voltage under verification, a good one above every failure, and the curve stopped there; the stage now ends with it, as it does on a guard during the search and on a timeout. The regulator's step down for the hashrate on the stage's own clock during the verification is the verdict on the voltage under verification, as it is during the search. A reference that failed its own verification ended the stage at once as reference_short_back; it is searched upward to the ceiling, as a reference short at the start or on the way back up is (2026-11-07). The result is the verified voltage itself: the yield rule, run again on the verification's readings, could pick a lower voltage measured good once and never verified (a verification window without an error mean made the lowest good voltage the pick) and take it over with no J/TH for the Eco curve.
  • WarpTune: a stage that searched upward is written back to the voltage it takes over, not to the reference it measured short; the firmware's give-up hold is not the latch bump; a clamped quick stage keeps its own window (release audit, 2026-11-08). At a pause, a stop and the job's end the miner was written back to the stage's reference, even where the stage had just measured that reference short of good and found a higher voltage (the Gaia's Eco stage: back to the 940 mV it had measured short after 950 mV ran good, for hours while the job waited for the operator); it goes back to the voltage the stage takes over, and to the reference only where nothing good was measured. The firmware's one-time hold for a chip domain it gave up on begins with the words of WarpTune's own latch bump and was taken for it under a running stage — a failed step recorded at the stage voltage, the floor raised, a pause that never resumed on its own; the domain stays off until a boot, so the stage ends failed with its own reason (domain_given_up), nothing recorded bad, the floor untouched, and the job ends with it — no later stage measures with the dead domain; the results of the stages done so far wait for apply as after the operator's stop. A heal under way only starts the stage's window over. A quick job's stage whose reference is lowered to the ceiling on a journal resume got the full search's floor at the hard minimum, and an auto re-check that tests one step screened down to it; it keeps the quick check's own window.
  • WarpTune: the pin is never skipped and a mark from before the job is lifted, a pause read back from the journal reaches its day's end, a step kept above the top is dropped by a later complete apply (release audit, 2026-11-08). The regulator's rule to skip a step marked unstable carried the miner past the step a calibration pins onto the one above, at the stage's window voltage, from where the way down passed the marked step over again and the stage failed as a guard, never measured; the pinned step is never skipped (a marked pinned step holds the miner below it, the mark as the blocker), and a mark from before the job on the stage's clock — the regulator's guard at the old voltage, within the hour — is lifted when the stage starts and for the open stage on a restart, since the stage measures the step anew; a mark the regulator sets during the job stays. The clocks of the pause for a silent chip and of the pause for a dead domain at the hand point are not journaled, so a job read back paused after a restart never reached its day's end and blocked every reload and apply for good; the day starts over on the first tick after the restart. A ladder step a curve job added above the top and kept on its apply was not among the steps a later complete apply takes out when it drops the clock (the restart's rule, v1.49 audit R2 M-3), so the ladder differed before and after a restart; the kept step is listed with the restored ones.
  • WarpTune: a curve stage seeded from a neighbour clock's result keeps its reserve under the ceiling; interpolated points honour the latch floor and the trial memory's failure (release audit, 2026-11-08). A curve stage seeded from a neighbour clock (the next Eco clock, the next Max clock above the top) has that clock's bare found voltage as its reference, not a voltage the step ran at — the reserve, capped at the reference since 2026-11-08, was lost where the stage was good at the seed and short one step under it (the Gamma's 465 MHz, seeded at 490's 1030 mV, taken over at 1030 itself); such a stage's result keeps the full reserve, bounded by the ceiling. The steps interpolated between two measured clocks took no notice of a latch floor at their clock (the Octaxe's 625 MHz, latched at 1210 mV two hours earlier, interpolated at 1180 and written there) nor of a failed voltage the trial memory holds; the floor lifts the interpolated voltage (a floor above the ceiling leaves the clock out), a failure at or above it leaves the clock out, and a calibrated step is written no lower than its latch floor, the calibrated ceiling still holding.
  • WarpTune: below the hand point a curve stage is held to the regulation's own electrical lines, not the clock search's reserves (Oliver, 2026-11-08). As the voltage regulator's line already does (bullet below), the other window limits of a stage below the configured hand point no longer judge it more strictly than the hand point that bounds it. The core current fails the stage only at or over the warn line itself, where the regulation steps down, not at 95 % of it — the configured hand point may sit inside that reserve, which it overrides (2026-11-06). A hardware power limit (90 % of the board, 80 % of the supply) and a default supply rating exempt the stage as they exempt the hand point (v1.39.4); the 95 % line of the firmware's board limit, which the hand point as a curve stage is never judged against, steps aside as well; the owner's max_watts (judged on its own where a hardware line is the lower limit) and own supply rating hold as everywhere. A member of the supply's group silent for long no longer fails the stage — the hand point is validated on the real supply and the stage draws less — but is noted under the result. Above the hand point, in the clock search and without a configured hand point, every limit judges as before.
  • WarpTune: a calibration's reserve is capped at the stage's reference again; only a result found upward is capped at the ceiling (Oliver, 2026-11-08). The curve (unreleased, 2026-11-06) lets a stage search upward when its reference is short of good, and with it the +20 mV reserve was capped at the stage's ceiling for every result. On the Nano the Eco stage with the reference 1020 mV found 1010 and was taken over at 1030, above the voltage it started from; the steps interpolated between the measured clocks (450–600 MHz) all came out at 1030 with it, and the journal still said "capped at the reference". A result found at or under the reference is now taken over at the found voltage plus the reserve, capped at the reference, as before; only a result the upward search found above the reference is capped at the stage's ceiling (the hand voltage for a stage under the hand clock, the owner's voltage_max_mv where set). The interpolated steps follow, and the journal line names both caps. A job read back from the journal has every stage's take-over worked out again by this rule, so a stage that finished under the old cap is taken over at the corrected voltage right after the update.
  • WarpTune: below the hand point a curve stage's voltage regulator is held to the regulation's own line, not the clock search's margin (Oliver, 2026-11-08). The curve's hard limits over the window (unreleased, 2026-11-06) judged every stage off its start clock by the clock search's rule, the VR temperature 15 °C under the firmware's shutdown line among them. That rule was approved for candidates above the hand point; on the Octaxe it made the Eco stage at 675 MHz, below the 700 MHz hand point, unpassable: VR 61 °C against 70 − 15 = 55 °C, with its VR at 61–62 °C for hours at the hand point and the regulation stepping down at 68 °C. A stage below the hand point now fails on the voltage regulator only when its temperature is at or over the regulation's own down line (the firmware's shutdown line minus 2 °C, where the regulation itself steps down), and the card names that line. Stages above the hand point and the clock search keep the 15 °C margin.
  • WarpTune: a calibration's stage starts at the step's operating voltage, never under the owner's floor (Oliver, 2026-11-07). On the Gaia the Eco stage started at the table's 940 mV although the owner had set voltage_min_mv = 950 because 940 reads 7 % chip errors there, and although the step had run at 950/960 mV for weeks. A planned stage now starts at the voltage the step is known to run good at — its calibrated voltage, else the trial memory's good voltage — instead of the table's, never under voltage_min_mv and never above the stage's ceiling. The voltage stage that a clock stage hands its clock to starts by the same rule, and the curve's next clock and the Eco curve's seed from the Max stage — which start at the neighbour's found voltage — keep the same floor and ceiling; the quick check, too, starts no lower (the quick check of 12.10. started at 940 for the same reason), and no higher than voltage_max_mv. A floor that lies above a stage's ceiling (voltage_min_mv over the hand voltage or voltage_max_mv) is a misconfiguration: the stage starts at the ceiling and searches under the owner's floor down to the hard minimum, and the log says so — the start line for the planned stages, a line of its own for a stage the job adds while it runs. A start lifted to the owner's floor with the hard minimum (the firmware's lowest voltage, calib_hard_min_mv) below it is not "already at the floor": the stage runs and searches under the floor, as the full search does — down to the first failure. The owner's voltage_max_mv, while the trial window is in force, caps every stage's ceiling: no stage starts or searches above it.
  • WarpTune: a reference that falls through on the way back up is searched upward, not given up (Oliver, 2026-11-07). When the reference itself was short of good after a failure below it, the stage ended without a result ("short of good on the way back up"); it now searches upward from the reference, 10 mV at a time, to the stage's ceiling — the hand voltage under the hand clock, the owner's voltage_max_mv elsewhere — as a reference short at the start does. A bad verdict the regulator gives at the reference counts as the reference short of good as well.
  • WarpTune: under a calibration's pin the regulator's hashrate verdict is the stage's to take (Oliver, 2026-11-07). On the Gaia the regulator's urgent step down for the hashrate ("73 % of expected < 90 %, shares 79 %") wrote 340 MHz, marked 350 unstable for an hour and failed the Eco stage after 24 min — before the stage's own 200-share window was in; the Max stage went the same way after 10 min, and the marks then kept the pin from its own clocks (340 → 360, "skipping 350 MHz (unstable)"). While the calibration pins the clock the miner runs at, a verdict on the voltage's stability alone — the hashrate, the chip errors — no longer steps the clock down or marks the step: the regulator holds and says so ("…: the stage judges it on its own window", 8 languages), and the stage judges the voltage on its own window, as the plan intends. The reject rate keeps its urgent step down under the pin (rejects are seldom the voltage's doing, a pool's trouble as often as not); the heat, the VR temperature, the electrical lines, a dead chip and a latch keep theirs. Should such a step down still reach a stage (an older decision), the stage reads it as a verdict on that voltage: it verifies the lowest good voltage it has above the failure or searches upward from it, and the regulator's mark on the step is lifted so the pin can reach it; at the hand point, with nothing above, it ends on the guard as before and the mark stays.
  • WarpTune: a failed stage of a complete calibration keeps the clock's earlier entry (Oliver, 2026-11-07). A complete job replaces the calibrated map, and a clock whose stage failed without a result got no entry — on the Gaia the Eco 350 MHz would have fallen back to the table's 940 mV, the very voltage the owner's floor keeps the trial away from. The job still replaces the map (stale clocks elsewhere are dropped), but a clock that was calibrated and measured nothing new keeps the voltage it had — capped at the owner's current voltage_max_mv, and dropped altogether when the stage found that voltage, or any voltage above it, short of good; the card keeps its measured point and the journal line carries the kept voltage, so a restart reads it back. A clock the map never had stays without an entry, as before. Keeping the old entry rather than treating the job as incomplete lets a complete job still clean up stale clocks, and the kept voltage is one that ran good in operation — which the table's voltage never is where the owner set a floor above it.
  • A long badge wraps inside its card. A WarpTune state such as "Max · 525 MHz · waits for PV surplus · dry run" ran out of the device card; badges now wrap at word boundaries and turn into a rounded box when they need a second line.
  • PROXY protocol: bytes that start with 'P' but not "PROXY " are no header at once. From a trusted proxy address the pool read a v1 header up to its CRLF; a peer without a header whose first byte happened to be 'P' (an Sv2 handshake does so for one key in 256) waited the full 5-second header deadline before it was dropped. The reader now answers "no header" as soon as the bytes leave the "PROXY " prefix, for V1 and V2 alike; this also ends a test that failed once in about 256 runs.
  • WarpTune: the apply of a full calibration replaces the calibrated map (Oliver, 2026-11-07). A complete job — the start job, not a quick check, with every stage run, over the curve or not — now takes over its own points alone: the measured ones and the steps interpolated between them; points an older job left at other clocks are dropped (the Nano's 650 MHz @ 1050 mV from 24.10. sat above the ladder cap in the map), and a clock whose stage failed keeps the entry it had, if any (see the bullet above), else gets none. The memory a dropped entry left (the trial's good voltage, the "known good" mark, a ladder step a restart had added above the top) goes with it, and the journal's trial verdicts and healthy marks from before the apply at the dropped clocks are not read back after a restart. A stopped job, a quick check and any job that measures only some clocks still merge into the map as before.
  • WarpTune: the calibration card lists the measured points alone (Oliver, 2026-11-07). After the apply on the Nano the card listed ten points — the two the job measured (Eco 425 MHz, Max 625 MHz), seven ladder steps interpolated between them, and 650 MHz kept from an older job above the ladder cap. The card now lists only what this result measured, each as "Eco 425 MHz: 1020 mV (measured 1000 + 20 mV reserve)", and says once, without numbers, that the steps in between are WarpTune's estimate from these points. The regulator keeps the whole map; the snapshot carries the measured points and the stage labels, read back from the journal after a restart; a step that a raise in operation has moved is listed with the apply's value and the voltage it sits at now; a quick check keeps the earlier measured points at the clocks it did not measure. The log line of an apply names interpolated and kept points as such instead of "found".
  • WarpTune: a step that runs under its calibrated voltage is written up to it (Oliver, 2026-11-07). The calibration on the Nano was taken over while the miner sat on its last point, the 425 MHz Eco cap at the found 1000 mV; the apply set 1020 mV, but the regulator only held ("up blocked: eco cap") and the step ran on at 1000 — the calibrated voltage was written only on a step change, and the regulator moved a settled step down to its calibrated voltage, never up. Once settled, such a step is now written up to its calibrated voltage (reason calibrated voltage: 1000→1020 mV at 425 MHz), as a step change would write it — the step's ceiling and a trial window's top hold as before — with the way up's own guards: the core current bar, the hardware's power limit, a PV surplus cap, the VR temperature and the input voltage each hold the raise and say why; a running calibration, an emergency, a domain or chip the firmware is healing and a point that is not WarpTune's are left alone, and the write is tried once per point. A step the owner lowered by hand under its calibrated voltage is written back up too: the calibrated voltage is the step's voltage until the result is discarded. The calibrated entry itself does not move, so there is nothing to step back down to.
  • WarpTune: the calibration card counts a verification on its own shares (Oliver, 2026-11-06). During the verification of a voltage the card said "testing 1000 mV · 215 of 200 shares" beside the green 1000 mV chip: the count was the regulator's share window, which still held the verdict's own shares. The card now says "confirming 1000 mV · 15 of 200 new shares" — the new shares on the miner's accepted counter since the verification started, the count the verification itself waits for (its own window of new shares, not the vote's confirmation window) — and the progress bar and the time estimate take that count too (the estimate had read the open verification as done). After a counter reset the count restarts from the first counter seen, and the bar no longer steps back as a search goes into its verification.
  • WarpTune: the calibration's time estimate rests on the share rate as counted, not on the pool difficulty of the moment. The estimate divided the share-rate hashrate by the difficulty the miner reported in that very sample; on the Nano (2026-11-06) VarDiff swung that difficulty between 3.3 k and 15 k within minutes at one hashrate, and the estimate for the same plan read 10 h in the morning and 16 h in the afternoon. It now takes the shares counted over the regulator's share window per second — the rate VarDiff holds the miner at, whichever point it runs. The dialog's estimate before a start takes the same yardstick.
  • WarpTune: a voltage stage whose pinned clock the regulator refuses ends as "clock not reachable". The calibration pins a stage's clock, but a hard guard of the way up (the power budget, the current bar, VR or VIN, a step marked unstable) can hold the miner under it; the stage then stood for its full calib_timeout_s (4 h on the Nano) before it failed as "could not reach 625 MHz". Like a clock candidate, a voltage stage now ends after three such decisions in a row with not_reachable and the blockers as the detail. Hard guards are what belongs to the miner and its electrics: the current bar, VR and VIN, a step marked unstable, and the hardware's power limit (the board, the supply, max_watts; the reason now says "power limit (power supply reserve)" instead of "budget" when that is what binds, over_power_limit, 8 languages). The budgets of the hour — the PV surplus and the thermal budget — hold a calibration's step no longer than they last: a stage pinned under one waits them out, for clock candidates as well (before, a PV budget wrote a clock candidate off after three decisions); the card names the budget as the blocker meanwhile — with the result it already has (as at the timeout), otherwise failed, and the apply logic treats it as before: nothing of that stage is applied, the hand point stays. A transient blocker (a dwell, an unjudged step, the fan) is waited out, and the timeout stays the upper bound. The card meanwhile says "waiting for 625 MHz: blocked by …" with the regulator's blockers and shows no estimate; the wording of not_reachable now names the clock in all 8 languages (it read like a network failure in some).
  • WarpTune: the calibration's estimate on a searching stage with its window full. With the share window full and no verdict (a near-short vote the regulator keeps confirming), the estimate still counted the plan's remaining steps as if the step were about to end; it now counts what the stall guard still needs to end the stage (twice the verdict's shares over the shares seen since the wait began) and then the rest of the plan.
  • WarpTune: the calibration's stall guard counts on the miner's accepted-share counter. The guard ends a searching stage that gets no verdict although twice the shares a verdict needs came in — but it read that count from the regulator's share window, which is trimmed to the confirmation window's ~400 shares, so in a confirmation (400 needed, 800 asked for) it could never fire and a stage on a near-short vote stood until its calib_timeout_s (4 h). It now counts on the miner's raw accepted counter since the stage began waiting, as the verification window does; a counter that fell (a reboot, a pool reconnect) starts the count over, and a telemetry tick between decisions still never ends a stage.
  • WarpTune: a BitForge Nano on Forge-OS v1.8 is known as a Nano again. Forge-OS v1.8 no longer reports boardVersion in /api/system/info (it names the board only as deviceModel under /api/system/asic). Without it WarpTune took the Nano for a generic BM1370 board: the generic ladder (up to 1250 mV, above the Nano's 1200 mV) instead of the Nano's maker presets, no board limits, and allow_board = ["800"] no longer matched. For a firmware whose /api/system/info names no board, WarpTune now reads deviceModel from /api/system/asic once per board and run (asked again for another board at the same address, and on the next poll after a failed request); Forge-OS's BITFORGE_NANO also gets back the board version 800 it reported up to v1.7, so presets, limits and the allowlist hold as before. Firmwares that name their board in /api/system/info are never asked. The Nano's table on Forge-OS also takes the maker's new top preset from Forge-OS v1.8 (commit 9d8070e): Power at 610 MHz @ 1200 mV instead of 625 @ 1160; Eco 425 @ 1000 and Medium 525 @ 1150 stay as they were. A Nano on WarpAxe keeps WarpAxe's own presets and fine ladder up to 625 @ 1160.
  • WarpTune: the example config no longer caps the ladder at 600 MHz. dvb-warppool-tune example wrote ladder_cap_mhz = 600 (from the first test phases), which cut every step above 600 MHz for a config started from it — the Bitaxe Gamma's 625 from the maker table and the BitForge Nano's top preset (610 on Forge-OS v1.8, 625 before). The line is now commented out, so the ladder reaches the maker's top step, as it always did for a config the WarpTune Desktop page creates. An existing warptune.toml keeps whatever cap it sets.
  • WarpTune: chips that Forge-OS switches off for want of a pool are no dead chips. Forge-OS v1.8 switches the chips off by itself while no pool answers (core voltage 0, reset held, hashrate 0) and reports poolsUnavailable: true; it probes the pools every 30 s and re-inits the chips once one answers. WarpTune read those readings as an electrical death: it restarted the device and marked the step as a ceiling. It now takes the flag as the firmware's own stop, as it does WarpAxe's shutdown: it holds the point, writes and marks nothing, for as long as the flag lasts (unlike the pool-outage deferral, with no 30-minute cap: the firmware itself says why there is no work), and judges the point afresh once the chips hash again. The card says "chips off (no pool reachable) on the device: holding, nothing marked" (8 languages).
  • Pool: template_source = "auto" switches to IPC once Bitcoin Core's socket answers, and back to GBT should it stop delivering — without a restart. 2026-11-04 on the Umbrel: the pool came up at 12:28:19Z, Core's node.sock at 12:28:25Z, the 3 s start probe missed it and the pool stayed on GBT until the app was restarted (the health banner said so and asked for the restart). Now auto runs GBT and IPC side by side: it starts on IPC when the socket answers the start probe, else on GBT, probes the socket again every 60 s (backing off to 5 min) and switches as soon as the socket answers and delivers its first template — GBT delivers until then, so there is no job gap and no stale job at the switch; the block-submit path takes the IPC fast path from the switch on. On IPC, no template for three refresh intervals (at least 90 s) takes the pool back to GBT at once: the GBT source resumes with a fresh getblocktemplate (what queued up meanwhile is dropped, ZMQ events deduplicated) and the retry starts over; a long poll in flight is never cancelled client-side (Core's worker would stay parked), no getblocktemplate is dropped half-way (the GBT source runs in its own task), and the ZMQ watchers run in auto whatever the start probe said, so they are there for the way back. While IPC delivers, the idle GBT source keeps draining the ZMQ events (counted as ZMQ liveness, so no false "ZMQ silent" warning after a switch) and a new tip that ZMQ reports and IPC has not delivered (IPC's waitNext usually brings it first; the last eight IPC tips are remembered, and a template on a later tip clears the debt too) within 10 s takes the pool back to GBT at once, not after the stale window; an IPC source that answers the probe but never delivers is dropped after the same window and probed again with backoff; a short IPC phase (under 10 min) lets the probe backoff grow instead of starting over, so a flapping socket is tried less and less often; a first IPC template behind the last GBT job's height is released and not switched to. IPC template ids are unique across all IPC phases, so a job of an earlier phase can never release or submit against a template of the current one (the fast path answers NotRetained and the block goes through submitblock). One log line per switch; /api/overview, the header badge and the node card on the admin health page show the source in force, and the ipc_template_stale warning fires only while IPC is the source in force. The ipc_auto_fallback_socket_reachable health warning is gone (8 languages); "ipc" alone stays strict as before. V1 and Sv2 get the same jobs from both sources as before (the switch is below the job pipeline).
  • WarpTune: a chip domain the firmware heals is no verdict on the step. With domain_latch in the firmware's selfHeals (block 5 WarpAxe: a domain under a quarter of the mean of the chip's other domains for ten minutes while work goes out gets chips off → on, clock and voltage unchanged, once an hour, three attempts, then given up until the next boot or point; fields domainLatchResets, lastDomainLatchReset, domainsGivenUp, 0-based), WarpTune's own latch path waits while the domain is not in the firmware's give-up list: no restore bump, no voltage held off, no latch floor, no chain re-init, no domain_off journal line (a restart resurrects nothing), the way up is held ("domain 2 on chip 2 off, healed by the firmware" among the up blockers; the card: "chip 2 domain 2 off (counted from 1), healed by the firmware: no step up"), no step is judged good, and the hashrate is judged on the domains that run (up to a quarter of the domains, at least one; more is no single latch and is judged on all domains — the card says which). A rise of domainLatchResets is the firmware's heal: the windows start over and the point settles afresh as after the chain restart in block 4 — no step fault, no stall, no dead-chip, collapse or step verdict ("the firmware healed domain 2 on chip 2 (counted from 1; it ran at 12 % of the chip's other domains) by chips off → on (heal 1 since boot): settling afresh, no verdict"; journal notes with the prefix "domain latch (firmware):"; 8 languages); a calibration starts its stage window over on it instead of failing the candidate, and never pauses for it. While a calibration runs, a domain the firmware would heal counts as a latch for the calibration — a latch at a voltage the stage wrote is the calibration's finding (the firmware would only act after ten minutes, and every stage write starts its clock over): the latch goes WarpTune's own way, as on a stock firmware — the short raise to the hand point, the job's latch pause, the resume on its own once the domain has been back for ten minutes. Once the firmware has given the domain up ("given up by the firmware" in the journal), WarpTune only reports it, at the hand point and at a step alike (Oliver, 04.11.): no chain re-init (the firmware's chips off → on was the same action, three times), no raise to the hand point, no voltage held off, no latch floor, no step marked — one hold when first seen, saying "domain 2 on chip 2 given up by the firmware at 625 MHz @ 1250 mV …: WarpTune answers with no re-init, no raise and no mark — switch the miner off at the power supply for a few seconds …" (8 languages), then the same text rides along on every following decision while the temperature, electrical and error steps run as always and the hashrate is judged without the domain; the journal gets one note; once the give-up ends (a new point, a boot, the list cleared) the firmware's heal is waited for again. Block 4's daily device restart for a chip given up on is untouched. And a domain off since before a step down is carried over, not a latch of the step below (Oliver, 04.11.; on a block-5 and on a stock firmware alike, whatever triggered the step — the heat, the power limit, a verdict): no bump back to the hand point, no step marked, no latch floor, no latch line, the hashrate judged without it ("chip 2 domain 2 (counted from 1) off at 625 MHz @ 1250 mV since before the step: no verdict on this step, hashrate judged on 7 of 8 domains", 8 languages), and the way back up open to the point it was off at — where, before this change, the step down bounced the miner between the hot hand point and the step below it every two decisions, marking every step on the way. A step up carries nothing over, and a step back up to (or past) the point a domain was carried from drops the entry — that point judges the domain again (the firmware's heal with its note, the latch line, the re-init or give-up at the hand point). Under a calibration a carried domain is judged as in the main loop: a domain off fails the screen or pauses the job. The card's red banner lists every domain off, WarpTune's own and the ones it waits on. A heartbeat WarpTune has ended is not WarpTune's to end again until it sends a new one. A voltage a chip domain latched at under a calibration is never measured again in that job: after the latch pause and the resume the stage starts its reference over, one step above the latch at least, and the screen stops there (a quick stage used to pick up at the very voltage it had latched at, and could accept it). A re-init that waits at the hand point (for a calibration, a steady state, the settle after the last one, the hour's bound) holds no urgent move any more: the heat and the other urgent moves run under it and the wait rides along on the card (before this change, on a WarpAxe without the heal, a hot hand point with a dead domain was never stepped down); WarpTune's own give-up at the hand point is one hold, then an annotation, like the firmware's — and after it the hashrate is judged on the domains that run ("hashrate judged on 7 of 8 domains after the give-up at the hand point", 8 languages; Oliver, 04.11.): the dead domain alone is no verdict on the hand point, no mark, no step down, and it stays in the banner — Eco's rule for a latched step (one step up, the step held off) marks the hand point no more after the give-up either; a real weakness on the running domains is still the verdict it always was, the step down with its mark; the scaling is the one the carried domains and the owed re-init have, a quarter of the domains at most, and it ends ten minutes after the domain was last counted off — the hashrate judged is the ten-minute average, which ramps for that long after the domain's return (the give-up itself is remembered for a day). A stock firmware has no chain re-init and so no give-up of its own at the hand point: nothing changes there. The decision that first counts a latch at the hand point judges the hashrate on the running domains too (before, the reading of that one decision was on all domains: a 7-of-8 board read 87.5 %, the plain verdict marked the hand point and stepped down, and the re-init never came). While the re-init is owed, the Eco cap's own step, the mode's own moves — the step up too, Eco's step up off a latched step and the budget's alike ("the step up waits: a chain re-init is owed at the hand point") — and the fan's step back hold ("the step down waits: a chain re-init is owed at the hand point", 8 languages) — a step down without a cause of its own would carry the dead domain past the re-init the hand point owes (the Octaxe comes up with domains off after an OTA or a cold start, which is exactly when the re-init helps); every other step down runs as at any other point: the heat (also under an Eco cap, whose line leads the card), the VR temperature, the electrical lines, the verdicts and a calibration's pin. No step is marked for a step down that is held: the fan's step back and the hashrate's soft fail ask first, and a verdict marks the hand point only together with its step down. The hashrate is judged on the domains that run ("hashrate judged on 7 of 8 domains while the re-init is owed") and the hand point is never marked from the dead domain. And a chip under its target counts as steady for the re-init: the re-init waited forever on a cool miner. A calibration never starts a stage with a dead domain at the hand point (Oliver, 04.11.): the chain re-init the hand point owes runs before the first pin step — the job pauses with "waits for the chain re-init at the hand point (chip 2 domain 2 off at 625 MHz @ 1250 mV)" and the regulator, not pinned, re-inits as it would without the job; the domain back, the stage starts as planned; the domain still off after the re-init, given up on (by WarpTune or by the firmware), or on a firmware without the re-init, the job pauses as it does for a latch ("paused: … — no calibration with a dead domain at the hand point; resumes once the domains are back", 8 languages, one journal line), resumes on its own once the domains have run for ten minutes (a resume of its own kind, not one of the two a latch under a stage gets), ends after a day with the domain still off ("ended: a chip domain has been off at the hand point for a day …; measure again once the domain runs", 8 languages, as the silent chip's day does), and records no failed step, no floor and no mark for it (before this change the pin stepped the miner down with the dead domain and left marks and floors on every step it passed — on a stock firmware too, where main holds the hand point instead). The restart of a screen or a confirm on a resume applies after a latch pause alone; an operator's pause or a silent-chip pause keeps the stage where it was. A firmware without the list keeps today's latch path unchanged.

  ---

  dvb-WarpPool v1.48.0 — Downloads

  Docker

  git.warppool.org/dvb-projekt/dvb-warppool:v1.48.0 (multi-arch amd64+arm64, ohne v-Präfix)

  Native packages

  • Linux .deb: amd64 + arm64 → apt install ./dvb-warppool_*.deb
  • Linux .rpm: amd64 + arm64 → dnf install ./dvb-warppool-*.rpm
  • Linux AppImage: x86_64 + aarch64 portable
  • Linux tarballs: x86_64 + aarch64 for manual installs
  • WarpTune only: dvb-warppool-tune-<tag>-<target>.tar.gz (Linux x86_64 + aarch64; macOS added with the .dmg) for running the tuner next to a pool on Umbrel or Docker — see the README inside
  • macOS .dmg: added shortly after publish (built separately) — or build from source
  • Windows .msi (the pool): paused since the forge migration (no Windows runner yet)

  WarpTune Desktop (the regulator with its own page, no pool needed)

  • macOS: WarpTune-Desktop-<tag>-{aarch64,x86_64}.dmg — added shortly after publish, with the .dmg above
  • Linux: dvb-warptune_*.deb (amd64 + arm64) or WarpTune-Desktop-<tag>-{x86_64,aarch64}.AppImage
  • Windows: WarpTune-Desktop-<tag>-x86_64-setup.exe (per-user installer, no admin) or the portable …-x86_64-windows.zip; runs on Windows-on-ARM through emulation
  • Not signed with a paid certificate: macOS Gatekeeper and Windows SmartScreen ask once — see the "open anyway" guide in scripts/warptune-setup.md; verify the download with SHA256SUMS + cosign below (the macOS .dmg lines are added when those assets are, with a re-signed SHA256SUMS)

  Signatures

  • SHA256SUMS + cosign bundle (SHA256SUMS.bundle, project key)
  • SBOM (SPDX) for all dependencies

  Verify (project public key cosign.pub in the repo root):

  cosign verify-blob \
    --key cosign.pub \
    --bundle SHA256SUMS.bundle \
    SHA256SUMS
  sha256sum --check SHA256SUMS
  

  First-time setup: run dvb-warppool-setup for the first-run wizard.

  Downloads

  • SHA256SUMS
    1 download · 2026-11-10 09:24:24 +00:00 · 2.5 KiB
  • SHA256SUMS.bundle
    1 download · 2026-11-10 09:24:24 +00:00 · 3.8 KiB
  • WarpTune-Desktop-v1.48.0-aarch64.AppImage
    1 download · 2026-11-10 08:59:51 +00:00 · 5.7 MiB
  • WarpTune-Desktop-v1.48.0-aarch64.dmg
    6 downloads · 2026-11-10 09:23:53 +00:00 · 6.1 MiB
  • WarpTune-Desktop-v1.48.0-x86_64-setup.exe
    6 downloads · 2026-11-10 08:59:51 +00:00 · 3.7 MiB
  • WarpTune-Desktop-v1.48.0-x86_64-windows.zip
    6 downloads · 2026-11-10 08:59:52 +00:00 · 4.7 MiB
  • WarpTune-Desktop-v1.48.0-x86_64.AppImage
    1 download · 2026-11-10 08:59:52 +00:00 · 5.9 MiB
  • WarpTune-Desktop-v1.48.0-x86_64.dmg
    6 downloads · 2026-11-10 09:23:55 +00:00 · 6.7 MiB
  • dvb-WarpPool-v1.48.0-aarch64.AppImage
    1 download · 2026-11-10 08:59:52 +00:00 · 26 MiB
  • dvb-WarpPool-v1.48.0-aarch64.dmg
    6 downloads · 2026-11-10 09:24:01 +00:00 · 29 MiB
  • dvb-WarpPool-v1.48.0-x86_64.AppImage
    1 download · 2026-11-10 08:59:53 +00:00 · 27 MiB
  • dvb-WarpPool-v1.48.0-x86_64.dmg
    6 downloads · 2026-11-10 09:24:09 +00:00 · 31 MiB
  • dvb-warppool-1.48.0-1.aarch64.rpm
    6 downloads · 2026-11-10 08:59:53 +00:00 · 20 MiB
  • dvb-warppool-1.48.0-1.x86_64.rpm
    6 downloads · 2026-11-10 08:59:53 +00:00 · 21 MiB
  • dvb-warppool-tune-v1.48.0-aarch64-apple-darwin.tar.gz
    6 downloads · 2026-11-10 09:24:10 +00:00 · 4.2 MiB
  • dvb-warppool-tune-v1.48.0-aarch64-unknown-linux-gnu.tar.gz
    1 download · 2026-11-10 08:59:54 +00:00 · 4.7 MiB
  • dvb-warppool-tune-v1.48.0-x86_64-apple-darwin.tar.gz
    1 download · 2026-11-10 09:24:11 +00:00 · 4.6 MiB
  • dvb-warppool-tune-v1.48.0-x86_64-unknown-linux-gnu.tar.gz
    1 download · 2026-11-10 08:59:54 +00:00 · 5 MiB
  • dvb-warppool-v1.48.0-aarch64-apple-darwin.tar.gz
    1 download · 2026-11-10 09:24:17 +00:00 · 26 MiB
  • dvb-warppool-v1.48.0-aarch64-unknown-linux-gnu.tar.gz
    1 download · 2026-11-10 08:59:54 +00:00 · 27 MiB
  • dvb-warppool-v1.48.0-x86_64-apple-darwin.tar.gz
    1 download · 2026-11-10 09:24:24 +00:00 · 27 MiB
  • dvb-warppool-v1.48.0-x86_64-unknown-linux-gnu.tar.gz
    1 download · 2026-11-10 08:59:55 +00:00 · 28 MiB
  • dvb-warppool_1.48.0-1_amd64.deb
    1 download · 2026-11-10 08:59:55 +00:00 · 21 MiB
  • dvb-warppool_1.48.0-1_arm64.deb
    1 download · 2026-11-10 08:59:55 +00:00 · 19 MiB
  • dvb-warptune_1.48.0-1_amd64.deb
    1 download · 2026-11-10 08:59:55 +00:00 · 3.7 MiB
  • dvb-warptune_1.48.0-1_arm64.deb
    1 download · 2026-11-10 08:59:56 +00:00 · 3.3 MiB
  • sbom.spdx.json
    2 downloads · 2026-11-10 08:59:56 +00:00 · 1.4 MiB