Talon/RemSound
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Release v4.8: fix rare crash from endpoint thrash on a dual-address peer (#16)

Browse Source 
The same singer hit a rare crash: their transmitter (COMP3) was reachable at two
addresses at once — the VPN address 10.8.0.1 they chose and that machine's wireless
192.168.3.245 — and the discovery-driven endpoint-follow ping-ponged the connection
between the two (the log shows four moves in 58 ms) right where the process died with
no shutdown line, no managed exception, no dialog: a hard crash from the receiver
audio-session teardown/rebuild churn the thrash caused.

Fix: the follow loop now never moves off an endpoint that's still answering heartbeats,
only follows once the current one has been unreachable for a sustained grace period
(6 s), only to an address that is itself answering, and never more than once per cooldown
(15 s) — so it can't thrash, and a peer reached on a working address stays put (honours
the singer's "just stay on 10.8.0.1"). New endpointUnreachableSinceUtc + lastEndpointMoveUtc
state; genuine DHCP/network moves are still followed a few seconds later.

Also: a global crash handler (Program.WriteCrashReport on AppDomain.UnhandledException +
TaskScheduler.UnobservedTaskException) writes a crash-*.txt into the logs folder, so a
future "RemSound just vanished" report leaves a stack behind. Removed a stale doc comment
left over from the v4.7 adoption removal. Manual gains a "RemSound closed unexpectedly"
troubleshooting entry. Version 4.8; About + RELEASE_NOTES updated.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
Ednunp
2026-06-27 22:57:49 +01:00
co-authored by Claude Opus 4.8
parent 64d5cb5a86
commit 0df2a576fc
7 changed files with 119 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files
readme.html
+3
View File
@@ -1294,6 +1294,9 @@ RemSound.exe --connect 192.168.1.42
<h3>A peer rebooted or changed address and the sound didn't come back</h3>
<p>RemSound keeps trying the address you connected to, so when a peer comes back at the same address &mdash; the usual case after a reboot &mdash; the sound returns on its own within a few seconds, with nothing for you to do. If the peer comes back at a <em>different</em> address (a new DHCP lease, say), reconnect to it: pick it again from <strong>Discovered peers</strong>, or enter its new address with <strong>Add peer by IP</strong> (Connectivity tab, Alt+A). If the sound still doesn't return, the peer is genuinely unreachable &mdash; off, asleep, or a firewall is blocking the path.</p>
<h3>RemSound closed unexpectedly</h3>
<p>RemSound is normally very stable, but if it ever closes on its own, it writes a small crash file into your logs folder (the RemSound folder &rarr; <strong>user settings and logs</strong> &rarr; <strong>logs</strong>, named <code>crash-</code> followed by the date and time). There's nothing you need to do with it &mdash; but if it happens, sending that file along with your report records what went wrong, so it can be tracked down and fixed.</p>
<h3>One side says &ldquo;unreachable&rdquo; even though sound is flowing</h3>
<p>The health check-ins use the same channel as the audio, so if the sound gets through, the check-ins should too. If one side shows &ldquo;unreachable&rdquo; while the sound plays fine, make sure both computers are running the same version of RemSound &mdash; an older version on either end can speak a slightly different check-in language.</p>