mirror of
https://github.com/ZoneMinder/zoneminder.git
synced 2026-10-12 11:43:13 -04:00
Isaac ConnorandClaude Opus 5
dd9e06fd78
MonitorPresets.ControlId hardcoded the row numbers controls.sql happens to produce, so the shipped presets only pointed at the right control as long as nobody changed the number or order of rows in that file. Nothing guaranteed that, and nothing detected when it broke. Removing the two duplicate Pelco rows earlier in this branch shifted every id from 10 up and silently re-pointed six presets at the wrong ptz driver. The name is the identity, so look the control up by it: ControlId = (SELECT `Id` FROM `Controls` WHERE `Name`='Foscam FI8620') controls.sql is sourced before the preset inserts, so the rows exist by then, and all 21 referenced names are unique in the table. ControlId is a nullable varchar, so even a missing control degrades to an unset control rather than failing the install. This also corrects three mappings that were already wrong on master, where a control had been inserted above the referenced row without the presets being updated -- exactly the failure the ids invite: Foscam FI9821W FFMPEG H.264 pointed at Foscam FI8908W Loftek Sentinel PTZ pointed at Foscam FI9821W SunEyes SP-P1802SWPTZ pointed at WanscamPT Verified on a full fresh install: 51 controls, 75 presets, every one of the 21 references resolving to the control named for it and none unresolved. Re-ran it with three extra controls inserted ahead of the shipped set, moving every id: the resolution is unchanged, which is the property the row numbers never had. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015Y6FieTwEXuLhhR4e2yiax