wget downloaded moonfire-nvr-0.7.16 's cargo test fails

[fr4nz909]

I downloaded the archived package of moonfire-nvr-0.7.16 and ran tests inside /server, they failed with the following error message:

`Compiling libsystemd v0.7.0
Compiling mp4 v0.9.2 (https://github.com/scottlamb/mp4-rust?branch=moonfire#388fb476)
Compiling reffers v0.7.0
Compiling sync_wrapper v0.1.2
error: failed to run custom build command for moonfire-nvr v0.0.0 (/root/rust/moonfire-nvr-0.7.16/server)

Caused by:
process didn't exit successfully: /root/rust/moonfire-nvr-0.7.16/server/target/debug/build/moonfire-nvr-f9a5569a9564ce58/build-script-build (exit status: 101)
--- stdout
cargo:rerun-if-changed=build.rs
cargo:rerun-if-env-changed=VERSION

--- stderr
thread 'main' panicked at build.rs:173:38:
called Option::unwrap() on a None value
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace
warning: build failed, waiting for other jobs to finish...`

Could the reason just be, that there was an older version of moonfire on the system before?

Addition:
Tests do not fail with the master branch code.
Only the archived version has the tests fail.

[scottlamb]

Ahh. The failure is from here:

moonfire-nvr/server/build.rs

Lines 161 to 173 in e6c7b80

	// Get version from `git describe`. Inspired by the `git-version` crate.
	// We don't use that directly because `cross`'s default docker image doesn't install `git`,
	// and thus we need the environment variable pass-through above.
	// Avoid reruns when the output doesn't meaningfully change. I don't think this is quite right:
	// it won't recognize toggling between `-dirty` and not. But it'll do.
	let dir = Command::new("git")
	.arg("rev-parse")
	.arg("--git-dir")
	.output()?
	.stdout;
	let dir = String::from_utf8(dir).unwrap();
	let dir = dir.strip_suffix('\n').unwrap();

It fails because the source bundle from github doesn't include the .git directory, and the error handling when that command fails could use some work.

As a workaround, try VERSION=v0.7.16 cargo test instead.

[scottlamb]

This will give a more helpful message as of 6c227ec

[fr4nz909]

Hello Scott! I hope you have started well into 2025! :) Thanks for working on moonfire-nvr regarding Reolink cams, with specific hardware number of RLC510A it really works well. You mentioned on GitHub that you would like to be able to create cams etc. via the frontend, talking to the API. As I needed this for my use case I extended the moonfire API to add cameras and change there retentions. Now the thing: I also extended the API to after adding a cam over the API, to start the stream for it. And after long hours, this works. The stream starts, the media gets written through the writer. BUT, it seems like HTTP requests requesting the /view/...mp4 endpoint are 'blocked'. When i stop the server and restart it, it gets the written streams from DB. So the saving/writing works. But somehow I think starting a stream from within the web service somehow blocks getting responses from the view/mp4 endpoint. Other endpoints, like adding a sample file dir (which I added), still works after starting the stream via API. This is the error I get inside browers: [image: Bildschirmfoto 2025-01-26 um 23.27.47.png] Blockiert == blocked with "NS_ERROR_NET_RESET" And the window, that open to show the media, says: [image: Bildschirmfoto 2025-01-26 um 23.27.04.png] "Kein Video mit unterstütztem Format und MIME-Typ gefunden." -> Which means "No video with supported format and MIME type found." I guess you probably really fast see what the problem with starting a stream from within the Web Service is... As you also wanted to extend the API before, what would be your way of making starting of a stream via the API possible? Otherwise, after adding a cam, moonfire-nvr needs to be stopped every time to restart the runtime which starts the streams. :D But I guess you will have an idea on that, then I can do that if you want. :) [Will not be the most qualitative Rust Code, but I am willing to learn haha :D And I need this feature myself anyways] Many regards from Germany, Franz Am Fr., 31. Mai 2024 um 17:58 Uhr schrieb Scott Lamb < ***@***.***>:

…

