sync: atualizações do upstream rustdesk/rustdesk - #11
Merged
Merged
Conversation
* add the base crate and repoint the moved modules at it `libs/base` (crate `base`) takes the parts of hbb_common that only this app uses: `fs`, `platform`, `keyboard`, `message.proto`, and 145 of the 177 `config::keys` constants. hbb_common keeps what the server names, and the 32 keys it reads itself are re-exported from `base::config::keys` so call sites still see the full set through one path. Sources move verbatim. The only edits inside them are `crate::` prefixes that now have to say `hbb_common::`; `keyboard.rs` and `platform/windows.rs` are byte-identical. The crate stays on edition 2018, the edition the moved code was written under. `log`, `lazy_static` and `anyhow` become direct dependencies so the bare paths in that code resolve exactly as before, and its winapi features are spelled out rather than left to feature unification. Two call sites outside Rust and Cargo had to follow the move: the Android protobuf source dir, which still pointed at hbb_common/protos for message.proto, and the three AGENTS.md entries that named hbb_common for options, protos and file transfer. `scrap`'s `drm` feature now forwards to `base/wayland_probe`. Left pointing at hbb_common it would still have compiled, silently dropping the Wayland socket-probe fallback, so that forward is verified by a build with and without the feature. `config::keys` carries a test asserting its names stay disjoint from the ones hbb_common kept: the glob re-export and the local constants share a namespace, and Rust prefers the local item silently, so a name added to both sides would otherwise let client and server disagree with no diagnostic. Verified: macOS and Linux, debug and release, `--all-targets`; the 177 key constants diffed name-for-name and value-for-value; the generated protobuf types compared before and after; every `#[cfg]` gate on a moved import checked against its original; and every file that was `rustfmt`-clean before this change still is, compared against master file by file. Windows is checked by inspection only -- it cannot be compiled here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab * one `use` per crate, and write the rule down `fs.rs` came out of the move with two ungated `use hbb_common::` statements, because the original single `use crate::{...}` had to give up `message_proto` to the new crate and the rest was left in a second block. Fold it back into one. A scan of the whole tree for the same shape finds nothing else: every other file with more than one top-level `use base::` or `use hbb_common::` is split by a `#[cfg]` that does not cover the whole block, or by `pub use` next to `use`. Those are the cases that cannot merge, so AGENTS.md now states both the rule and the exemption. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
`set_stream_offset` indexed `self.files` directly. Its only guard is the `self.file_num() == r.file_num` check in `confirm()`, and `file_num` counts up past every file, so it equals `files.len()` once the job is done -- read_frame at :849 treats exactly that value as "job done". A peer that then sends `send_confirm` with the matching file_num and a non-zero OffsetBlk gets through the equality check and off the end of the slice. Every other site indexing `files` in this file already bounds-checks; this was the one that did not. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
Signed-off-by: Jamal <jamalkamaladdin@gmail.com>
* fix(audio): update CPAL for WASAPI thread priority * update cpal Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com>
The probe recovery merged as 692113c cost two to four times the p99 on the workload a remote desktop actually has, and the fork now reverts it: `sctp/src` returns to 48100bf1, the revision this repository shipped in rustdesk#15684, with the benchmark harness and its corrections kept. It was justified on a fixed frame rate. Nothing is sent while the screen holds still - the capturer answers WouldBlock and the loop sends nothing - so typing, reading and clicking are short bursts with silence between them, and a steady frame rate is what playing video or dragging a window looks like and nothing else. The difference matters because a steady rate hides the whole effect: the next frame's SACK exposes a loss whatever the recovery logic does. Measured on bursts with gaps, after correcting two faults in the harness itself, p99 in ms for the two seeds: sparse RTT70 sparse RTT150 48100bf1 09-06 00:06 200 / 208 407 / 507 b221f13b 09-06 14:00 328 / 804 737 / 826 On a fixed frame rate the two are within noise of each other, which is why this was not caught. KCP is 138/130 and 257/250 on those rows, ahead of both. What is given up: a tail loss of exactly four packets recovers in 140 ms rather than 229, and an idle sender's backlog after a stall offers 1.58x the bytes rather than 1.08x. A five-packet tail improves, 292 ms to 232. Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Signed-off-by: cuishuang <imcusg@gmail.com>
* fix(macOS): preserve release entitlements during signing Signed-off-by: Sidn <3996515+sidnvy@users.noreply.github.com> * ci(macOS): sign outer app with release entitlements Signed-off-by: Sidn <3996515+sidnvy@users.noreply.github.com> --------- Signed-off-by: Sidn <3996515+sidnvy@users.noreply.github.com>
…ustdesk#16124) A controlling peer whose link dies without a close reconnects, while the connection it left behind runs on here until its own 30s inactivity timeout. That one then ends with `on_close("Timeout", true)`, and the lock is gated only on `lock_after_session_end` and this connection's own `keyboard` - both set by the very controller that is at that moment working in the session its reconnect re-established. Nothing anywhere asks whether the session is still being controlled, so the screen locks under a peer that came back twenty-odd seconds earlier, and the operator's desk locks itself in front of them. The lock now also requires that no newer remote control connection of this session is authorized. Newer, not merely other. A connection stays in `AUTHED_CONNS` until its `AuthedConnID` drops, which is well after `on_close` returns, so a symmetric test would have two of one session ending together each see the other and neither lock. Ids come from a counter, so `>` orders them: of a session's connections the last still locks, whether they end one after another or at once. Remote control only, and this session only. The other kinds do not keep a screen in use, and `send_logon_response` clears `keyboard` for a file transfer, a terminal and a camera view, so none of those reaches the gate at all - a port forward keeps it, and is kept out only by the client not sending `lock_after_session_end` on one. Another peer's session is left exactly as it is: whether its ending locks the screen while this one is connected is a separate question, and not one a timeout on this side should start answering. Every close that asked to lock, not only the timeout. A connection its own peer has already replaced should not lock the session that replaced it however it ends, and singling out one reason would leave the same race reachable through the others. Two things it does not cover. A reconnect that has not authorized yet is not in `AUTHED_CONNS`, so a timeout landing while one waits at the accept prompt or on 2FA locks as before. And the lock is skipped, not handed on: if the connection that replaced this one later ends through a path that asks not to lock - a failed send, a stopped service - nothing locks. That is what those paths already choose for a connection dying of a network error, on the assumption that the peer will retry, and it is the same assumption this makes. Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* first improve Signed-off-by: 21pages <sunboeasy@gmail.com> * fix(qos): avoid reducing FPS for transient network jitter Require consecutive bad samples to confirm congestion before normal FPS reductions. Prefer bitrate reduction when ABR is available and allow an outstanding probe to complete before evaluating its effect. Recover FPS faster on fresh good samples while preserving severe-delay and timeout protection. Add regression coverage for jitter, bandwidth changes, and multiple viewers. Signed-off-by: 21pages <sunboeasy@gmail.com> * test(qos): virtual clock and a closed-loop link simulation Tests drove time by moving `Instant`s into the past, which panics on a host that booted less than two minutes ago, and the ABR smoke had to detect ratio changes to keep its fake clock consistent. `VideoQoS` now reads the clock through `now()`; tests set a virtual instant and advance it. `tests/sim.rs` drives the controller the way `Connection` does, over a link with variable frame sizes, wobbling capacity, heavy-tailed jitter, retransmission stalls and link stalls, with both a bitrate-targeted (VP8/VP9/AV1) and a fixed-rate (hardware) encoder model. It prints one table row per scenario; the assertions arrive with the controller changes. The short-stall smoke sweeps the stall phase instead of three fixed values. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): keep jittery but healthy links fast, drain congestion with bitrate A weak home Wi-Fi with plenty of capacity but frequent jitter and the odd stall ended up at about 10 fps: single bad replies, the two second probe timeout and a slow climb back each took their share. The controller now treats a transient stall and a saturated link differently. - The probe timeout no longer slams the frame rate to 2. Every second the probe stays out beyond the first halves it instead, and the late reply that finally closes the probe does not reduce again. - After a reduction, good replies return halfway, then fully, to the level held before it. A restored level that congests within five replies becomes a lower ceiling, so a real capacity drop converges instead of oscillating. - VP8, VP9 and AV1 run CBR against timestamps: fewer frames only means bigger frames. While the bitrate can still be reduced the frame rate keeps its floor, and three bad replies in a row confirm congestion and halve the bitrate instead of stepping it down by a fifth every three seconds. - `bitrate_first` now means the bitrate can actually still drop; at the floor, congestion during the adjustment cooldown reduces the frame rate (Greptile). - `avg_delay()` subtracts the baseline with `saturating_sub`; at exactly the baseline it returned the whole delay, which kept the bitrate of a stable high-RTT link from ever recovering. - `HISTORY_DELAY_LEN` kept three samples, not two. - Every ratio adjustment resets the dynamic screen counters, so a long congestion episode cannot make a static screen look dynamic (CodeRabbit). - One `qos_trace` debug line per probe reply and per timeout, for replay through `tests/sim.rs`. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): adapt each viewer from its own target, not the shared minimum `user_network_delay` started every viewer's adaptation from `self.fps`, the minimum over all viewers. One congested viewer therefore pulled the others' targets down with it, and when it recovered the stream stayed low until the others had climbed back on their own. The per-viewer memory added for restores made the coupling worse: a viewer recorded another viewer's low rate as its own pre-congestion level (Greptile). Each viewer now adapts from its own `delay.fps`, falling back to the shared value only for its first reply; `adjust_fps` keeps aggregating the minimum. The replay test now fails on a malformed trace value instead of dropping it (CodeRabbit). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * test(qos): paired network trace, bitrate-conserving encoder, twenty seeds The simulator drew every random quantity from one stream, so two controllers with the same seed saw different links as soon as they produced a different number of frames; the A/B was not paired. The link trace (capacity wobble, stalls, loss events) is now generated before the run from a network stream of its own, and encoder noise and probe jitter have separate streams. The CBR model let a scene change add three frames' worth of data every five seconds without clawing it back, which raised the offered load of any controller that lowered the frame rate (up to +27% at 2 fps). The encoder now repays the surplus over the following frames and the size spread has mean one, so the long-term load no longer depends on the frame rate. Every scenario runs over twenty seeds and the assertions bound the distribution: median of the mean target, worst p10, p90 of the time below half the limit and of the queue p95. The bounds state what the product needs, not what one seed produced. New columns: produced and delivered frames per second, delivered frame age, sustained recovery (target at the limit and queue under 200 ms held for five seconds), cold-start minimum and time to 90% of the limit. The replay advances by recorded `t=` deltas when present and is labelled as the open-loop, FPS-only diagnostic it is. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): baseline from the first reply, bitrate cuts on confirmation only Two findings from the design re-check. The baseline needed ten replies before it was used, so a stable 180 or 300 ms link spent its first ten seconds read as congested: the frame rate fell to 5 and the bitrate was cut before either recovered. The running minimum is the baseline from the first reply on; the smoothed estimate takes over once the window is full. A single reply a second above the baseline, or a single timer tick with the probe out for two seconds, cut the bitrate by a fifth. A static screen never earns an increase back, so repeated stalls ratcheted its ratio down and the next dynamic episode started from there. Bitrate cuts now need two bad replies in a row, or a probe still outstanding at the second tick past two seconds; the frame rate brake and the severe-reply rule are unchanged. An elevated but unconfirmed delay no longer restarts the ratio cooldown, so a confirmation on the next reply is acted on at once. `qos_trace` lines carry a millisecond timestamp for the replay test. The simulator asserts the intercontinental cold start: minimum target at INIT_FPS and 90% of the limit within ten seconds. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * test(qos): held-out seeds and parameter sensitivity as guards against tuning The scenario bounds now live in one function shared by the CI run over seeds 1 to 20 and by `robustness.rs`, whose two ignored tests apply the same bounds to seeds 21 to 120 in blocks of twenty and halve or double each scenario parameter in turn. Anyone changing a controller constant or a bound runs them; a bound that fails on unseen seeds was fitted to the CI seeds. At this head every held-out block passes, with medians within a few percent of the CI seeds, while master fails five of five blocks in every home Wi-Fi row. The sweep keeps the lead over master in all fourteen variants for the frame-rate metrics and shows two limits worth knowing: at 6 Mbps of capacity both controllers hold about 2.4 s of queue p95, and at a drop to 1.5 Mbps both are poor because the 1 Mbps bitrate floor leaves little to drain with. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * test(qos): frame age bounds, wall-clock scene changes, time-indexed probe jitter The queue metric divides the queued bytes by the nominal capacity, so during a link stall it reports how long the backlog takes to drain afterwards, not how long the frame at the head has already waited. Frame age, the time a delivered frame spent in the shared path, was computed but not bounded. It is now bounded per scenario, as a regression bound set from the scenario rather than from a run: 1.5 s on the home Wi-Fi rows (isolated stalls of up to 2.5 s are tolerated, a sustained multi-second backlog is not), 100 ms on a clean link, 150 ms on a stable high-RTT link (frame age excludes the round trip, so RTT earns no allowance), and the same bound as the queue on the bandwidth-drop and mobile rows. Two residual couplings between controller decisions and the exogenous inputs are removed: scene changes follow the wall clock instead of the frame count, and probe jitter is a per-second table drawn before the run, so two controllers with the same seed meet the same content timeline and the same jitter. The moderate-congestion smoke profile now asserts that the frame rate actually drops, and the held-out test builds its combined summary from the block reports instead of simulating every seed twice. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * test(qos): remove the placeholder viewer from trace replay Clear the synthetic viewer created by smoke::session so it cannot cap replayed FPS at 15 when the recorded connection ID differs from 1. Add a regression test verifying identical FPS sequences for connection IDs 1 and 1652, both recovering to 30 FPS. Signed-off-by: 21pages <sunboeasy@gmail.com> * fix(qos): cap each viewer by its own limit, judge bitrate steps per viewer Two places still let one viewer's state leak into another's. The per-viewer target was clamped by `highest_fps()`, the minimum of every viewer's limit, before being stored, and a new viewer started from the shared stream rate. A viewer that lowered its limit dragged the others' targets down with it, and when it left the stream stayed there until the others had climbed back; a viewer joining a congested session started at the congested rate. Each viewer now starts at INIT_FPS, is capped by its own limit only, and `adjust_fps` keeps applying the shared limit to the aggregate. `adjust_ratio` paired the maximum delay over viewers with any viewer's confirmation, so one viewer's unconfirmed 1200 ms spike and another viewer's two 200 ms replies produced a 20% cut, and a third mild reply a halving, when each viewer on its own called for five percent. Each viewer's own delay and confirmation now decide the step it calls for, and the stream takes the most conservative one; increases still need every viewer below the threshold. Single-viewer behaviour is unchanged. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * test(qos): replay advances by the wall clock across connections The replay kept a last timestamp per connection id, so a log with several viewers each writing once a second advanced the virtual clock once per line and replayed several times slower than it was recorded. It now advances by the delta between consecutive lines whatever their connection. The replay is a plain function over the log text, with the environment-driven test as its entry point, so the time axis can be tested directly. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): first reply keeps the ratio cooldown, closing a viewer re-aggregates A viewer's first TestDelay reply called `adjust_ratio` with no cooldown check. With the per-viewer steps, that scan finds the other viewers' still confirmed evidence, so a viewer joining right after a cut halved the bitrate a second time inside the three seconds the cut is meant to be observed for. The first reply is now one more trigger of the periodic adjustment and keeps its cooldown; a fresh session still adjusts on its first reply, since its controller was created long before. Linux was never on this path. `on_connection_close` removed the viewer without re-aggregating, so the stream stayed at the departed viewer's rate until the next tick; the remaining viewers are aggregated at once. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): the newcomer guard belongs to the viewer that joined Re-aggregating on close applied the one-second INIT_FPS guard that the departing viewer had set when it joined, so a viewer that connected and dropped within a second throttled the others to 15 fps for the rest of that second. The guard now records which viewer set it and is cleared when that viewer leaves; a genuinely new viewer is still capped for its first second. The first-reply ratio adjustment's platform switch is a field instead of a `cfg!` inside the condition, so the cooldown regression test exercises the path on Linux CI as well. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): every newcomer carries its own start-up guard The start-up guard had one slot, so a second viewer joining within a second overwrote the first one's join time, and when the second viewer left the first one's window was released early. The join time now lives in the viewer's own entry, `adjust_fps` caps the stream while any viewer is inside its first second, and a departed viewer takes its guard with its entry; no clearing logic is needed (Greptile). Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): adapt delay baselines and speed up FPS recovery - Relearn stable baseline increases from recent fresh replies. - Require fresh congestion confirmation between ordinary FPS reductions. - Keep automatic FPS reductions above a 5 FPS floor, respecting lower caps. - Restore FPS after two good replies, with rollback on renewed congestion. - Add regression tests for baseline changes, jitter, and FPS recovery. Signed-off-by: 21pages <sunboeasy@gmail.com> * test(qos): align FPS floor tests with the 5 FPS minimum - Remove the unregistered sustained tests with outdated expectations. - Test severe delays and timeouts independently, including lower user caps and recovery. - Move the 700 kbps scenario into active adaptation tests, checking the FPS floor and recovery after bandwidth returns. Signed-off-by: 21pages <sunboeasy@gmail.com> * fix(qos): a timeout never lifts a target, and the invariants as property tests The timeout brake floored its output at MIN_FPS + 1, so a viewer whose target had already reached 1 fps was lifted to 2 by the next tick past two seconds: bad evidence raising the frame rate. Inherited from master, where the timeout set the whole stream to MIN_FPS + 1 outright. The brake now never exceeds the target it found, whatever the elapsed time it is told. The controller's six invariants become property tests over random sessions (150 seeds, 300 steps, one to three viewers, ABR on and off): a viewer's target is independent of other viewers; bad evidence never raises a target or the ratio; joins and leaves only change the aggregation; a bitrate cut is owned by a viewer's own evidence and not spent again by a newcomer; targets stay within their caps and the stream is their aggregation; a braked probe's late reply does not brake again. The timeout case is also pinned exhaustively over every target and a range of elapsed times. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * feat(qos): log the encode and send pipeline behind RUSTDESK_QOS_VERBOSE The controller's target frame rate is neither the rate the encoder produced nor the rate the send path accepted, and two facts kept that gap invisible. libvpx drops frames on its own when the bitrate cannot carry them, so a capture round is not a delivered frame. The video send is inline in the connection's message loop, so a slow write stalls capture and the delay probe alike, and the recorded delay cannot tell the two apart. `qos_video` reports, per second and per display, the capture rounds, the frames that actually reached a connection, and the longest wait for the previous frame to be picked up. `qos_send` reports, per second and per connection, how long `stream.send().await` blocked and how deep the video queue is. Both carry `t=`, so they join with `qos_trace` offline; `replay` filters on `qos_trace` and ignores them. The default log level is `debug`, so an unconditional line would land in every user's log file once a second forever. Neither line is emitted unless `RUSTDESK_QOS_VERBOSE` is set, nothing enables it implicitly, and without it the timing calls are skipped as well. TestDelay, the controller and every threshold are untouched. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PARvswNPeZ88LVT7Ew5hkp * fix(qos): speed up FPS ramp-up on clean connections Double startup FPS after every two fresh low-excess-delay replies, up to the viewer's cap. End acceleration on queue growth, timeout, or FPS reduction. Add regression tests for startup speed, viewer caps, congestion, timeouts, and multiple viewers. Signed-off-by: 21pages <sunboeasy@gmail.com> --------- Signed-off-by: 21pages <sunboeasy@gmail.com> Co-authored-by: RustDesk <71636191+rustdesk@users.noreply.github.com> Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com>
* webrtc: recover from a silent peer in about 8s instead of 30s A controlled peer that is killed, switched away by a user switch, or rebooted leaves no trace on a UDP transport: there is no reset to receive, so the session sees silence, and only the 30s inactivity timeout ends it. By then the remote machine may have finished rebooting and be reachable again, while the user has been watching a frozen frame the whole time and is then told the peer reset the connection. ICE already knows sooner. It reports Disconnected about 5s after it stops hearing from the peer, from its own task, so it stays accurate even while this loop is busy sending. That state is transient by design - a Wi-Fi roam or a sleep/wake recovers from it - so it is treated as suspicion, not as death: three more seconds with the transport receiving nothing, and the session reconnects. Receive progress cancels the suspicion, so a peer that is merely slow, or one ICE was late to clear, is not dropped. This only reaches the existing recovery sooner; it does not replace it. The first reconnect goes out immediately and, if it fails, falls into the same retry the UI already applies to any unexpected disconnect. The restart reconnect event is reused deliberately: it is what asks for exactly that, with no error dialog in front of it, and the UI shows "Connecting..." for it rather than anything about restarting. Its five-minute grace stays reserved for a restart the user actually asked for - silence is no evidence of a reboot. The 30s timeout is unchanged and still backs every transport. TCP and WebSocket are untouched. The controlled side is untouched: it detects a dead controller on the same 30s, which wastes some capture but nothing a user sees. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns * kcp: recover from a silent peer on the endpoint's own clock KCP is the other transport with nothing to receive when the peer dies, and it was the slower of the two: its endpoint reaps a connection only after 60s without a packet, which is past the 30s inactivity timeout above it, so in practice nothing but that timeout ever noticed. The endpoint already tracks when each connection last heard from its peer and now exposes it, so this reads that rather than anything derived from the session loop - it keeps answering while that loop is busy sending. Its liveness ping now goes out about every 2s rather than every 10s, so silence means the peer rather than an idle link, and eight seconds of it is several missed pings. Same threshold and the same recovery as the WebRTC half, so a user sees the same thing on either transport. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns * review: time the inactivity window off receive progress, bound the parting send Two things the review found, both on the controlling side. The 30s inactivity window still ran off completed messages alone, so the probe added for the fast path did not fix what it was added for: a message larger than the transport's fragment size yields nothing until its last fragment, and a peer sending one steadily was still timed out mid-transfer. It is now timed off whichever is later, a completed message or receive progress. Transports that report no progress leave that at its starting value, so nothing else moves. The parting close-reason send for KCP waited on send capacity with no deadline of its own, and a queue a dead peer will never drain held the finished session's thread until the endpoint reaped the connection a minute later. Bounded once the peer has been declared gone. Still attempted rather than skipped: if the loss was one-way the peer does receive it, and drops its side immediately instead of waiting out its own timeout - which is also the one case where the note below resolves itself. Recorded from the same review, for the case none of this targets - a peer that is alive behind a path that broke for five to ten seconds and then healed. Giving up cannot deliver a close there, because the path is still down at that moment, so the controlled side keeps the old connection until its own 30s expires. For up to twenty of those seconds it holds two authorised connections: its connection manager lists both, and the stale one reports a growing delay that pins the shared frame rate low for the new one. Input is unaffected throughout and both recover once the stale connection goes, so this trades twenty-two seconds of a frozen, uncontrollable session for a controllable one that looks wrong for a while. Closing the displaced connection is controlled-side work and belongs with the rest of it, not here. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns * review: reject a disconnected cached session, tidy the detector hbb_common: `is_reusable_for` now also rejects a session ICE reports Disconnected, so a caller is not handed one that already carries the hint; and the receive-progress test no longer races `next()` against a sleeping sibling. Here: the `is_some()` guard on the progress comparison was dead, since a transport answers `None` for its whole life and `None != None` is already false. The parting-send deadline is a `Duration` like every other constant around it rather than bare milliseconds. And the comments are cut back to what is not already evident from the code they sit on. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns * review: keep the legacy UI's retrying error when the peer goes silent `restarting-show` is a Flutter control event; Sciter has no case for it and falls through to a plain dialog, which `check_if_retry` marks non-retryable because its type is not `error`. So on that build the new detector would have replaced a timeout that reconnects on its own after 30s with a dialog waiting for a click at 8s - a regression for the one path this was meant to shorten. Send it the message the timeout already sends, so its behaviour is unchanged apart from arriving sooner. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns * review: keep the 30s watchdog hard, and let Android's picker hold the reconnect Timing the watchdog off receive progress gave away its upper bound. A fragment bumps the counter as it arrives, ahead of the framing checks that would reject it, so a peer sending one `FRAG_MORE` every twenty seconds and never a `FRAG_END` refreshed the deadline forever while the reassembly buffer grew toward `MAX_FRAME_LENGTH`, a gigabyte away. What it bought - a clipboard image that takes longer than thirty seconds to arrive is not a dead peer - is a pre-existing problem that predates this branch and can be fixed on its own. Receive progress goes back to the one job it was added for, which needs no deadline of its own: telling a transport that has gone quiet from one that is still delivering, so ICE's disconnected hint is not acted on mid-transfer. The Android document picker suppresses a `Connection Error` while it is open and remembers to reconnect once it closes. The peer-gone break reconnects under `restarting-show` with a `Connecting...` title, which matched neither half of that test, so an eight-second stall behind an open picker - Doze and background throttling produce them - threw a dialog up behind the picker and lost the deferred reconnect. It is now named there by its own title rather than by its type: an explicitly restarted remote device sends the same type from a path this leaves alone, on every transport, and deferring that one too would be a change to sessions this has no business touching. The two limits are still not hard upper bounds, and the comment saying so was wrong about why. A send is awaited inline in this loop, so one in progress delays the tick that checks them - bounded on WebRTC by the timeout the stream was built with, not bounded at all on KCP, whose framed stream is constructed with none. The 30s watchdog beside it shares the loop and the same delay. Left alone deliberately. `restarting-show` reconnects without the backoff its `restarting` sibling uses, which can loop while each round gets far enough to establish a session and then loses the transport within eight seconds; a cooldown there would also delay the recovery this exists for when a peer really does come back, and the loading it shows can be cancelled. And the KCP limit reads an accumulated silence rather than a transient hint, so unlike the WebRTC grace it needs no second sample to confirm - one would only move eight seconds to nine. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019aokqJuhjvB3kijXtAg5Ns --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
* wayland: say which step of the portal handshake failed
The XDG portal handshake is four sequential requests, and every way it can end
badly -- the user declining, the request being dismissed, a timeout, the portal
being absent or dying mid-handshake, the stream list coming back empty -- left
`request_remote_desktop` through one `bail!` carrying one string.
`map_err_scrap` then guessed a cause by looking for "dbus" or "pipewire" in
that string. Since that string always mentions "PipeWire library", a decline
and a three-minute timeout both came out as "Wayland requires higher version of
linux distro. Please try X11 desktop or change your OS." On Ubuntu 21+, where
the mapping passes the text through untouched, they came out as raw English
pointing at an unrelated GitHub issue.
The response code and the D-Bus error were in hand at the moment of failure and
were being dropped: `handle_response` collapsed all of it into one
`AtomicBool`. Record it instead, tagged with the stage that produced it, and
let the app side look the tag up. `map_err_scrap` gains one leading branch;
anything untagged -- which is everything the capture loop reports -- takes the
existing path unchanged.
What the peer is told is chosen from the tag, and only from facts the tag
actually carries:
- A decline and an interaction that ended some other way are separate outcomes
and say so. The Request spec defines response 1 as the user cancelling, and
guarantees nothing more about 2 than that it ended -- libportal treats 2 as a
plain failure -- so 2 says the request ended without completing and does not
guess who ended it or why.
- A timeout says it timed out. It does not say nobody answered: RustDesk passes
a saved `restore_token` with `persist_mode` 2, and a restored session is
exactly the case where the portal shows no picker at all, so there may have
been no dialog for anyone to answer.
- Not reaching the session bus, a portal that answers but does not implement
what was called, and a grant that fails only when the PipeWire connection is
handed over, each get their own message. None of the three is fixed by
restarting the portal, so none of them is told to. Each says only what its
evidence supports: failing to open the session bus does not prove nobody is
logged in, and `UnknownMethod` on RemoteDesktop does not prove the portal
cannot capture a screen. Which interface was called is in the D-Bus message
that goes to the log; the message to the peer does not claim one.
- What is left -- the portal absent, silent, or failing mid-handshake -- keeps
the existing `xdp-portal-unavailable`, which is already translated everywhere
and carries the one remedy that fits: `systemctl --user restart
xdg-desktop-portal`.
- The Ubuntu-before-21 branch keeps every outcome that says something about the
machine and yields the three that say what happened to the request.
Two more say less than they could, for the same reason. `streams_from_response`
comes back empty when the response cannot be parsed as well as when there is
nothing in it, so the message says RustDesk did not obtain a usable screen
rather than that the portal offered none. `ElementFactory::make` fails the same
way for a plugin that is absent as for one that will not load, so the message
says the component could not be loaded rather than that it is missing.
The D-Bus error name and message, the portal response code and the GStreamer
factory's own error go to the log. Only the element name also reaches the peer,
because it is the one detail that says which package to look at.
`fill_displays` needs the tag resolved at its own call site: it opens a second
portal session for cursor-based display disambiguation, and its error returns
straight up `check_init` without passing through `map_err_scrap`, so a tag
would otherwise reach the peer verbatim.
Two existing paths change, both necessarily:
- `check_init` no longer wraps `Capturer::new` in `with_context`. The peer is
shown `format!("{}", err)` (connection.rs), which renders only the outermost
layer, so that context was replacing the mapped code with "Failed to create
capturer for display 0".
- The `std::process::exit(-1)` on libdbus' no-reply text is now reached only by
the capture loop, which is what that self-heal was written for. Every D-Bus
call in the handshake -- opening the session bus, `get_request_path`, the
`add_match` inside `handle_response`, `create_session`, and `conn.process` in
the wait loop -- carries a tag, so a no-reply there is reported rather than
fatal. It is worth saying plainly what that branch did before: the portal
proxy has a one-second timeout, so a portal slow to activate could take the
whole service down.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
* wayland: lang keys for the staged portal failures
Eight keys, appended to `template.rs` and to every `src/lang/*.rs`. `it.rs`
gets empty values, as AGENTS.md requires -- it is maintained by hand by its
translator. No `en.rs` entries: each key is already its own English display
text, which is also what an older peer falls back to.
One carries a `{}`, the name of the GStreamer element that could not be created
-- the one detail that tells a user which package to look at. `lang.rs`'s
`extract_placeholder` resolves a key by replacing the first `{...}` with `{}`,
which is why the server sends the value still inside the braces and why the
scrap side strips braces out of any detail before it gets there. Everything
else technical stays in the log: a D-Bus error name or a portal response code
in a dialog is noise to the person reading it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
---------
Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
) * fix(macos): recreate system-stopped audio capture streams Pin CPAL's ScreenCaptureKit stop notifications and retain interruption state with each capture stream. Recreate an interrupted stream through the existing service restart path, outside the backend error callback, and resend its audio format. Late callbacks cannot restart a replacement. A natural -3821 stop was observed with the remote connection still open. Its OS trigger remains unknown and it has no deterministic natural reproducer. Controlled verification stops the real SCStream and delivers an explicitly marked -3821 notification; this is not a natural failure. Dependency: rustdesk-org/cpal#5 Validation: requested macOS Rust and Flutter debug builds; three full-crate regression tests; build check without ScreenCaptureKit; two controlled recreations on one connection with independently recorded receiver audio. * chore(macos): log audio capture startup and resumed samples * Update deps, cpal Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com>
dash_chat_2, window_manager and desktop_multi_window named only a url, so the lock recorded `ref: HEAD` for them. That holds while the lock is used verbatim, but any re-resolution -- an unrelated pubspec.yaml edit, a lock conflict resolved by regenerating -- re-reads HEAD and silently moves the plugin to whatever the fork's tip is that day. All three forks are ours and get pushed to, which is how window_manager and desktop_multi_window drifted across five lock bumps since July with no pubspec.yaml change to show for it. Each ref is the resolved-ref already in the lock, and all three still match their fork's HEAD, so nothing resolves differently today. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01EZ49AbZJYfm8NTp5yDPMab
Signed-off-by: Yann Antunes <yannantuneslopes123@gmail.com>
* fastlane: add pt-BR Android metadata Signed-off-by: Kauan Kelvin <kelvinkauan722@gmail.com> * Update fastlane/metadata/android/pt-BR/full_description.txt Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com> --------- Signed-off-by: Kauan Kelvin <kelvinkauan722@gmail.com> Co-authored-by: greptile-apps[bot] <165735046+greptile-apps[bot]@users.noreply.github.com>
Fix formatting and punctuation in full_description.txt
Updated documentation links and improved text clarity. pt-BR
…16142) * fix(audio): restart capture when the device is unavailable * refact: remove low-value test Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com>
* fix(audio): add streaming resampler * fix(audio): preserve stream resampling state * fix(audio): keep playback callback nonblocking * fix(audio): decouple capture conversion from dasp * fix(audio): support stateful samplerate backend * refactor(audio): isolate stream callback state * refactor(audio): group capture output options * fix(audio): clear stale playback state after startup failure Reset non-Linux playback state when stream startup fails to prevent new-format audio from using the previous stream or resampler. Add regression tests for failed format changes and successful playback. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): honor capture resampler selection and reuse buffers Use the selected resampling backend for fixed-frame capture. Convert samples directly into the input queue and reuse the PCM frame buffer. Add tests for anti-aliasing, thread transfer, and partial-frame draining. Signed-off-by: fufesou <linlong1266@gmail.com> * refact: reduce diffs Signed-off-by: fufesou <linlong1266@gmail.com> * test(audio): check resampler output count and passband energy Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): reset incompatible Linux playback state on startup failure Preserve compatible output streams when replacement startup fails. Clear state when no compatible stream exists and cover both paths in tests. Signed-off-by: fufesou <linlong1266@gmail.com> * perf(audio): reuse PCM buffers in the capture pipeline - Reuse capture framing, resampling, and channel conversion buffers - Deliver borrowed packets and write Sinc output into reusable storage - Add allocation and output-equivalence regression tests Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): smooth buffer discard discontinuities Signal receiver PCM discards and fade from the current playback output when the callback reaches the new timeline. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): add missing Cargo.toml Signed-off-by: fufesou <linlong1266@gmail.com> * perf(audio): move capture encoding off the CPAL callback Move Opus encoding and service delivery to a dedicated worker. Use a preallocated bounded PCM queue with explicit loss reporting. Add tests for callback allocations and queue saturation. Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): smooth capture gaps and report losses during backlog Signed-off-by: fufesou <linlong1266@gmail.com> * feat(audio): report capture queue high-water mark Track peak queued PCM packets and log the approximate queued audio duration alongside capture loss statistics. Signed-off-by: fufesou <linlong1266@gmail.com> * refact(audio): reduce diffs Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): avoid blocking capture on encoder queue contention Use preallocated queues with try_lock in the capture callback. Count and drop the current packet on contention, preserving drop-oldest behavior on overflow. Add regressions for paused workers, buffer reuse, and sequence wrap. Signed-off-by: fufesou <linlong1266@gmail.com> * fix: add the missing files Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): isolate zero-gate state per encoder Signed-off-by: fufesou <linlong1266@gmail.com> * refact: reduce diffs Signed-off-by: fufesou <linlong1266@gmail.com> * refact(audio): simple refactor Signed-off-by: fufesou <linlong1266@gmail.com> * fix(audio): avoid waiting on playback callback locks Use one PCM try_lock attempt and preserve queued samples during contention. Replace readiness locking with per-stream atomic status and report callback errors from the receiving thread. Cover callback progress, retained audio, recovery, and poisoned-buffer handling. * fix(audio): restart capture after processing errors Stop further processing until the service recreates the stream. Document the guard as defensive recovery for an unconfirmed failure. Group capture and resampler submodules under their parent directories. Signed-off-by: fufesou <linlong1266@gmail.com> * audio: report capture queue contention drops separately - Add contention_dropped to loss reports while preserving total drop counts - Document packet rejection on contention even when buffers are available - Extend existing contention and saturation test assertions Signed-off-by: fufesou <linlong1266@gmail.com> * refact unit tests Signed-off-by: fufesou <linlong1266@gmail.com> --------- Signed-off-by: fufesou <linlong1266@gmail.com>
…esk#16143) Co-authored-by: changshenhan <217217832+changshenhan@users.noreply.github.com>
* Update it.rs * Update it.rs * Update it.rs
* Fix Portuguese translations for error messages Fix Portuguese translations for error messages * Fix translation for RustDesk desktop session message * Update ptbr.rs
The row was added for the web client, which has no session tab to name the transport on, but nothing gated it: a desktop session over WebRTC showed it too, duplicating the tab tooltip's "(WebRTC)". The getter now answers only on the web, as its own comment intended. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QcJZZeJ3Nqb2MHxXuUadkb
* fix(ci): allow native x86 Rust toolchain on Windows * docs(ci): explain the rustup 1.29.1 host check * docs(ci): explain the unverified x64 cross-compilation alternative
* ci: use native ARM64 MSBuild for MSI packaging * ci: clarify MSBuild host and MSI target architectures
Debian Bullseye has reached end‑of‑life and is no longer supported. Signed-off-by: Marc Frank <78813606+D-MarcFrank@users.noreply.github.com>
Co-authored-by: Elyor1977 <elyor77q@gmail.com>
* Translate terminal clipboard tips to Portuguese * Update terminal clipboard write tip translation
FFmpeg 7.1 can deadlock during software HEVC decoding with WPP slice threading, as reproduced on Linux and macOS. Version 7.1.1 includes the upstream progress2 fix (79c47dfd25f101b6842bbec8c6ffef8d5077c3ae). Update the overlay version and archive checksum, reset the port revision, and document the fix. Existing FFmpeg patches and build options are unchanged, and decoding can retain its existing thread-count policy. Validation on macOS arm64: - Built the overlay successfully with all 23 existing patches. - HEVC four-thread replay: 1,000 rounds / 71,000 frames without a stall; resolution changes: 6,816 frames; H.264 replay: 4,100 frames. - VideoToolbox H.264/HEVC encoding with software and hardware decoding: all six cases matched the FFmpeg 7.1 baseline. - git diff --check and manifest/archive checksum validation passed.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
PR automático do workflow
sync-upstream.yml. Traz o que há de novo em rustdesk/rustdesk para o fork, via a branchupstream-tracking. Revise os commits antes de aprovar e mesclar - verdocs/AUTOMACAO-SYNC-RELEASE.md(seção 3.1).