The client and the relay server are published from the same GitHub repo;
the server's releases use "server-" prefixed tags. RemSoundUpdater hit
/releases/latest, which is repo-wide — when a server release was newest,
the updater fed "server-v2.3" to ParseTag (-> a bogus 0.0.3) and concluded
"up to date", silently skipping real client updates.
CheckForUpdateAsync now lists /releases and picks the highest-versioned
release whose tag is a RemSound client tag (new IsClientReleaseTag: after
an optional leading "v", first char must be a digit). Drafts and
pre-releases are skipped. The server-side updater already filters to
"server-" tags, so client + server coexist in one repo cleanly.
Also rewrites build-release.ps1 with a data-safety check: it publishes to
a fresh staging folder and aborts the release if any logs/, profiles/,
recordings/ folder, .log file or remsound.config.json is present in the
staged output or the finished zip — preventing a repeat of the v1.5/v1.6
zips that shipped with developer logs and profiles.
No wire-format or audio-pipeline changes — v1.5/v1.6/v1.7 interoperate.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
v1.2's self-updater silently failed when the install folder lived
inside a Dropbox sync path. Dropbox held write locks on the existing
RemSound.exe / DLLs during the brief window between the parent exiting
and the helper script copying the new files in. The helper's robocopy
(/R:5 /W:1) gave up after 5 seconds, and the helper then
unconditionally relaunched the OLD binary — so the user saw the same
version they started with after pressing "Yes" on the install prompt,
with no visible error.
Helper script (BuildInstallScript) changes:
* Robocopy retries bumped to /R:60 /W:1 — up to 60 seconds per file.
Dropbox lock release happens reliably within that window in
practice.
* Robocopy exit code is captured and checked. Codes >= 8 are real
failures. On a failure the helper writes update-failed.txt to the
install folder with the cause + recovery steps, leaves the staging
folder intact, and does NOT relaunch the old binary. Earlier
versions silently relaunched the unmodified old binary, hiding the
failure.
* Helper appends a step-by-step trace to _update-helper.log (in the
install folder), with robocopy's own output included via /LOG+:.
* update-failed.txt, _update-helper.log, and _apply-update.cmd are
added to the /XF exclusion list so the helper's own state files
don't get copied to themselves on a repeat update run.
DownloadAndStageInstallAsync also clears any stale update-failed.txt
at the start of every new attempt, so a successful run leaves the
install folder clean.
readme.html "If install fails" section expanded with the new
update-failed.txt marker file behaviour and the _update-helper.log
location.
Wire format, audio pipeline, and recording feature unchanged from
v1.2 — this is updater-machinery-only.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
EdnunpandClaude Opus 4.7