Settings editor#

A browser page for configuring and operating the camera without SSH: edit settings.jsonc and /boot/firmware/config.txt, browse and pull takes off the RAW drive, review a take's frames, and see the live camera feed — all from one page over Wi‑Fi.

It is a Flask blueprint (src/module/app/settings_editor.py) served by the same process as the Web GUI, so it needs CineMate itself running. For the console that stays up when CineMate won't start, see the Recovery console instead.

Reaching it#

http://cinepi.local:5000/settings-editor

Over the camera's own hotspot (see Configuring the Wi-Fi hotspot):

http://10.42.0.1:5000/settings-editor

Layout#

The top bar carries a search box (filters every field/take on the current tab by name) and, on the two file-editing tabs, five more controls:

The four file controls and Save changes are hidden on Playback and RAW files, which edit no file. The search box stays.

For the live camera feed without leaving the page, see The live-view launcher below — it replaced a dedicated tab.

Four tabs run across the top of the page:

settings.jsonc tab#

The left rail groups the same fields settings.jsonc holds, unchanged in meaning from the Settings file reference — this page is a form over that file, not a different configuration surface:

Editing anything marks the page dirty (the header shows an "N unsaved" pill) but touches nothing on disk until you click Save changes.

Save & restart#

Clicking Save changes on this tab:

1. Backs up the current settings.jsonc to .settings-backups/ next to it (timestamped, last 10 kept).

2. Writes your changes. If only values changed, the surgical writer keeps every comment, the key order and the file's formatting. If a key was added or removed (a structural change), it falls back to a full rewrite, which is correct but drops every comment.

   A structural save loses comments without saying so

   The server composes a warning when this happens, but the page does not show it — the toast reads Saved. Restarting CineMate… either way. If you keep notes in settings.jsonc, recover them from the newest file in .settings-backups/ after a save that added or removed a key.

   A save now merges into the file instead of replacing it

   Until this release the saved document was built from the form's own fields alone, so any setting the page had no field for was not written back at all — it was dropped from settings.jsonc entirely. Observed on a camera 2026-09-13: one save removed the whole system.https and system.web_api blocks, blanked both cameras' tuning_file_override.path, emptied input_peripherals.pots and cleared sensors.cam1.camera_name. Nothing warned, and the camera kept running, because CineMate falls back to its built-in defaults for whatever is missing — so the loss stayed invisible until you read the file, or until a default differed from what you had set. On 2026-09-15 that is exactly what happened: a camera lost image_capture.hdr.imx585_clear_hdr_12bit, whose absence means "on", and 12-bit ClearHDR came back by itself.

   A save now writes the values the page carries over the file on disk, so a key with no field on the page keeps whatever it said. The page still owns what it builds in full: the GPIO in/out lists, the quad rotary's encoders, the per-mode fps ceilings and every value-steps list — removing an entry there still removes it. See "Settings with no field on this page" for what that now protects.

   Comments are a separate matter and are still lost on a structural save, as above. diff .settings-backups/<newest> settings.jsonc after a save remains the way to see exactly what changed.

3. Restarts CineMate automatically to apply the new file — the same effect as the CLI's restart cinemate, not a reboot. Recording stops if one is in progress.

You can also apply a save-in-place, or just restart with nothing pending, from System → Restart CineMate. The same pane's danger zone adds Reboot Pi and Shut down Pi for when CineMate itself is fine but the Pi needs a full restart or powering off — neither writes config.txt. Shut down Pi asks you to confirm first: once it answers, the Pi is on its way down and only someone at the rig can power it back on, so the page does not poll for it to come back the way a restart or reboot does.

All three post to the settings editor's own POST /settings-editor/api/power route, not the general web API's POST /api/v1/cmd — that route refuses reboot and shutdown unless system.web_api.allow_destructive is turned on in settings.jsonc, which it is not by default (see Web API). The settings editor already performs other destructive actions (formatting a drive, deleting a take) without that switch, so these three buttons work on an unmodified camera the same way those do.

The console under Restart CineMate is a live tail of the camera's own system.log, so runtime messages appear there as they happen — not only around a restart. It reconnects by itself, which is what you want across a restart: the stream drops as the service goes down and resumes when it comes back, so the restart appears in the log as the camera's own output.

Boot config (config.txt) tab#

