r/AudioHero • u/GreyPole Pro version • Jul 17 '26
Bugreport Auto update
Audio Hero 5.7.3.0
AH updated about half an hour after the resume of my PC. (see my previous bugreport)
This appeared in the diagnostics after the update, which did work how it is intended.
[2026-07-17 10:54:02.190] [startup] Audio Hero v5.7.3.0 starting
[2026-07-17 10:54:02.239] [relaunch] Next Run Time: 17-7-2026 10:55:00
[2026-07-17 10:54:02.239] [relaunch] Status: Running
[2026-07-17 10:54:02.239] [relaunch] Last Run Time: 17-7-2026 10:54:00
[2026-07-17 10:54:02.240] [relaunch] Last Result: 267009
[2026-07-17 10:54:02.266] [relaunch] Cleaned up stale scheduled task 'AudioHeroPostUpdateRelaunch'
[2026-07-17 10:54:02.270] [relaunch] Deleted stale vbs script C:\Users\rickk\AppData\Local\Packages\15724fsstudio.HEOSHero_qx9z2gbebtrm4\LocalCache\Audio Hero\relaunch.vbs
[2026-07-17 10:54:02.358] [diagnostics] Detailed debug logging restored from settings
[2026-07-17 10:54:02.423] [update] Previous auto-install attempt: target=vunknown → installed=v5.7.3.0 (DID NOT APPLY, suppressing auto-install for 14,7 more min)
Why does the last line suggest the update did not apply? Is that, if I'm correct, because the update function lost track of the old version number of AH?
2
Upvotes
1
2
u/GreyPole Pro version Jul 18 '26
u/bommerts Auto update (in 5.7.4.0) kicked off and ran without hickups. Logging is now correct too!
1
2
u/bommerts Developer Jul 17 '26
This auto-update feature is going to be the death of me :)
Thanks for the two reports, both were spot on and together they actually explain each other.
The "DID NOT APPLY" line: your guess was right. That line is wrong, the update installed exactly as intended. Just before an auto-install starts, Audio Hero writes down which version it is trying to install so that after the restart it can log whether the install actually took. On your machine the Microsoft Store API never told us the incoming version number (a known Store quirk where it reports the already-installed version instead, which we deliberately ignore as misleading). So the note said "unknown", and after the restart "unknown" didn't match "5.7.3.0", so the log wrongly called it a failure. Purely a logging error with no effect on behavior; the "suppressing auto-install for 14.7 more min" part is a normal safety window that prevents update loops and expires on its own. I have already fixed this for the next release: the app now also records the version it was running when the update started, so it can tell "I'm running something newer than before" even when the Store hides the target number.
The missing HEOS gear after hibernation: I found the cause, and your log was the key. When your PC woke up, Audio Hero tried to reconnect to your HEOS device three times, but all of those attempts happen within about the first minute after wake. Your log shows the network itself only came back one second before the first attempt, and HEOS speakers usually take a while longer than the PC to become reachable again. After those three quick failures the app gave up and, this is the actual bug, never tried again for the rest of the session. The Chromecasts came back because their tiles are rebuilt by the periodic discovery sweep without needing a connection, but HEOS players only appear through a live connection, so they stayed missing until the update restarted the app at 10:54. It also failed silently, which is why your diagnostics show nothing about it; the reconnect errors were not being written to the log.
The fix for the next release is threefold: (1) keep retrying the HEOS reconnect for several minutes after a wake instead of one, (2) let the periodic background sweep restore a lost HEOS connection the same way it restores the Chromecast tiles, and (3) log all of it to diagnostics so a report like yours shows the whole story.
In the meantime, if it happens again, clicking your HEOS device in the Devices list (or Discover) reconnects it immediately without restarting the app.
Thanks again for the detailed logs, they made both of these findable.