After a frustrating search for a suitable channel to use for shutdown
(tokio::sync:⌚:Receiver and
futures::future::Shared<tokio::sync::oneshot::Receiver> didn't look
quite right) in which I rethought my life decisions, I finally just made
my own (server/base/shutdown.rs). We can easily poll it or wait for it
in async or sync contexts. Most importantly, it's convenient; not that
it really matters here, but it's also efficient.
We now do a slightly better job of propagating a "graceful" shutdown
signal, and this channel will give us tools to improve it over time.
* Shut down even when writer or syncer operations are stuck. Fixes#117
* Not done yet: streamers should instantly shut down without waiting for
a connection attempt or frame or something. I'll probably
implement that when removing --rtsp-library=ffmpeg. The code should be
cleaner then.
* Not done yet: fix a couple places that sleep for up to a second when
they could shut down immediately. I just need to do the plumbing for
mock clocks to work.
I also implemented an immediate shutdown mode, activated by a second
signal. I think this will mitigate the streamer wait situation.
I saw this recently while working on new-schema. It was probably due
to some manual upgrade or downgrade I did rather than an actual bug.
Improve debuggability a little nonetheless.
* upgrade to Retina 0.3.1 which automatically tears down sessions
* wait out stale sessions before reconnecting
* wait for teardown to complete before shutting down
This adds some pressure on #117: it will keep waiting for the stale
session to expire even if the user has requested shutdown. I'll try
to address that next.
When you select the first camera in the drop-down on a grid square
that isn't the top left, then select a camera in the top-left, it
behaves strangely.
The root cause is that I had a dumb mistake in how I assigned React
keys. I used the camera index when a camera is selected, and the
inverse of the selected index when one is. But 0 == -0!
* prefix docker/nvr commands with sudo (fixes#142).
I was just going to link to the docker documentation on setting
up non-root access, but that's kind of a personal preference.
I included a `<details>` about it instead and made all the commands
work with sudo.
* take better advantage of github markdown's code block syntax
highlighting. Use "console" for shell session stuff, put the
"nvr" wrapper script in its own block with "bash".
* add some comments to nvr wrapper script where people need to
make changes and/or will be confused.
* add a `<details>` that talks about shutting down and restarting
the session around `nvr config` (see #151). Still not user-friendly
but at least it's better documented now.
* add the command to create `/usr/local/lib/moonfire-nvr`, necessary
the first time
* have the files owned by root and use world-readable permissions, even
if the building user has a restrictive umask set
This mostly affects .mp4 init segments (#146), which currently set the
Last-Modified: date to the epoch. It could also affect other resources
(static files, other .mp4 changes) but only if the clock has gone
backwards.
I forgot to do this in 27395ec resulting in #146. Bump the version now,
and update the digest used in the tests so they will remind me to
bump the version any time the headers change.
As written in the changelog: Live streams formerly worked around a
Firefox pixel aspect ratio bug by forcing all videos to 16:9, which
dramatically distorted 9:16 camera views. Playback didn't, so anamorphic
videos looked correct on Chrome but slightly stretched on Firefox. Now
both live streams and playback are fully correct on all browsers.
* run node 12, 14, and 16 (next to be supported) on CI. This will catch
node version-specific problems like that solved in dad9bdc.
* mention 12 and 14 in build instructions and link to instructions for
installing that version.
* follow this in Dockerfile, installing version 14. This addresses
a "Cannot find module 'worker_threads'" error introduced in
39a63e0, which (inadvisedly) upgraded gzipper 4->5 in addition to
the material-ui upgrade.
* use utf-8 encoding rather than ascii in live part parser. Those
builds apparently don't support ascii. iThey must use "small-icu" or
have ICU disabled, as described here:
https://nodejs.org/api/util.html#util_encodings_supported_when_node_js_is_built_with_the_small_icu_option
This worked fine on my workstation with node 12. But on CI or my laptop
with node 14, it failed. Apparently there @testing-library/user-events
expects a peer @testing-library/dom dependency. At least copying the
"npm install --save-dev @testing-library/user-event @testing-library/dom" command
from the top of https://testing-library.com/docs/ecosystem-user-event/
made it work again on my laptop; fingers crossed about CI.
This is a surprisingly complex upgrade. Some relevant changes from
[their CHANGELOG](https://github.com/mui-org/material-ui/blob/v5.0.0-beta.3/CHANGELOG.md):
* @material-ui/core/styles no longer re-exports some stuff from
@material-ui/styles
* there's no more defaultTheme, so tests need to provide one
* select's onChange has a new type; match that. I haven't actually
tried that the string form (apparently from autofill) works correctly.
* checkboxes no longer default to the secondary color; explicitly
request this in some places.
* checkbox no longer has a checked argument; use event.target.checked
instead.
* date pickers have switched to the new style system, so I had to
redo how I was overridding their spacing for desktop.
* LoadingButton now has a loading property, not pending
* createMuiTheme is no createTheme
Fixes#136
Before:
```
E20210803 09:00:31.161 main moonfire_nvr] panic at '/Users/slamb/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.14.10/src/server/server.rs:68:17': error binding to 0.0.0.0:80: error creating server listener: Address already in use (os error 48)
(set environment variable RUST_BACKTRACE=1 to see backtraces)
...potentially unrelated log msgs from other threads before exiting...
```
After:
```
E20210803 09:06:02.633 main moonfire_nvr] Exiting due to error: unable to bind --http-addr=0.0.0.0:80
caused by: error creating server listener: Address already in use (os error 48)
(set environment variable RUST_BACKTRACE=1 to see backtraces)
```
For #136. I'm also going to make this particular case no longer panic,
but there will surely be other affected panics.
Before:
```
E20210803 08:58:31.606 main moonfire_nvr] panic at '/Users/slamb/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.14.10/src/server/server.rs:68:17'
```
After:
```
E20210803 08:59:51.319 main moonfire_nvr] panic at '/Users/slamb/.cargo/registry/src/github.com-1ecc6299db9ec823/hyper-0.14.10/src/server/server.rs:68:17': error binding to 0.0.0.0:80: error creating server listener: Address already in use (os error 48)
```
Scott Lamb
John Poole
dependabot[bot]