fix: stop orphaned zms processes accumulating, without killing streams on tab hide

[connortechnology]

Fixes the orphaned zms accumulation reported in #4706, without killing streams on tab hide — which @connortechnology ruled out there, since killing takes the status polling and alarm sounds down with it.

Reproduced and verified on a live instance. Two monitors on a montage page, one simulated tab hide/show cycle each time:

	before	after 1 cycle	after 2 cycles	processes
stock zms + stock MonitorStream.js	2	4	6	replaced each cycle, old ones orphaned
with this branch	2	2	2	the same two, resumed

The pre-fix run is exactly the accumulation #4706 describes. With the branch the process ids do not change at all across the cycles, and both pictures are live afterwards.

The two defects

A stopped zms could never exit (src/zm_monitorstream.cpp:670). The stopped branch slept and continued without writing anything, so the socket was never touched and a client that had gone away was never discovered: no write, no EPIPE, no SIGPIPE. The continue also skipped the ttl check at the bottom of the loop, so even a caller's deadline did not apply. The only way out was an explicit CMD_QUIT, and a stream that missed one stayed until the machine was restarted. This is why they accumulate rather than merely appear.

The last captured frame is now held on entering the stopped state and re-sent every five seconds, as the paused state already does, and ttl applies here too. Confirmed in the logs of a running stream:

DB1 [Got STOP command]
DB1 [Saving stopped image from index 0]
DB2 [Sending keepalive frame while stopped]      <- every 5s thereafter

setLastViewed is deliberately still not called: capture and decoding should not be held active for a stream that is not playing.

select_zms() replaced the connkey without quitting the process it addressed (web/js/MonitorStream.js). Once the key is gone nothing can reach that zms again, so no CMD_QUIT can ever be delivered to it. getStreamCmdResponse() already learned this — its reload path calls quitConnKey() first, with a comment saying exactly why — but the path every ordinary start() takes did not. quitConnKey had precisely two references in the file: its own definition and that one use.

Resuming instead of rebuilding

The third commit makes the hide/show path resume the stopped zms with CMD_PLAY rather than build a new one — what CMD_STOP is designed for, and what the discussion on #4706 assumed should work. It did not, for three separate reasons, none of which were visible from reading:

1. stop() clears activePlayer, which is the only thing the resume branch tests, so after a stop it was unreachable.
2. srcAuthCurrent required a non-empty zmAuth.hash, which is '' whenever auth is off — so those installs always rebuilt, for no reason, since there is no hash that can go stale.
3. streamCommand() drops anything sent while !started, and started is not set until the end of select_zms(). The resume issued its CMD_PLAY into nothing. Resuming after a pause worked only because pause() leaves started set.

With those fixed the zms status reports stopped: 0 and ~15 fps — and the picture still looked frozen, because the rebuild path clears the "Loading..." info block from img_onload, which cannot fire when src never changes. The resumed stream was playing underneath its own overlay. Clearing the block on the resume path is the last piece.

@IgorA100 reported on #4706 that a CMD_PLAY after CMD_STOP does not restart the video. That was correct, and points 3 and 4 above are why.

Testing

• zms builds clean, no new warnings; full C++ suite 138/138 pass; ESLint clean on MonitorStream.js.
• Live before/after process counts as tabled above, on a 2-monitor montage page.
• Keepalive behaviour confirmed in zms debug logs.
• Resume confirmed end to end: same pids across two cycles, stopped: 0 and ~15 fps from the stream status query, and the burnt-in camera timestamp advancing in the browser afterwards.

Relationship to #4706

Supersedes it. Same diagnosis of the symptom, different mechanism: nothing is killed on tab hide, and the process that does get replaced is now told to quit rather than left behind.

🤖 Generated with Claude Code

[connortechnology]

Tested on a live instance and dropped one of the three commits as a result.

Before/after, two monitors on a montage page, one hide/show cycle each time:

	start	1 cycle	2 cycles
stock zms + stock MonitorStream.js	2	4	6
this branch	2	2	2

The keepalive works as intended — Got STOP command, Saving stopped image from index 0, then Sending keepalive frame while stopped every 5s, process alive and reachable throughout.

What I got wrong: the third commit made hide/show resume the stopped zms with CMD_PLAY rather than rebuilding. On paper that is what CMD_STOP is for. In practice the connkey and process are preserved, started returns to true — and the picture stays frozen on the keepalive frame. The streaming process logs viewing fps: 0.00 and goes on sending keepalives; no CMD_PLAY ever reaches it.

@IgorA100 said exactly this on #4706 and I dismissed it as the client re-creating the stream. It wasn't. Resuming on an existing connkey needs the command delivery path investigated first, which is a separate piece of work and not a MonitorStream.js change. That commit is gone; the branch now rebuilds as before, but quits the old process instead of abandoning it.

[connortechnology]

Update: the resume commit is back, and now actually works. My earlier comment said resuming a stopped zms was not achievable from MonitorStream.js — that was wrong, I stopped one layer short.

Three things were preventing the CMD_PLAY from ever arriving:

1. stop() clears activePlayer, the only thing the resume branch tests.
2. srcAuthCurrent demands a non-empty zmAuth.hash, which is '' when auth is off — so those installs always rebuilt, though there is no hash that can go stale.
3. streamCommand() drops anything sent while !started, and started is not set until the end of select_zms(). The resume was issuing its CMD_PLAY into nothing. Resuming after a pause works only because pause() leaves started set.

With those fixed the stream status came back stopped: 0, ~15 fps — and the picture still looked frozen. That last part was a red herring of the same kind: the rebuild path clears the "Loading..." info block from img_onload, which cannot fire when src never changes, so the resumed stream was playing underneath its own overlay.

Live result on a 2-monitor montage page, two hide/show cycles:

• the same two zms pids throughout — not replaced, not orphaned
• both pictures live afterwards, camera timestamp advancing

So hide/show now costs nothing to return from: no new process, no restart latency, and the status polling that drives alarm sounds is never interrupted. @IgorA100 — your observation on #4706 that CMD_PLAY after CMD_STOP does not restart the video was right; points 3 and 4 are why.