I spotted this by inspection: adding a media time and wall time didn't
look right. I also confirmed the brokenness on my primary NVR:
```
sqlite> .mode column
sqlite> select
...> r1.composite_id,
...> r1.prev_media_duration_90k,
...> r1.wall_duration_90k,
...> r1.media_duration_delta_90k,
...> r2.composite_id,
...> r2.prev_media_duration_90k
...> from
...> recording r1 join recording r2 on (r1.composite_id = r2.composite_id - 1)
...> where
...> r1.prev_media_duration_90k + r1.wall_duration_90k + r1.media_duration_delta_90k !=
...> r2.prev_media_duration_90k
...> limit 5;
4296791095 2232623913716 5398956 154 4296791096 2232629312672
4296791096 2232629312672 5400016 38 4296791097 2232634712688
4296791097 2232634712688 5400729 105 4296791098 2232640113417
4296791098 2232640113417 5399024 80 4296791099 2232645512441
4296791099 2232645512441 5400770 124 4296791100 2232650913211
```
In the first row, the second recording's prev_media_duration_90k is the
first's prev_media_duration_90k plus its wall time, not its media time.
The CI nightly builds had been broken with the following error:
```
error: custom inner attributes are unstable
--> /home/runner/work/moonfire-nvr/moonfire-nvr/server/target/debug/build/moonfire-db-415ce696a754c614/out/schema.rs:10:4
|
10 | #![rustfmt::skip]
| ^^^^^^^^^^^^^
|
= note: `#[deny(soft_unstable)]` on by default
= warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
= note: for more information, see issue #64266 <https://github.com/rust-lang/rust/issues/64266>
```
I'd thought this was by mistake given that #[rustfmt::skip] is still
advertised on rustfmt's github page, but maybe not. Looks like
rust-protobuf's newest version uses
`#![cfg_attr(rustfmt, rustfmt::skip)]` to avoid this error.
Also fix a warning on nightly about an extraneous semicolon.
I also enforced some invariants in the signals code, fixing a couple
bugs. The signals code is more complex than I'd like, but hopefully
is working now.
I'd once thought about using 1 second resolution for signals and wrote
this map to match that. But I decided to match signals to the timestamps
used elsewhere instead. Match that for the days map also.
My main goal is to support creating indexes for signals as well as
recordings. An additional goal is to just shrink db.rs a bit; it's
gotten quite large.
This reverts commit d273a99f83.
This accidentally increased the density by making my global CSS
overrides ineffective. I'm struggling to achieve both, and I'd rather
have my desired sizing.
Looks like material-ui's `<Select variant="outlined">` needs a redundant
label property to make the layout correct.
https://next.material-ui.com/api/outlined-input/#main-content
"The label of the input. It is only used for layout. The actual
labelling is handled by InputLabel. If specified labelWidth is ignored."
* 1-hour videos are a bit faster to render server-side and don't
require so much index data to be transferred before play starts
* the timestamp tracks might be causing a lot of excess data transfer
in some cases. They're currently not interleaved by ascending
timestamp, and I wonder if they should be. Chrome might be pulling
all the bytes between the current position in the two tracks, which
can be excessive. I'll have to consider interleaving when I add
audio anyway. But for now, just make the default UI display
snappier. Chrome doesn't display the timestamp track anyway, so
don't let it slow things down.
Once I have more than one area of the UI (e.g., adding config, live
video, or a scrub bar prototype), I'll use this for a pull-down menu to
go between them, and maybe add a filter icon to do what this does. But
this works for now and most closely matches the old UI.
I tried to use a Collapse or Slide transition, but I had trouble getting
it to work on both desktop and mobile. In particular, the way I used the
flex wrap to display the selectors on the left/above doesn't seem
compatible with picking an orientation. If I pick the wrong orientation,
the list views won't fill the empty space.
* hide the end day selector away when it's not in use.
It was confusing, especially since it seemed to have
a purely black circle over the selected date when disabled.
* add a "Time" label to the time selectors. On desktop,
this isn't entirely necessary because they have clock icons
and "hh:mm:ss" annotations. But on mobile, they were entirely blank,
so it was unclear what they were for.
As noted in mylog's 2b1085c:
Looks like both the GNU tools' --color argument and cargo's
CARGO_TERM_COLOR expect always/never rather than on/off. Match that.
Might as well understand off/no/false and on/yes/true also.
This picks up moonfire-ffmpeg's 4b13378:
support ffmpeg's multi-call log messages
This should fix this annoying log output:
```
W20210310 13:17:09.060 s-garage_west-main moonfire_ffmpeg::rtsp] 0xaf300950: RTP H.264 NAL unit type 29
W20210310 13:17:09.060 s-garage_west-main moonfire_ffmpeg::rtsp] 0xaf300950: is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
```
so it looks like this instead:
```
W20210310 13:17:09.060 s-garage_west-main moonfire_ffmpeg::rtsp] 0xaf300950: RTP H.264 NAL unit type 29 is not implemented. Update your FFmpeg version to the newest one from Git. If the problem still occurs, it means that your file has a feature which has not been implemented.
```
I think this has a minor behavior change: permission denied replies
change to HTTP 403 where they were HTTP 401. The new behavior seems
more correct, as these errors can occur when authentication has
succeeded but the session in question is not authorized for the given
operation. The UI currently doesn't care about this distinction.
Looks like a refactoring in 9d7cdc09 introduced the possibility this
could fail (where before it might produce a silly i32 pts) and forgot
to restore the invariant.
* add more description to the troubleshooting guide
* adjust the log format to match more recent glog
* include a config for the lnav tool, which will help colorize,
browse, and search the logs.
Next up: install an ffmpeg log callback for consistency.
Otherwise `moonfire-nvr check --delete-orphan-rows` can fail with this
error:
```
I0305 113848.655 main moonfire_db::check] Deleting 2 recording rows
E0305 113848.655 main moonfire_nvr] Exiting due to error: FOREIGN KEY constraint failed
```
The new order matches the online system's `db::raw::delete_recordings`.
It worked fine on my laptop with node.js v14.15.4, but not on my
new workstation with node.js v12.18.2 (as comes with Ubuntu 20.10).
It would print "Unexpected token '?'" without any clue what file the
error is in. I'm trying to fix that here:
https://github.com/facebook/create-react-app/pull/10652
