mirror of
https://github.com/Vateron-Media/XC_VM.git
synced 2026-10-27 03:03:31 +01:00
obscuremindandClaude Opus 5
cea545fed0
Closes the two gaps left by the supervision work: the panel could not see what the daemon knew, and it kept trying to start a watchdog for streams that already had one. The daemon has no database access -- XC_VM's credentials are not available to it -- so `cron:streams` is the only path by which its view reaches the panel. It now asks once per pass which streams the daemon supervises, then for each reads GET /monitor/<id> and writes back `stream_status`, `pid`, `current_source`, and the codecs, resolution and measured bitrate the daemon derived from the bytes it is fanning out. Only fields the daemon could actually determine are written: it reports an unknown as unknown, and overwriting a correct value with a blank would be worse than leaving it alone. `monitor_pid` names a PHP process, and isMonitorAlive checks the pid's /proc/<pid>/exe is the PHP binary -- so for a supervised stream it always answers false. Two callers drew the wrong conclusion from that: * cron:streams started a PHP monitor on every single pass, which then immediately stood down again. * admin/live.php, on the on-demand connect path, started one and then waited its full three seconds for a `_.monitor` file that would never appear. That is latency paid on the viewer's connect, for nothing. Both now ask who is watching before concluding nobody is. An unreachable daemon falls back to exactly the old behaviour in every case. That distinction is load-bearing: supervisedIDs() returns null rather than an empty list precisely so a blinking socket is not read as "supervising nothing", which would start a PHP monitor for every stream on the node at once. The supervised set is fetched once per cron pass rather than per stream, since the loop runs over every live stream on the node and each call is a socket round-trip. Verified: php -l clean on every changed file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>