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.
I copied the example of the password field by introducing a setter.
But I forgot: it was only that way because the password field has
the complexity of hashing/salting. For fields where setting is
idempotent, it can be directly exposed.
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
