EdnunpandClaude Opus 4.8
0df2a576fc
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>
35 lines
2.2 KiB
Markdown
35 lines
2.2 KiB
Markdown
# RemSound v4.8
|
||
|
||
A rare crash fixed, and crash reports for next time.
|
||
|
||
## Fixed: a rare unexpected close
|
||
|
||
If a peer was reachable at two addresses at once — for example a transmitter on a VPN *and* the local network at the same time — RemSound could rapidly flip the connection back and forth between the two addresses. Usually harmless, but a fast enough flip could tear the audio down and rebuild it quickly enough to make RemSound close unexpectedly: you'd find the sound had stopped and the program gone, and relaunching brought it straight back.
|
||
|
||
RemSound now settles on whichever address is actually working and stays there, only following a genuine move once the current address has properly stopped responding — so the flipping, and the crash it could cause, are gone.
|
||
|
||
(With thanks again to the singer who reported it and sent the log.)
|
||
|
||
## New: a crash file if anything ever does go wrong
|
||
|
||
If RemSound ever closes unexpectedly, it now writes a small `crash-*.txt` file into your logs folder (RemSound folder → **user settings and logs** → **logs**). There's nothing you need to do with it — but if you ever hit a problem, sending that file in turns a "closed for no reason" into something that can actually be pinned down.
|
||
|
||
## Compatibility
|
||
|
||
**v4.8 talks to v3.3 through v4.7 with no trouble** — the over-the-network format is unchanged, so you don't have to update both ends at once. (Everyone still needs **v3.3 or newer**, where end-to-end encryption came in.)
|
||
|
||
## Install
|
||
|
||
1. Download `RemSound-v4.8.zip` from this release.
|
||
2. Close RemSound.
|
||
3. Extract the zip **over your existing RemSound folder**, overwriting program files when prompted. The zip is program files only — it won't touch your settings, profiles, logs or recordings.
|
||
4. Run `RemSound.exe`.
|
||
|
||
## Upgrading
|
||
|
||
**From v3.6 or newer:** Help → Check for updates installs v4.8 with the in-app updater — and if it can't finish, it puts your old version back exactly as it was.
|
||
|
||
**From v1.9–v3.5:** Check for updates works, but uses your current version's older updater for this one hop. If auto-update has been failing on your machine, install by hand using the steps above.
|
||
|
||
**v1.8 and earlier:** the auto-updater in those versions can't install updates — install by hand using the steps above.
|