Systemd syntax expects comment in a single line, hence the parsing failure
https://www.freedesktop.org/software/systemd/man/latest/systemd.syntax.html
Before;
```
[leandro@nuc ~]$ sudo systemd-analyze verify /etc/systemd/system/moonfire-nvr.service
/etc/systemd/system/moonfire-nvr.service:16: Failed to parse TimeoutStartSec= parameter, ignoring: 300 # large installations take a while to scan the sample file dirs
[leandro@nuc ~]$
```
After;
```
[leandro@nuc ~]$ sudo systemd-analyze verify /etc/systemd/system/moonfire-nvr.service
[leandro@nuc ~]$
```
* use `termion` rather than `ncurses` to limit runtime deps
* cross-compile with `cross` instead of our own dockerfiles/scripts
* update instructions
* update release procedure and GitHub actions to match
* prep changelog for `v0.7.8`
Fixes#160Closes#265
I think this is a big improvement in readability.
I removed the `lnav` config, which is a little sad, but I don't think it
supports this structured logging format well. Still seems worthwhile on
balance.
This gives much better information to the UI layer, getting rid of a
whole troubleshooting guide entry. See #119#132#218#219
I also restructured the code in anticipation of a new WebSocket event
stream (#40).
The build instructions currently fail if the user doesn't have a group
matching their user name (not a universally adopted convention). Update
the command to use the following functionality of the `chown` command:
"If a colon but no group name follows the user name, that user is made
the owner of the files and the group of the files is changed to that
user's login group."
* support cross-compiling an x86-64 target on an arm64 host. This
it turns out is a matter of *removing* an unnecessary dependency.
(aarch64-linux-gnu-pkg-config exists but x86_64-linux-gnu-pkg-config
doesn't. Turns out neither is necessary.) Added a comment explaining
where ${gcc_target}-pkg-config comes from now.
* documentation tweaks
* improve debug output a bit
This is useful for e.g. deciding whether or not to present the user
admin UI in navigation.
As part of this change, I adjusted the casing in Permissions, and then
all the toml stuff for consistency. Noted in changelog.
Fixes#206. 307a388 switched to creating a single-threaded runtime for
each stream, then destroying prior to waiting for TEARDOWN on shutdown.
This meant that the shutdown process could panic with this error:
```
panic at '/home/slamb/git/retina/src/client/mod.rs:219:22': teardown Sender shouldn't be dropped: RecvError(())
```
Let's switch back to expecting a multithreaded runtime context.
Create one for the config subcommand, too.
Don't go all the way back to the old code with its channels, though.
That had the downside that the underlying retina::Session might outlive
the caller, so there could still be an active session when we start
the next one. I haven't seen this cause problems in practice but it
still doesn't seem right.
* switch the config interface over to use Retina and make the test
button honor rtsp_transport = udp.
* adjust the threading model of the Retina streaming code.
Before, it spawned a background future that read from the runtime and
wrote to a channel. Other calls read from this channel.
After, it does work directly from within the block_on calls (no
channels).
The immediate motivation was that the config interface didn't have
another runtime handy. And passing in a current thread runtime
deadlocked. I later learned this is a difference between
Runtime::block_on and Handle::block_on. The former will drive IO and
timers; the latter will not.
But this is also more efficient to avoid so many thread hand-offs.
Both the context switches and the extra spinning that
tokio appears to do as mentioned here:
https://github.com/scottlamb/retina/issues/5#issuecomment-871971550
This may not be the final word on the threading model. Eventually
I may not have per-stream writing threads at all. But I think it will
be easier to look at this after getting rid of the separate
`moonfire-nvr config` subcommand in favor of a web interface.
* in tests, read `.mp4` files via the `mp4` crate rather than ffmpeg.
The annoying part is that this doesn't parse edit lists; oh well.
* simplify the `Opener` interface. Formerly, it'd take either a RTSP
URL or a path to a `.mp4` file, and they'd share some code because
they both sometimes used ffmpeg. Now, they're totally different
libraries (`retina` vs `mp4`). Pull the latter out to a `testutil`
module with a different interface that exposes more of the `mp4`
stuff. Now `Opener` is just for RTSP.
* simplify the h264 module. It had a lot of logic to deal with Annex B.
Retina doesn't use this encoding.
Fixes#36Fixes#126
* switch from json to toml.
I think this will be more user-friendly. It allows comments and has
less punctuation. Fewer surprises than yaml (which has e.g. the
"Norway problem"). I might have stayed with JSON if I could see a
good serde json library that allows comments, but hson is unmaintained
and serde-json strictly follows the spec.
* switch from camelCase to snake_case. Seems more idiomatic for TOML
and matches the Rust source.
* forbid unknown keys. Better to spot errors sooner.
* rename "trust_forward_hdrs" to "trust_forward_headers". Nothing else
is abbreviated.
Fixes#204
* The docker container won't start if a bind refers to a path that
doesn't exist yet, so move the /etc/moonfire-nvr.json creation up
* Remove redundant command in the dedicated hard drive setup, and
improve its clarity
I did a full `cargo upgrade` and fixed what it broke:
* a couple things for the latest protobuf 3.0 alphas
(note alphas don't promise API stability)
* new minimum supported Rust version
This should have some other nice effects: parking_lot now uses inline
assembler, tokio has gotten faster, etc.
1c9a556 started depending on arrays implementing IntoIterator. I keep
forgetting that 1.52 doesn't support this. There's really no compelling
reason to keep building on 1.52, so don't.
SelectView::set_selection doesn't seem to be working properly. The
symptom is editing an existing camera will clear the sample file dir,
and thus hitting edit without making any changes will fail.
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.
