* reset local start time at each recording boundary
* include the final frame's time when converting from wall to media time
Together at 30 fps these caused about 15 seconds of drift over 4 hours.
As noted in the changelog, this problem caused restarts to take a long
time, and the SQLite database to (slowly) grow without bound.
The problem was simple: the directory worker incorrectly aborted
`collect_garbage` if nothing was watching the result. For some
operations (e.g. reading from sample files) this is the correct
behavior, but in this case it contradicts the `Pool::collect_garbage`
contract.
LoadingButton was merged into the core Button component in MUI v7.
Replace all usages and remove the @mui/lab dependency entirely.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Remove @babel/core, @babel/preset-env, @babel/preset-react,
@babel/preset-typescript (Vite uses SWC via @vitejs/plugin-react-swc),
http-proxy-middleware (Vite has built-in proxy), and ts-node (unused).
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
React 19:
- Replace JSX.Element with React.JSX.Element (namespace moved)
- Update RefObject types to include null
- Remove forwardRef from FullScreenVideo (ref is a regular prop now)
- Fix snackbar test to use await act() for fake timer advancement
testing-library:
- @testing-library/dom 8 → 10
- @testing-library/react 13 → 16
- Use ReactNode instead of ReactElement in testutil
react-router:
- Rename react-router-dom → react-router (package consolidated in v7)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The default trailingComma changed from "es5" to "all", so many files
are reformatted with trailing commas in more positions.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Bump @emotion/react, @emotion/styled, react-hook-form,
@testing-library/jest-dom, msw, eslint-plugin-react, and
@testing-library/user-event within their current major versions.
Fix App.test.tsx race condition exposed by msw 2.12: wait for the
fetch error to render before test cleanup aborts the request.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
FullScreenVideo was a plain function component, so MUI's Modal/FocusTrap
could not attach a ref to it, producing three React warnings. Wrap it in
React.forwardRef and forward the ref to the outermost Box element.
Also fix an MUI warning about the modal content node not accepting focus,
by adding tabIndex={-1} to FullScreenVideo's root element.
`v0.7.26` introduced a busy loop error when the dir pool was shutting
down with multiple streams. This commit tests and fixes this scenario.
Also fixes a second problem in dropping a writer without an explicit
close would panic in debug mode about using (dropping) the blake3 hasher
while holding a lock. The check is meant to detect slow operations while
holding a lock. The panic wouldn't happen in release mode and probably
isn't a significant source of slowness, but fix it anyway.
The live view WebSocket handler was declared async and called
`await blob.arrayBuffer()` directly:
```js
onWsMessage = async (e: MessageEvent<any>) => {
...
const raw = new Uint8Array(await e.data.arrayBuffer());
...
};
```
When several WebSocket messages arrive in quick succession—as commonly
happens at stream start—the browser dispatches multiple concurrent
invocations of this handler. Each invocation independently awaits
`Blob.arrayBuffer()`. `LiveCamera.tsx` implicitly assumed that message
n's buffer would resolve before message n+1's buffer, which seemed
logical because they're on the same TCP stream. However, there's no
guarantee of this, and it apparently is not true on Firefox. Perhaps
it's about how FF schedules async tasks.
`LiveCamera.tsx` assumes in its timestamp handling that media segments'
blobs will be strictly resolved in the order they should be played.
Playing segments before their dependencies (e.g. non-IDR frames before
the first IDR frame) doesn't go well.
Fix: make `onWsMessage` synchronous and chain each blob onto a
sequential promise (`messageChain`) so that `processWsBlob` is always
called in arrival order, regardless of the implementation-defined
resolution order of individual `Blob.arrayBuffer()` calls.
Fixes#343.
TypeScript 5.7 made typed arrays generic (Uint8Array<TArrayBuffer extends
ArrayBufferLike>), which is no longer assignable to BufferSource (used by
SourceBuffer.appendBuffer), since ArrayBufferLike includes SharedArrayBuffer.
Since the data always comes from Blob.arrayBuffer(), it is always backed by a
plain ArrayBuffer, so use Uint8Array<ArrayBuffer> to reflect that precisely.
This puts a lot of state into a new `LockedStream` that was formerly
guarded more coarsely by the recording lock or more granularly by
`RecordingToInsert` locks. And it restructures `LockedDatabase::flush`
to avoid holding this lock while performing SQLite operations.
Streamers write only into a recent frames buffer in RAM, which the
directory pool workers asynchronously write to disk approximately once
per GOP, where formerly there was a write call per frame.
Before, streamers could fall behind due to slow sample file directory
disk I/O calls or if writing got stuck in a retry loop, for example if
out of disk space. If Moonfire falls too far behind in receiving,
cameras tend to disconnect or (sadly) mis-frame messages because they do
not handle this case well. This removes a confusing potential cause of
such errors.
In the new model, streamers never wait for disk I/O. Frames are buffered
up to a limit. Recordings are aborted if the I/O pool falls too far
behind. There's no retry loop.
This roughly halves CPU usage as thread hand-offs and syscalls are less
common. It also enables several desirable future changes:
* audio recording (which radically increases the number of frames and
thus would otherwise significantly increase CPU usage).
* "monitor mode" (allowing live view without recording to disk),
* further CPU reductions for live view (by skipping all SQLite ops and
disk I/O).
In the new model, streamers also rarely wait for SQLite database
operations either—now only on video parameter changes. That might go
away in an upcoming change too.
The "syncer" (which synced files/dirs and kept track of what has to be
flushed into the SQLite database when) has mostly gone away too. The
directory pool workers handle the syncing now, and then they notify
a new "flusher" for the latter portion.
I'd like to go further still and have the database as a whole be owned
by a dedicated thread, the only one that uses the SQLite connection.
This prevents the tokio threads from blocking on SQLite operations.
I tried out doing so before making the streamers less dependent on the
db, but the extra thread handoffs were awful for performance.
Now, all IO happens on each directory's two-thread pool with threads
named `dir-<PATH>`. Formerly, IO could happen on the per-stream writer
threads, per-directory reader threads, and occasional on even the tokio
worker threads.
The recording path uses more CPU than before due to extra thread
hand-offs. That will change in the next commit, which will radically
change the approach to writing.
Currently all errors from retina are `Unknown`, and these massive
backtraces are obnoxious when a camera fails on every attempt, with
only a second between.
* add `/var/tmp` to the image so it doesn't have to be mounted
* remove obsolete `version: 3` from compose snippet
* mention `/usr/share/zoneinfo` in error msg and troubleshooting guide
Since buildx v0.10.0, provenance attestations are enabled by default,
causing even single-platform `docker build --push` to produce a
manifest list (OCI image index) rather than a plain image manifest.
This breaks the subsequent `docker manifest create` step, which
expects plain image manifests as inputs:
ghcr.io/scottlamb/moonfire-nvr:v0.7.24-x86_64 is a manifest list
Fix by passing `--provenance=false` to suppress the attestation,
ensuring each per-arch tag is a plain image manifest.
Ref: https://github.com/docker/buildx/issues/1507
...to:
* 20 (maintenance LTS)
* 22 (maintenance LTS)
* 24 (active LTS release)
* 25 (current non-LTS release)
And address some "realm mismatch" problems in tests:
* It was using `AbortSignal` from `jsdom`'s realm, `fetch` from the Node
native `fetch`. Node 24 upgraded to undici v7 with stricter Fetch spec
compliance, which complained about this.
* It was doing `instanceof` checks from `myfetch` which failed for
similar reasons.
by updating vitest (see <https://github.com/vitest-dev/vitest/issues/8374>) and simplifying the `api.ts` checking.
Along the way, give error messages like `POST /api/login failed; see browser console` rather than the unhelpful `TypeError: Failed to fetch`.
Scott Lamb
Jared Wolff