Ahh. The failure is from here: https://github.com/scottlamb/moonfire-nvr/blob/e6c7b800feceaed2ae124341024af8d62015867b/server/build.rs#L161-L173 It fails because the source bundle from github doesn't include the .git directory, and the error handling when that command fails could use some work. As a workaround, try VERSION=v0.7.16 cargo test instead. — Reply to this email directly, view it on GitHub <#318 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJNRFM2S76Y4DWF7DRKJTMDZFCM3TAVCNFSM6AAAAABITBIYVWVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TMMRQG43DE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[scottlamb]

As I needed this for my use case I extended the moonfire API to add cameras and change there retentions.

❤️ 🎉

I guess you probably really fast see what the problem with starting a stream from within the Web Service is...

I don't off-hand. Do you want to open like a draft PR with your changes? Maybe the problem will jump out at me as I read and/or run the code myself.

As you also wanted to extend the API before, what would be your way of making starting of a stream via the API possible?

I think the super hand-wavey version is that there needs to be some tracking of stream states somewhere accessible from the web::Service: at least running vs not, maybe also transitional "starting" and "shutting down" states. And then the logic for starting the streamers should move out of cmds/run/main.rs to somewhere else.

...and likely the same for sample file directories.

[fr4nz909]

Hey Scott. Thanks for answering! That sounds nice, I guess that’s a good path for me. When having the logic moved out of main.rs (what I did), would there be any side effects when starting single streams on different time-starting-points? For example, I start moonfire up, add „cam1“, start a stream for „cam1“, it is running a while, then I add „cam2“ and start up that stream. With the logic similar to what’s in main.rs, streamer.run when I remember right. As it says this should be started in an tokio invironment with IO enabled. Is there something else to be aware of when starting streams at different points like this? I think the main thing to also be aware of is the db-Lock, isn’t it? Because when a new cam is added and the stream for that starts up, I think there most be kind of a „reload“ or „reopening“ of the sample file dirs and the db, right? With that Informationen, I will sit down on a draft PR. :) Am Montag, 27. Januar 2025 schrieb Scott Lamb ***@***.***>:

…

As I needed this for my use case I extended the moonfire API to add cameras and change there retentions. ❤️ 🎉 I guess you probably really fast see what the problem with starting a stream from within the Web Service is... I don't off-hand. Do you want to open like a draft PR with your changes? Maybe the problem will jump out at me as I read and/or run the code myself. As you also wanted to extend the API before, what would be your way of making starting of a stream via the API possible? I think the super hand-wavey version is that there needs to be some tracking of stream states somewhere accessible from the web::Service: at least running vs not, maybe also transitional "starting" and "shutting down" states. And then the logic for starting the streamers should move out of cmds/run/main.rs to somewhere else. ...and likely the same for sample file directories. — Reply to this email directly, view it on GitHub <#318 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJNRFM3XTSD6RXYXQ3XPXXT2M2IH3AVCNFSM6AAAAABV44LLNCVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCOJXGUYTIMQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[scottlamb]

When having the logic moved out of main.rs (what I did), would there be any side effects when starting single streams on different time-starting-points?

I expect it would be fine. Even today, while it tries to start them at about the same time, the actual timespans recorded vary widely if a camera is down for a while or the like.

I think the main thing to also be aware of is the db-Lock, isn’t it?

There are certainly some operations that could end up holding the db lock for a long time, e.g. radically decreasing the retention for a stream will involve a huge database commit, and long-term it'd be better to break that apart into batches or the like. But just starting and stopping streams should be fast. If it's not, you'll see a warning about the slow operation generated from the following code:

moonfire-nvr/server/base/clock.rs

Line 195 in dd30d5b

warn!("{} took {:?}!", label_f().as_ref(), elapsed);

moonfire-nvr/server/db/db.rs

Line 2423 in dd30d5b

let _timer = clock::TimerGuard::<C, &'static str, fn() -> &'static str>::new(

Because when a new cam is added and the stream for that starts up, I think there most be kind of a „reload“ or „reopening“ of the sample file dirs and the db, right?

The initial scan of the sample file dirs and database indeed can be slow, but it should just once on startup. I don't see why it'd be necessary when adding a new camera (which will have 0 recordings, nothing to scan for) or even a new sample file dir (likewise, no existing database entries).