Everything here needs a full reboot to take effect — restarting CineMate alone never picks up a config.txt change. The page shows the detected sensor modes for whatever is actually attached right now, separately from the overlay picks above them (those apply only after the reboot). CineMate only manages its own fenced block; anything you add to the file outside it survives updates and is untouched by this page.

Below the Save & reboot Pi card sits a second, separate row: Restart CineMate, Reboot Pi and Shut down Pi. These are the same three actions as the System pane's, placed here too so you don't have to leave this tab to reach them — none of the three saves or writes config.txt; that stays Save & reboot Pi's job alone, and Reboot Pi here ignores any unsaved edits on this page the same way the System pane's does.

i2c tab#

Shows which optional hardware is answering on the camera's I²C bus right now. Everything listed is optional — the camera records without any of it.

The bus is probed each time you open the tab, one byte read per address. Nothing here writes to the bus, so opening this tab cannot disturb an encoder someone is turning or blank a display mid-take.

Each row shows the address that answered. A device that is not found says which address was tried, so a board strapped to a different address is obvious rather than just missing.

The clocks#

The camera's system clock sets itself whenever it can reach the internet, over Ethernet or joined Wi-Fi. The RTC keeps whatever it was last given, so the two only agree after you copy one across.

Both tick live, in the camera's own timezone, and both are shown to the second in the same format so drift between them is obvious at a glance. The tick is done in the page from a timestamp the camera sends, and re-anchored every 30 seconds, so watching the clocks does not fork hwclock once a second.

Sync RTC runs hwclock --systohc and then reads the clock back to check it took. That readback matters: the CLI's set rtc time discards hwclock's exit status, so it reports success even with no clock attached. This reports what actually happened, including the case where the write needs a sudo rule the image does not have.

Missing hardware on the settings tab#

Sections for a board that is not answering are dimmed on the settings.jsonc tab, with a line saying so — the pot channels when there is no Grove HAT, the encoder rows when there is no quad rotary board, the OLED section when no display answers.

Dimmed does not mean disabled. The fields stay editable and their values stay in the file, so a rig can be configured before the hardware arrives, and unplugging a board never quietly rewrites the settings that describe it.

RAW files tab#

Storage shows a card per mounted drive: label, device and filesystem, free/total space, take count, and — for the active drive only — a Format… control. Formatting asks for confirmation, is refused while a recording is in progress, and is verified against the drive's actual filesystem after the dispatch completes rather than trusting the command succeeded.

Takes lists every take across all mounted storage, newest first by default (also sortable by oldest or largest), each with a thumbnail you can scrub for a quick frame check. Per take:

• Download — streams a zip of the take. Only one download runs at a time server-wide; a second attempt is told to wait. On a Chromium browser over a secure context (HTTPS, or localhost) it can write straight into a folder you pick; elsewhere it's a normal browser download.
• Delete — asks for confirmation, and is refused while that take is actively being written to.

Checking takes and using Download selected / Delete selected applies the same actions to the whole selection. Bulk delete refuses the entire request (not a partial delete) if any selected take is currently recording. Download selected with more than one take produces a single zip with each take in its own top-level folder — on a Chromium browser over a secure context it writes straight into a picked folder like the per-take download does; everywhere else (plain HTTP, the hotspot, mDNS, Safari, every phone) it's one combined zip as a normal browser download. Refusal/wait rules match the per-take download above.

Playback tab#

Reviews a take's frames, decoded live from the CinemaDNG files, at the settings' conform frame rate. Fully covered in Playback — including the storage-contention lockout that holds playback while a take is recording or its buffer is still flushing.

The live-view launcher#

A circular button fixed to the bottom-right corner of the page (#cinepiLiveLauncher), on every tab rather than a tab of its own. It replaced the settings editor's old embedded Live view tab, which ran the main Web GUI in an iframe.

With one camera detected it is a single button that opens the live Web GUI at http://cinepi.local:5000 — the same shooting screen a full tab would show, with the EXPERIMENT drawer and the record button. With two cameras it instead shows three small buttons (cam0, cam1, combined); whichever source the Web GUI is currently previewing is highlighted.

Unlike the old embedded tab, following the launcher navigates away from the settings editor rather than showing the live image inline. For the picture on its own with nothing drawn over it, use port 8000 instead of 5000 (8001 for a second sensor).